Mock it up!
Gestern hatte ich eine Veranstaltung zu Visual Studio Team System und dem Team Foundation Server. Während wir über Unit-Testing gesprochen haben, stellte mir ein Teilnehmer die Frage, ob wir ein Mocking Framework zur Verfügung stellen. Nach einem klaren "Nein" stellte ich die Gegenfrage wer von den Teilnehmern Mocking einsetzt. Das Resultat: Keiner.
Nachdem sich die Frage also vielmehr als "rein Interesse-halber" herausstellte, überlegte ich, welches Mocking Framework ich eigentlich mag.
Um ehrlich zu sein, ich habe noch keine besondere Präferenz. Ich finde allerdings den Ansatz von Rhino Mocks interessant. Objektmodelle mit Fluent Interfaces sind einfach gut zu lesen und leicht zu benutzen.
Hier ein Beispiel:
1: MockRepository mocks = new MockRepository();
2: sessionState = mocks.CreateMock<IHttpSessionState>();
3:
4: Expect.Call( sessionState.Count ).Return( 10 );
5:
6: sessionState.Add( "Hallo", "Welt" );
7: LastCall.Repeat.AtLeastOnce();
8:
9: Expect.Call( sessionState[ "hello" ] ).Return( "Hello, world." );
10:
11: Expect.Call( sessionState[ "Hallo" ] ).Return( "Welt" ).Repeat.Any();
12:
13: mocks.ReplayAll();
14:
15: Console.WriteLine( sessionState.Count );
16: sessionState.Add( "Hallo", "Welt" );
17: Console.WriteLine( sessionState[ "hello" ] );
18: // Console.WriteLine( sessionState[ "Hallo" ] );
19:
20: mocks.VerifyAll();
Die Zeilen 4 - 11 enthalten das Laufzeitverhalten das das Mock-Objekt darstellen soll. Einfach nur die Instruktionen betrachten, man sieht sofort die Intention die dahinter steckt. Das Schreiben der Anweisung LastCall.Repeat.AtLeastOnce(); ist intuitiv und das Ergebnis ist exakt das was man im Source ausdrückt: "Wiederhole den letzten Aufruf mindestens einmal". Das schöne, den Source-Code versteht man mit Sicherheit auch noch Wochen später.
Wer mehr zum Thema Mocks und Testing erfahren möchte, dem kann ich nur das Blog von Roy Osherove empfehlen.
