Mocks 'n' Stubs

Motivation

• Indirekte Eingaben/Ausgaben

• "Behavior verification": Benutzt das SUT (system under test) seine Abhängigkeiten korrekt?

• Abhängigkeiten können komplexe Implementierungen haben oder (noch) gar nicht implementiert sein

• Simulieren von externen Komponenten

• Testen von Fehlersituationen (Paperjam, Datenbankverbindung abgebrochen, o.ä.)

Test Doubles

• Dummy: Platzhalter innerhalb des Test-Setups
• Fake: Ersetzt eine Komponente (Service, Repository, etc.)
• Stubs: Rudimentäre Funktionalität --> Hard-Coded Rückgabewerte
• Spies: Flag wird bei Aufruf gesetzt
  • Self-shunt
• Mocks: Konfigurierbare Test Doubles (z.B. per Reflection, etc.)

Nachteile

• Abwägen von Performance der Tests und Reflection, die Laufzeit benötigt
• Zahl der Mocks minimal halten
  • Vor allem für Commands verwenden, nicht für Queries (z.B. Repositories)

Ausblick

• Mit Mocking über das Behaviour der Objekte lernen
  • Ohne Implementierung der umgegebenen Objekte zu kennen
  • --> Growing Object-Oriented Software, Guided by Tests

Quellen

• Martin Fowler: "Mocks Ain't Stubs"

• Steve Freeman, Tim Mackinnon, Nat Pryce, Joe Walnes: "Mock Roles, Not Objects"

• Steve Freeman, Nat Pryce: "Growing Object-Oriented Software, Guided by Tests"

• Avdi Grimm: "Making a Mockery of TDD"

• Gerard Meszaros: "xUnit Test Patterns"

• Frank Westphal: "Testgetriebene Entwicklung mit JUnit & FIT"

• EasyMock

• Mockito