Im Attachment zu diesem Blogeintrag zeige ich wie ich mir ein .NET Golfturnier vorstelle, der eigentliche Tester und der Abschlag des Golfers sind hierbei für das einfachere Verständnis miteinander gemischt.
In der #develop Combine sind 3 Projekte enthalten:* Tees: da drinnen sind die Interfaces definiert, dagegen linkt jede Aufgabe. Pro Aufgabe gibt es ein Interface das von ITee ableitet (für spätere Erweiterungen im Tester gedacht). Das aktuelle Turnier ist durch ITeeGroupTransform abgebildet.* GroupTransformTeeOffSample: hier habe ich Peter's Schlag in den Bunker implementiert, in der Datei TeeOff.cs. Die Klasse *muß* immer Tee heißen sowie das Turnierinterface implementieren. Der Rest ist Sache des Golfers...* GroupTransformTester: das ist unsere (Referee) Applikation. Im echten Leben wird das alles von der Kommandozeile aus gemacht: TeeOff.cs [oder wie auch immer die Einreichung des Golfers dann heißt], Interfaces.cs und Tester.cs werden mittels csc zu einer Assembly kompiliert, und dann vom Kommandozeilen-NUnit getestet. Der Einfachheit halber verwende ich heute aber das NUnitPad das im aktuellen #develop drinnen ist (http://svn.sharpwt.net/dev/). Damit wird es perfekt automatisierbar.
Das ist einmal die Basis - Reflection und dynamisches Laden einer Assembly habe ich mir mit dieser Lösung erspart. Kommentare?
