Sollte ich eine "real-delete" -Methode auf DAO für den Integrationstest hinzufügen?

Question

Ich schreibe einige Integrationstests für einige Legacy-Code. Um sicherzustellen, dass sich die Funktionen wie erwartet verhalten, muss ich die gefälschten Daten einrichten, die Test-APIs aufrufen und dann die Daten bereinigen.

Aus Gründen der Richtlinien können wir nur über Tools wie Hibernate und MyBatis auf die Datenbank zugreifen, niemals direkte Verbindung. Allerdings ist unsere delete() Methode auf den DAOs immer von der Soft-Deletion-Stil (dh, schalten Sie die is_delete Flag.) Also die Aufräumarbeiten tatsächlich nur die is_delete Flagge, und die gefälschten Daten ist immer noch da!

Also, sollte ich eine "real-delete" -Methode auf den DAOs für die Integrationstests hinzufügen, oder gibt es eine bessere Möglichkeit, mit diesem Problem umzugehen?

Answer 1

Es ist nichts falsch daran, eine echte Löschmethode hinzuzufügen - schließlich besteht der Zweck eines Integrationstests darin, alle Komponenten zusammen zu testen, um sie so zu emulieren, wie sie tatsächlich verwendet werden.

Ich würde nur sicherstellen, dass wenn Sie dies tun, zuerst Datensätze hinzufügen, die Sie nicht Duplikate wissen werden. Dann können Sie bestätigen, dass diese Datensätze in der Datenbank vorhanden sind, löschen Sie sie und bestätigen Sie, dass sie nicht mehr vorhanden sind. Auf diese Weise stellen Sie sicher, dass Ihr Test niemals echte Daten löscht.