Was ist der Unterschied zwischen einem Mock, einem Stub und einem Fake, und wann nimmst du stattdessen eine echte Abhängigkeit?

Ein Stub liefert vorgefertigte Antworten, damit der zu testende Code weiterlaufen kann. Ein Mock zeichnet zusätzlich Interaktionen auf, sodass du prüfen kannst, dass sie stattfanden, also Verhalten statt Zustand. Ein Fake ist eine leichtgewichtige funktionierende Implementierung, etwa ein In-Memory-Repository. Nimm echte Abhängigkeiten, wenn die Integration selbst das Risiko ist, und Test Doubles, wenn die Abhängigkeit langsam, teuer oder schwer in einen bestimmten Zustand zu zwingen ist.

Ein Stub ist passiv, er gibt einfach zurück, was du ihm gesagt hast, damit der Code weiterlaufen kann. Ein Mock ist ein Stub, der sich zusätzlich merkt, was mit ihm passiert ist, sodass du prüfen kannst, dass der Payment-Service genau einmal mit diesen Argumenten aufgerufen wurde. Ein Fake ist eine echte, aber vereinfachte Implementierung, etwa eine In-Memory-Variante eines Repositories, die sich korrekt verhält, aber nicht produktionsreif ist. Der praktisch wichtige Unterschied ist, dass Stubs und Fakes Zustandsprüfung unterstützen, also Prüfen auf das Ergebnis, während Mocks Interaktionsprüfung unterstützen, also Prüfen auf das Gespräch. Ich neige zum Ersteren, denn auf Interaktionen zu prüfen koppelt den Test an Implementierungsdetails, und dann bricht ein Refactoring hundert Tests, ohne dass sich ein einziges Verhalten geändert hat. Echte Abhängigkeiten nehme ich überall dort, wo die Integration das Risiko ist. Lautet die Frage, ob unsere Query tatsächlich gegen Postgres funktioniert, beantwortet eine gemockte Datenbank gar nichts, also fahre ich das echte Ding im Container. Das ist inzwischen mein Default für die Integrationsschicht, seit Container das billig gemacht haben. Drittanbieter-Services, die ich nicht kontrolliere, mocke ich und sichere das mit geplanten Contract-Tests gegen deren Sandbox ab.