Frage

Hat jemand gute Tipps zum Schreiben von Testcode für die Datenbank-Backend-Entwicklung, bei der eine starke Abhängigkeit vom Status besteht?

Insbesondere möchte ich Tests für Code schreiben, der Datensätze aus der Datenbank abruft, aber die Antworten hängen von den Daten in der Datenbank ab (die sich im Laufe der Zeit ändern können).

Erstellen die Leute normalerweise ein separates Entwicklungssystem mit einer „eingefrorenen“ Datenbank, sodass jede bestimmte Funktion immer genau die gleiche Ergebnismenge zurückgeben sollte?

Ich bin mir ziemlich sicher, dass dies kein neues Problem ist, daher wäre ich sehr daran interessiert, aus den Erfahrungen anderer zu lernen.

Gibt es gute Artikel, die sich mit diesem Thema der webbasierten Entwicklung im Allgemeinen befassen?

Normalerweise schreibe ich PHP-Code, aber ich gehe davon aus, dass alle diese Probleme weitgehend sprach- und rahmenunabhängig sind.

War es hilfreich?

Lösung

Sie sollten sich DBUnit ansehen oder versuchen, ein PHP-Äquivalent zu finden (es muss eines geben).Sie können damit die Datenbank mit einem bestimmten Datensatz vorbereiten, der Ihre Testdaten darstellt, sodass jeder Test nicht mehr von der Datenbank und einem vorhandenen Status abhängt.Auf diese Weise ist jeder Test in sich geschlossen und wird bei weiterer Datenbanknutzung nicht unterbrochen.

Aktualisieren:Eine schnelle Google-Suche ergab ein Erweiterung der DB-Einheit für PHPUnit.

Andere Tipps

Wenn Sie sich hauptsächlich mit dem Testen der Datenschicht befassen, sollten Sie sich dieses Buch ansehen: xUnit-Testmuster:Testcode umgestalten.Ich selbst war mir immer unsicher, aber dieses Buch leistet hervorragende Arbeit und hilft dabei, Bedenken wie Leistung, Reproduzierbarkeit usw. aufzuzählen.

Ich denke, es hängt davon ab, welche Datenbank Sie verwenden, aber Red Gate (www.red-gate.com) stellt ein Tool namens SQL Data Generator her.Dies kann so konfiguriert werden, dass Ihre Datenbank mit sinnvoll aussehenden Testdaten gefüllt wird.Sie können es auch anweisen, in seinem Zufallszahlengenerator immer denselben Startwert zu verwenden, sodass Ihre „Zufallsdaten“ jedes Mal dieselben sind.

Anschließend können Sie Ihre Komponententests schreiben, um diese zuverlässigen, wiederholbaren Daten zu nutzen.

Was das Testen der Website betrifft, schaue ich mir derzeit Selenium an (selenium.openqa.org).Dies scheint eine browserübergreifende Testsuite zu sein, die Ihnen beim Testen der Funktionalität hilft.Wie bei all diesen Website-Testtools gibt es jedoch keine wirkliche Möglichkeit, die Qualität dieser Dinge zu testen sehen in allen Browsern, ohne ein menschliches Auge darauf zu werfen!

Wir verwenden eine In-Memory-Datenbank (hsql: http://hsqldb.org/).Ruhezustand (http://www.hibernate.org/) macht es uns leicht, unsere Unit-Tests auf die Test-Datenbank auszurichten, mit dem zusätzlichen Vorteil, dass sie blitzschnell ausgeführt werden.

Ich habe genau das gleiche Problem mit meiner Arbeit und finde, dass die beste Idee darin besteht, ein PHP-Skript zu haben, um die Datenbank neu zu erstellen, und dann ein separates Skript, in dem ich verrückte Daten hineinwerfe, um zu sehen, ob es sie kaputt macht.

Ich habe noch nie Unit-Tests oder ähnliches verwendet und kann daher nicht sagen, ob es funktioniert oder nicht.

Wenn Sie die Datenbank vor der Durchführung der Tests mit einer bekannten Menge einrichten und am Ende wieder herunterfahren können, wissen Sie, mit welchen Daten Sie arbeiten.

Dann können Sie etwas wie Selenium verwenden, um einfach von Ihrer Benutzeroberfläche aus zu testen (wir gehen hier davon aus, dass sie webbasiert ist, aber es gibt viele UI-Testtools für andere UI-Varianten) und das Vorhandensein bestimmter aus der Datenbank abgerufener Datensätze zu erkennen.

Es lohnt sich auf jeden Fall, entweder eine Testversion der Datenbank einzurichten – oder Ihre Testskripte die Datenbank im Rahmen der Tests mit bekannten Daten zu füllen.

Du könntest es versuchen http://selenium.openqa.org/ Es dient eher dem GUI-Testen als einer Datenschicht-Testanwendung, zeichnet jedoch Ihre Aktionen auf, die dann wiedergegeben werden können, um Tests auf verschiedenen Plattformen zu automatisieren.

Hier ist meine Strategie (ich verwende JUnit, bin mir aber sicher, dass es eine Möglichkeit gibt, das Äquivalent in PHP durchzuführen):

Ich habe eine Methode, die vor allen Unit-Tests für eine bestimmte DAO-Klasse ausgeführt wird.Es versetzt die Entwicklungsdatenbank in einen bekannten Zustand (fügt alle Testdaten hinzu usw.).Während ich Tests durchführe, verfolge ich alle Daten, die zum bekannten Status hinzugefügt werden.Diese Daten werden am Ende jedes Tests bereinigt.Nachdem alle Tests für die Klasse ausgeführt wurden, entfernt eine andere Methode alle Testdaten in der Entwicklungsdatenbank und belässt sie in dem Zustand, in dem sie sich vor der Ausführung der Tests befand.Es ist ein bisschen Arbeit, das alles zu erledigen, aber ich schreibe die Methoden normalerweise in eine DBTestCommon-Klasse, auf die alle meine DAO-Testklassen zugreifen können.

Ich würde vorschlagen, drei Datenbanken zu verwenden.Eine Produktionsdatenbank, eine Entwicklungsdatenbank (gefüllt mit einigen aussagekräftigen Daten für jeden Entwickler) und eine Testdatenbank (mit leeren Tabellen und möglicherweise ein paar Zeilen, die immer benötigt werden).

Eine Möglichkeit, Datenbankcode zu testen, ist:

  1. Fügen Sie einige Zeilen ein (mit SQL), um den Status zu initialisieren
  2. Führen Sie die Funktion aus, die Sie testen möchten
  3. Vergleichen Sie die erwarteten mit den tatsächlichen Ergebnissen.Hier können Sie Ihr normales Unit-Testing-Framework verwenden
  4. Bereinigen Sie die geänderten Zeilen (damit bei der nächsten Ausführung die vorherige Ausführung nicht angezeigt wird).

Die Bereinigung könnte auf herkömmliche Weise (natürlich nur in der Testdatenbank) erfolgen DELETE * FROM table.

Im Allgemeinen stimme ich Peter zu, aber zum Erstellen und Löschen von Testdaten würde ich SQL nicht direkt verwenden.Ich bevorzuge die Verwendung einer CRUD-API, die im Produkt verwendet wird, um Daten zu erstellen, die der Produktion möglichst ähnlich sind ...

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top