Wie der Kopf sagt, nachdem ich einige Zeilen (nur zum Testen) in die Datenbank in einer Unit-Test-Funktion eingefügt habe, stelle ich derzeit eine Abfrage am Ende von die Funktion, um diese manuell zu entfernen, aber ich glaube, das ist nicht die beste Vorgehensweise zu tun. Also was ist das?Was ist die beste Methode zum Reinigen von Daten nach dem Einfügen für einen Komponententest
Nun, bei der Arbeit an Data Fixtures ist vielleicht die beste Option setUp() und tearDown() Methoden zu implementieren.
Wenn Sie externe Ressourcen wie Dateien, Datenbanken oder Sockets zugewiesen haben, scheint tearDown() Methode der beste Weg zu gehen.
Von PHPUnit docs:
setUp() und tearDown() sind in der Theorie schön symmetrisch, aber nicht in Praxis. In der Praxis müssen Sie nur tearDown() implementieren, wenn Sie in setUp() externe Ressourcen wie Dateien oder Sockets zugewiesen haben. Wenn Ihre setUp() nur einfache PHP-Objekte erstellt, können Sie allgemein ignorieren tearDown(). Wenn Sie jedoch viele Objekte in Ihrer setUp() erstellen, möchten Sie möglicherweise die Variablen aufheben, die auf diese Objekte in Ihrer tearDown() zeigen, so dass sie Garbage Collected sein können. Die Speicherbereinigung von Testfallobjekten ist nicht vorhersehbar.
Sie können weitere Informationen Daten-Befestigungen in Chapter 4. Fixtures erhalten:
"Best practice" ist immer eine subjektive Anfrage. Es ist wahrscheinlich nicht die beste Praxis, echte Dienste zu nutzen, aber ich tue es, weil es realistisch ist, dass es für mich am besten funktioniert. Durch die Verwendung von echten Diensten teste ich tatsächlich gegen alle Arten von datenbankspezifischen Minutien (wie Fremdschlüsseleinschränkungen, Trigger usw.).
Sie könnten eine Datenbanktransaktion erstellen, Ihre SQL-Abfragen ausführen und dann die Transaktion zurücksetzen. Aber um dies zu tun, müssen Sie zwei Annahmen:
Implizite Commits für MySQL sind, according to its documentation wie folgt:
'ALTER TABLE', 'CREATE INDEX', 'DROP INDEX', 'DROP TABLE', ‚RENAME TABLE ‘ 'CREATE TABLE' 'CREATE DATABASE' 'DROP DATABASE' 'TRUNCATE TABLE', 'ALTER PROCEDURE' 'CREATE PROCEDURE' 'PROCEDURE', 'ALTER FUNCTION', 'CREATE FUNCTION', 'DROP FUNCTION', 'ALTER VIEW', 'CREATE TRIGGER', 'CREATE VIEW', 'DROP TRIGGER', ‚DROP VIEW‘, 'CREATE USER', 'DROP USER', 'RENAME USER'
Unit-Tests sollten mit echten Dienste normalerweise nicht in Wechselwirkung treten: die übliche Praxis * mock sie ist * statt. – eggyal
Ruby on Rails verwendet Transaktionen, um Änderungen rückgängig zu machen, die während des Tests vorgenommen wurden. – tadman
Ehrlich gesagt bevorzuge ich die Interaktion mit realen Diensten, da es eher ein genauer "Test" ist - und da Rollback-Transaktionen nur Autoinkremente beeinflussen und Autoinkremente niemals eine Logik haben sollten, rationalisiere ich, dass es in Ordnung ist Starten Sie eine Transaktion, führen Sie einen Test durch, und führen Sie dann die Transaktion am Ende der Transaktion zurück. Achten Sie nur auf SQL-Abfragen, die Transaktionen durch Auslösen impliziter Commits (wie "ALTER") unterbrechen. Aber während ich das tue, bin ich mir nicht sicher, ob es das beste Verfahren ist. –