Mit der besten Praxis in API Testaufbau - DB-Kommunikation benötigt (TDD)

Question

Ich werde einen neuen Endpunkt schreiben, um das Domain-Objekt zu entsperren, so etwas wie:

../domainObject/{id}/unlock 

Wie ich TDD anwenden, habe ich begonnen, um zuerst einen API-Test zu schreiben. Wenn der Test fehlschlägt, werde ich mit dem Schreiben von Integrations- und Komponententests beginnen und den echten Code implementieren.

Im API-Test benötige ich eine gesperrte Domain-Daten für Test Fixture Setup, um den Entsperrendpunkt zu testen, der erstellt wird. Es gibt jedoch keinen Endpunkt zum Sperren des Domänenobjekts auf dem System. (Unsere Quartz-Jobs sperren die Daten.) Ich meine, ich muss Daten erstellen, indem ich die Datenbank direkt benutze.

Ich weiß, dass in der API-Test, gerade Datenbanknutzung nicht die beste Praxis ist. Wenn Sie Testdaten benötigen, sollten Sie auch die API aufrufen. z.B.

../domainObject/{id}/lock 

Sollte dieses Szenario eine Ausnahme in diesem Fall? Oder sollte ich sonst noch üben?

Danke.

Answer 1

Es gibt keine gute oder schlechte Praxis hier, es geht darum, wie viel Sie End-to-End-Tests des Systems einschließlich der Datenbank schätzen.

Das Testen des DB-Teils erfordert etwas mehr Infrastruktur, da Sie entweder eine In-Memory-Datenbank für schnellere Testläufe verwenden müssen oder in Ihrer Entwicklungsumgebung eine vollwertige permanente Test-DB einrichten müssen. Bei Letzteren könnte es eine gute Idee sein, eine separate Testsuite für End-to-End-Tests zu haben, die weniger häufig als Ihre normale Testsuite ausgeführt wird, da sie zwangsläufig langsamer ist. In diesem Szenario haben Sie bereits vorhandene Testdaten immer in der DB vorhanden und ein gesperrtes Objekt kann eines davon sein.

Wenn Sie sich nicht um all dies kümmern, können Sie die Datenspeicherabstraktion (Repository, DAO oder was auch immer) abbrechen, um ein vorspeicherndes gesperrtes Objekt zurückzugeben.