Ich teste gerade eine Fabrikklasse. Eine der Methoden muss die Daten in ein Array für ein Objekt laden, das von einer anderen Methode instanziiert wird.
Diese Methode enthält die SQL-Abfrage, die eine kritische Bedingung enthält, die getestet werden muss. (In diesem Fall fragen Sie nur nach den Aufzeichnungen, die "veröffentlicht" sind. Beispiel: WHERE veröffentlicht = 1). Diese Unterscheidung in der SQL-Abfrage ist das einzige Detail, das diese Methode von einer anderen unterscheidet, und ich möchte das Verhalten der Abfrageausführung testen.
Nun kann ich mein PDO-Objekt nicht wirklich verspotten und es um ein festes Ergebnis bitten, da ich die Ausführung der Abfrage nicht mit mySQL testen würde. Das wäre ein nutzloser Test.
Das führt mich zu der Annahme, dass ich eine statische Datenbank mit festen Testdaten einrichten muss. Habe ich recht damit oder habe ich etwas verpasst?
Sollte ich den Test, der die "Testdatenbank" erfordert, von den autonomen Tests trennen?
Ich stimme voll und ganz darin überein, die PDO nicht zu verspotten. Irgendwann möchte ich sicherstellen, dass meine Abfragen gegen eine echte Datenbank arbeiten. Dies könnte technisch gesehen kein Unit-Test mehr sein. Für mich bietet es so viel mehr zu wissen, dass mein Code, der Datenspeicher behandelt, wirklich gegen die db arbeitet.
Was ich tue, ist, eine Art Datenzugriffsklasse für jede Klasse zu erstellen, die mit der Datenbank kommunizieren muss und so den Großteil der Geschäftslogik vom Datenbankzugriffscode trennt.
Auf diese Weise kann ich den Datenzugriff beim Testen der Klassen ausspionieren und danach für jede "Datenzugriffsklasse" eine "Testdatenbank" einrichten und prüfen, ob diese funktioniert.
@zerkms Answer (+1) bereits verlinkt Ссылка und die einzige andere Ressource, die ich gefunden habe Wenn es um DB-Testing geht, ist das Buch Real-World Solutions for Developing High-Quality PHP Frameworks and Applications , das ein großes Kapitel zu diesem Thema enthält .
Soll ich den Test, der die "Testdatenbank" erfordert, von den autonomen Tests trennen?
Nur wenn Ihre Testsuite wirklich sehr groß wird und Sie Probleme mit der Laufzeit haben, die Sie zwingen zu sagen: "Selbst eine Testdatenbank zu schlagen dauert nur für alle meine Tests, also laufe ich diese nur auf einem Continuous Integration Server und nicht während der Entwicklung.
Ja, das ist gängige Praxis.
Es gibt auch spezielle Methoden zum Laden von Fixtures: Ссылка
Was ist mit der zweiten Frage: Nein, Sie sollten sie nicht trennen. Ihre Tests sollten das Verhalten und nicht die Details der Implementierung testen. Verknüpfen Sie Testfälle logisch mit Testklassen.