In general when A is dependend on B then A is component and B is argument
Some examples of different functions and how they map to DelftShell.Functions.
A function with one argument (year) and one component (dija)
A function with one argument (portofolio weight) 3 components (most-,least- and medium risk aversion). Or you could
model this as three separate functions with one argument and one component each.
Functions above are all 1D since they all have one argument.
2D functions: 
F(x,y) is dependend of x and y. Two arguments (x and y) and one component f(x,y)
A function with two arguments (horizontal and vertical position) and three components (R,G,B)
How to show a form in your test projects
[Test]
[Category("Windows.Forms")]
public ShowControlModal()
{
Control control = new myTestControl();
//this show a control on your developer box and show it shortly on the build server
WindowsFormsTestHelper.ShowModal(control);
}
Dont use blocking show calls in your tests since it will stop the server. Use can use
WindowsFormsTestHelper.IsBuildServer to find out if you're running on the buildserver
DelftShell Build Logica.
Hieronder staat de build logica beschreven van DelftShell. Wees vrij om wijzigen etc aan te brengen zodat dit document kan worden opgenomen in referentie materiaal. Hieronder staat een voorstel voor een nieuw build proces en ook hier zijn suggesties om het simpeler of sneller te maken natuurlijk nodig.
Martijn
Voor het builden van DelftShell inclusief plugins wordt nu gebruikt gemaakt van een aantal shared libraries en post-build events. Dit document probeert zo helder mogelijk het proces van builden en creëren van een 'loader' te beschrijven.
delft-tools\lib(1)
delft-tools\apps\DelftShell\modules\DelftShell.Loader\bin\Debug
delft-tools\apps\DelftShell\modules\DelftShell.Loader\bin\plugins(5)
delft-tools\apps\DelftShell\lib(2)
delft-tools\apps\DelftShellPlugins
delft-tools\apps\DelftShellPlugins\NetCdf
delft-tools\apps\DelftShellPlugins\NetCdf\lib(3)
delft-tools\apps\DelftShellPlugins\NetCdf\modules\
delft-tools\apps\DelftShellPlugins\NetCdf\modules\NetCDF\bin\Debug(4)
De lib directories (1,2,3) zijn er voor om 3rd party dlls te herbergen. NB: waarom lib (2)?
Allereerst worden onafhankelijke dlls (Bijvoorbeeld GeoApi.dll) gebuild met eventueel PostSharp post-build actie. Deze dll worden gereferenced door ander projecten.
De meer interessante projecten zijn de plugins en de loader.
1 Build plugins
1.1 Build plugin
1.2 Run postbuild events voor deze plugin
1.2.1 Run PostSharpPostBuild.cmd (\\bin\PostSharpPostBuild.cmd)
1.2.1.1 TODO: specify what this .cmd does
1.2.2 Run plugin PostBuild.cmd (\\bin\PluginPostBuild.cmd)
1.2.2.1 Creëer directory voor plugin in de loader\bin\plugins
1.2.2.2 Copieer alle dlls uit bin directory van plugin(4) naar bin\plugin directory binnen de loader(5).
1.2.2.3 Copieer alle dll.config files uit bin directory van plugin naar bin\plugin directory binnen de loader.
1.2.2.4 Verwijder bepaalde dlls als ze bestaan.(de lijst van welke is lang en staat in de .cmd file).
1.2.3 Doe plugin specifieke logica. Bijvoorbeeld: plugins.SharpMapGis kopieert alle bestanden uit de root lib (2) naar de plugin dir (5) binnen de loader en kopieert daarna nog van alles.
2 Build loader
2.1 Build de loader
2.2 Run postbuild events van de loader
2.2.1 Verwijder Nhibernate.dlls als deze er zijn.
2.2.2 Verwijder NetTopologySuite.dlls als deze er zijn.
2.2.3 Copieer een paar dllls uit de hoofd lib dir naar de build directory.
Problemen huidige structuur:
1 Verschillende build acties voor verschillende plugins. Kopieeer acties voor specifieke plugin slecht gedocumenteerd.
2 PostSharpPostBuild doet veel (onnodige?) kopieeracties.
3 3 lib directories! (1 voor plugins 1 voor shared kan ik begrijpen) waarvan men moet bijhouden wat waar wordt gebruikt.
Voorstel nieuwe structuur:
KISS.
Doel maak het simpeler en reduceer het aantal kopieer acties.
Veranderingen:
1 Plugin kopieert zichzelf naar bin van de loader (zonder subdir) en kijkt of afhankelijke dlls ook moeten worden gekopieerd (if !Exists copy op de hele bin van de plugin). Een grote bak met alle dlls dus.En geen specificatie van file-names in postbuild event.
2 PostSharp kan misschien sneller (zonder kopieer acties)
3 Geen extra acties binnen build loader.
4 Verwijder overbodige lib directory (2)
5 Split projecten zodat er minder vaak gebuild hoeft te worden
1 Build plugin
1.1 Build plugin
1.2 Run postbuild voor plugin
1.2.1 Run PostSharpPostBuild
1.2.2 Kopieer inhoud van bin directory van plugin naar bin van de loader. Doe dit alleen voor non-existing files.
2 Build loader
2.1 Run Postbuild events van de loader
- http://www.chrisbrandsma.com/2007/09/rhino-mocks-new-syntax.html
- http://aspalliance.com/1400_Beginning_to_Mock_with_Rhino_Mocks_and_MbUnit__Part_1.all
The old way:
[Test]
public void MyOldTest()
{
// Record your expectations here
Expect.Call(myObject.MyProperty).Return(1);
mocks.ReplayAll();
// do your work here
int i = myObject.MyProperty;
// check you values
mocks.VerifyAll();
Assert.AreEqual(1, i);
}
The new way:
[Test]
public void MyNewTest()
{
// Record your expectations here
using ( mocks.Record() )
{
Expect.Call(myObject.MyProperty).Return(1);
}
// do your work here
int i;
using ( mocks.Playback() )
{
i = myObject.MyProperty;
}
// check you values
Assert.AreEqual(1, i);
}
To improve quality of sourcecode we use unit tests. A typical unit test would check the result of a function or procedure for a given set of input parameters. The quality of our programs can be ensured when most of the sources are tested. Therefore it is important to have an overview of the "coverage" of our sources by tests. To show this coverage we use NCover on the buildserver. During nightly builds the coverage is calculated and presented in a stack-chart for the different dll's. An example of such a chart is shown below.
