Heim >Backend-Entwicklung >PHP-Tutorial >PHP: Soll ich mich lustig machen oder soll ich gehen?
Mocks zielen darauf ab, das Verhalten realer Objekte zu testen.
Sie simulieren Abhängigkeiten, sodass Sie keine externen Ressourcen aufrufen müssen, die Unit-Tests erheblich verlangsamen könnten.
Sie können Erwartungen definieren und diese überprüfen.
Sie können beispielsweise sicherstellen, dass eine Methode eine bestimmte Anzahl von Malen und/oder mit bestimmten Parametern aufgerufen wird:
use PHPUnit\Framework\TestCase; class MyTest extends TestCase { public function testMockExample(): void { $depencencyMock = $this->createMock(MyDependency::class); $dependencyMock->expects($this->exactly(2)) ->method('someMethod') ->with('some parameter'); $classToTest = new ClassToTest($dependencyMock); } }
willReturn() gewährleistet die Kompatibilität mit den Rückgabetypen:
// In code class MyClass { public function getNum(): int { } } // In tests $myClassMock = $this->createMock(MyClass::class); $myClassMock->expects($this->once()) ->method('getNum') ->willReturn(2);
Sie können willReturnCallback auch verwenden, wenn Sie dynamisches Verhalten basierend auf Eingabeparametern testen möchten.
Da Verspottungen nur echte Verhaltensweisen nachahmen, kann es leicht passieren, dass man den Kern verfehlt. Lassen Sie uns häufige schlechte Praktiken besprechen:
❌ Tu das nicht:
$colorServiceMock = $this->createMock(ColorService::class); $colorServiceMock->method('hexToName') ->willReturn('red'); $color = (new MyClass($colorServiceMock))->getColorName('ff0000');
✅ Fügen Sie stattdessen einige Erwartungen hinzu:
$colorServiceMock->expects($this->once()) ->method('hexToName') ->with('00f00') ->willReturn('green'); $color = (new MyClass($colorServiceMock))->getColorName('00f00');
Denken Sie daran, dass Mocks darauf abzielen, Interaktionen zu überprüfen.
Testen wir MyClass, die SomeInterface implementiert.
❌ Tu das nicht:
$myclassMock = $this->createMock(MyClass::class);
✅ Verspotten Sie stattdessen die Schnittstelle:
$myclassMock = $this->createMock(SomeInterface::class);
Mocks konzentrieren sich auf Verhaltensweisen. Schnittstellen ändern sich normalerweise nicht, da Sie Implementierungen und keine Verträge ändern sollen.
Tomas Votruba erklärt dieses Problem wunderbar: 5 Möglichkeiten, aus übermockten Tests einen Mehrwert zu ziehen
Es ist leicht, eine enge Kopplung zwischen Komponenten zu ignorieren:
$productRepositoryMock = $this->createMock(ProductRepository::class); $invoiceRepositoryMock = $this->createMock(InvoiceRepository::class); $emailServiceMock = $this->createMock(EmailService::class); $overComplexService = new OverComplexService($productRepositoryMock, $invoiceRepositoryMock, $emailServiceMock);
Das obige Beispiel durchbricht die Trennung von Bedenken und Spott setzt diese schlechte Praxis fort.
Mocks sind leistungsstarke Werkzeuge, aber Unit-Tests reichen nicht aus. Sie benötigen verschiedene andere Arten von Tests (z. B. Integration, e2e).
Zusätzlich zu den schlechten Praktiken gibt es weitere Anzeichen, die darauf hindeuten könnten, dass Mocks im Projekt missbraucht oder überbeansprucht werden:
Martin Fowler hat einen fantastischen Beitrag geschrieben, der erklärt, warum Mocks keine Stubs sind.
Sehen wir uns konkrete Situationen an, in denen Sie sie verwenden könnten:
Hier sind ein paar Testfälle, bei denen Mocks sinnvoller sind:
Mit PHPUnit können Sie ganz bequem Stubs erstellen:
use PHPUnit\Framework\TestCase; class MyTest extends TestCase { public function testMockExample(): void { $depencencyMock = $this->createMock(MyDependency::class); $dependencyMock->expects($this->exactly(2)) ->method('someMethod') ->with('some parameter'); $classToTest = new ClassToTest($dependencyMock); } }
Hier sind ein paar Testfälle, bei denen Stubs sinnvoller sind:
Kurz gesagt: Stubs sind nicht dazu gedacht, das Verhalten realer Objekte zu überprüfen, sondern Zustände.
Der Hauptzweck von Unit-Tests besteht darin, sicherzustellen, dass jede Einheit/Komponente wie erwartet funktioniert. Sie müssen diese Tests jedoch zusätzlich zum eigentlichen Code pflegen.
Stubs können den Testaufbau vereinfachen und sind sehr effizient für einfache Szenarien, in denen Sie Methodenaufrufe und Interaktionen nicht verfolgen müssen.
Es kann unnötige Komplexität vermeiden, indem Sie einige Ihrer Tests fokussiert halten.
Mocks können Methodenaufrufe und ihre Parameter verfolgen.
Vergessen Sie nicht, Werte zurückzugeben, die für reale Verhaltensweisen repräsentativ sind. Andernfalls könnten Sie ein falsches Sicherheitsgefühl entwickeln.
Mocks sollten sparsam eingesetzt werden, um unnötige Komplexität bei der Wartung zu vermeiden.
Das obige ist der detaillierte Inhalt vonPHP: Soll ich mich lustig machen oder soll ich gehen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!