Benötigen wir Testdaten oder können wir uns auf Unit-Tests und manuelle Tests verlassen?

Wir arbeiten derzeit an einem mittleren / großen PHP / MySQL-Projekt. Wir führen Unit-Tests mit PHPUnit & QUnit durch und haben zwei Vollzeit-Tester, die die Anwendung manuell testen. Unsere Testdaten (Mock-Daten) werden derzeit mit SQL-Skripten erstellt.

Wir haben Probleme mit der Verwaltung von Skripten für Testdaten. Die Geschäftslogik ist ziemlich komplex und eine "einfache" Änderung der Testdaten führt häufig zu mehreren Fehlern in der Anwendung (die keine echten Fehler sind, sondern nur das Produkt ungültiger Daten). Dies ist für das gesamte Team zu einer großen Belastung geworden, da wir ständig Tabellen erstellen und ändern.

Ich sehe keinen Sinn darin, die Testdaten in den Skripten zu verwalten, da mit der Benutzeroberfläche alles in etwa 5 Minuten manuell in die Anwendung eingefügt werden kann. Unser PM ist anderer Meinung und sagt, dass es eine schlechte Praxis ist, ein Projekt zu haben, das wir nicht mit Testdaten bereitstellen können.

Sollten wir die Wartung der Skripte mit Testdaten abbrechen und die Tester die Anwendung ohne Daten testen lassen? Was ist die beste Vorgehensweise?

— Christian P.
quelle

Antworten:

Sie mischen zwei verschiedene Konzepte. Eine davon ist die Überprüfung , die auf Unit-Tests und Peer Reviews basiert. Dies kann von den Entwicklern selbst ohne Testdaten durchgeführt werden, und es soll überprüft werden, ob eine Reihe von Anforderungen erfüllt sind.

Die zweite ist die Validierung , und dies wird von der Qualitätssicherung (Ihren Testern) durchgeführt. Für diesen Schritt benötigen Sie Testdaten, da der Tester keine Kenntnisse über die Programmierung in der Anwendung haben muss, sondern nur die beabsichtigten Anwendungsfälle. Ziel ist es zu überprüfen, ob sich die Anwendung in einer Produktionsumgebung wie beabsichtigt verhält.

Beide Prozesse sind wichtig und notwendig, um dem Kunden ein Qualitätsprodukt zu liefern. Sie können sich nicht allein auf Unit-Tests verlassen. Was Sie herausfinden müssen, ist eine zuverlässige Methode, um Ihre Testdaten zu verarbeiten und ihre Gültigkeit sicherzustellen.

EDIT: OK, ich verstehe, was Sie fragen. Die Antwort lautet Ja, da der Tester nicht die Aufgabe hat, die Testdaten zu generieren, sondern nur die Anwendung zu testen. Sie müssen Ihre Skripte so erstellen, dass eine einfachere Wartung möglich ist und gültige Daten eingefügt werden. Ohne die Testdaten hat der Tester nichts zu testen. Having said that, aber wenn Sie Zugriff auf die Testumgebung haben , ich sehe nicht , warum Sie können Sie nicht die Testdaten manuell eher einsetzen als mit Hilfe von Skripten.

— AJC
quelle

Vielleicht habe ich meine Frage falsch gestellt, indem ich die Unit-Tests und Testdaten erwähnt habe. Ich verstehe, dass die Validierung nicht mit Unit-Tests identisch ist. Mein Problem hierbei ist, dass die Testdaten, die wir mit den Skripten erstellen, in 5 Minuten über die Benutzeroberfläche erstellt werden können. Um diese Daten in die Anwendung einzufügen, müssen Sie keine Programmierkenntnisse haben, sondern nur die Testfälle befolgen.

— Christian P

@ christian.p überprüfe mein Update bezüglich deiner Klärung der Frage.

— AJC

Ihre Lösung besteht also darin, die Skripte abzubrechen und nur manuell Testdaten über die Benutzeroberfläche hinzuzufügen? Was ist mit der Antwort von P.Brian.Mackey und seinen Antworten auf die Kopplung der Daten mit der Benutzeroberfläche?

— Christian P

@ christian.p Nun, ich stimme zu, dass Sie Skripte verwenden sollten. ABER es gibt keine Formalität oder Regel, die besagt, dass Sie müssen. Der Hauptgrund für die Verwendung von Skripten zum Generieren von Scheindaten ist die Geschwindigkeit (Automatisierung) und der Zugriff (auf die Testumgebung). Wenn Sie Zugriff haben und es schneller und einfacher ist, dies manuell zu tun, gibt es keinen Grund, warum Sie dies nicht tun können. (ABER führen Sie ein Protokoll der Daten, mit denen Sie getestet haben).

— AJC

Jeder Tester hat seine eigene Testumgebung und Tester lassen die Datenbank mehrmals täglich vollständig fallen. Daher ist es unpraktisch, Testdaten manuell hinzuzufügen. Wir können sie jedoch höflich bitten, einige Daten zum Testen hinzuzufügen.

— Christian P

Ja, Unit-Tests und Datenmodelle sind eine bewährte Methode. Der Projektmanager ist korrekt. Da eine "einfache" Änderung der Testdaten häufig zu Fehlern führt, ist dies der Kern des Problems.

Der Code muss verbessert werden. Dies nicht zu tun (zu sagen, hey, wir brauchen keine Tests) ist keine Lösung, das bedeutet einfach, technische Schulden hinzuzufügen . Teilen Sie den Code in kleinere, besser testbare Einheiten auf, da es ein Problem ist, Einheiten ohne Bruch nicht identifizieren zu können.

Starten Sie einen Refactor. Halten Sie die Verbesserungen klein, damit sie überschaubar sind. Suchen Sie nach Anti-Mustern wie Gottesklassen / -methoden, die nicht DRY, Einzelverantwortung usw. folgen.

Schauen Sie sich zum Schluss TDD an , um zu sehen, ob es für das Team funktioniert. TDD funktioniert gut, um sicherzustellen, dass Ihr gesamter Code testbar ist (weil Sie die Tests zuerst schreiben) und um sicherzustellen, dass Sie schlank bleiben, indem Sie gerade genug Code schreiben, um die Tests zu bestehen (Minimierung über das Engineering hinaus).

Wenn eine Reihe komplexer Geschäftslogikprozesse einen Datensatz erzeugt, sehe ich dies im Allgemeinen als Bericht an. Kapsel den Bericht. Führen Sie den Bericht aus und verwenden Sie das resultierende Objekt als Eingabe für den nächsten Test.

— P.Brian.Mackey
quelle

Ich muss die Dinge ein wenig klären: "Einfache Änderung der Testdaten führt zu Fehlern" - das Problem liegt hier nicht in der Anwendung - die App funktioniert einwandfrei, wenn die Daten gültig sind (und Sie können ungültige Daten nicht manuell hinzufügen). . Das Problem hierbei ist, dass ungültige Testdaten Fehler verursachen können, wenn versucht wird, diese Daten zu bearbeiten. Also müssen wir auch die Testdaten testen?

— Christian P

Lassen Sie sich nicht von einem Irrtum des roten Herings stolpern. Die Tatsache, dass die Testdaten einen Fehler verursachen, ist insgesamt ein anderes Problem. Das Entfernen von Tests ist keine Lösung, "die Regierung regieren" ist auch etwas ganz anderes. Das Problem ist der Code. Es ist nicht testbar, weil Sie uns mitteilen, dass Sie keine Tests schreiben können, die keine Probleme verursachen. Deshalb müssen Sie den Code verbessern.

— P.Brian.Mackey

Vielleicht hast du meine Frage falsch verstanden. Wir haben Unit-Tests und jede neue Funktionalität, die wir schreiben, hat Unit-Tests. Ich schlage nicht vor, dass wir Tests entfernen, die nicht bestanden werden, oder dass wir überhaupt keine Tests schreiben. Ich schlage nur vor, dass wir die Skripte nicht zum Erstellen von Scheindaten in der Datenbank verwenden, da die manuellen Tester dasselbe tun.

— Christian P

"Ich sehe keinen Sinn darin, die Testdaten in den Skripten zu pflegen." <- Das Löschen der Testunterstützung ist das, was ich sage. Keine Löschung alter Tests. Es ist eine schlechte Idee. Sie verringern die Reproduzierbarkeit und koppeln sich an eine Benutzeroberfläche, die genau das ist, was Sie testen möchten, und können sich an Änderungen anpassen. Entkoppeln Sie sich von der Benutzeroberfläche. Behalten Sie die Datenautomatisierung bei.

— P.Brian.Mackey

Aber wie gehen wir das Problem ungültiger Scheindaten an? Wenn wir weiterhin Scheindaten für die Datenbank erstellen, wie überprüfen wir, ob die Scheindaten in Ordnung sind oder nicht? Wenn die Geschäftsregel diesen Wert X = 2 erfordert und die Datenbank X = 100 akzeptiert - wie können wir die Integrität der Testdaten überprüfen, wenn die Geschäftsregel komplex ist?

— Christian P

Dies ist ein sehr häufiges und auch sehr schwieriges Problem. Automatisierte Tests, die für eine Datenbank ausgeführt werden (selbst für eine In-Memory-Datenbank wie HSQLDB ), sind normalerweise langsam, nicht deterministisch und, da ein Testfehler nur darauf hinweist, dass irgendwo in Ihrem Code oder in Ihren Daten ein Problem vorliegt, sind sie es nicht viel informativ.

Nach meiner Erfahrung besteht die beste Strategie darin, sich auf Komponententests für die Geschäftslogik zu konzentrieren. Versuchen Sie, so viel wie möglich von Ihrem Kerndomänencode abzudecken. Wenn Sie dieses Teil richtig machen, was selbst eine ziemliche Herausforderung darstellt, erzielen Sie das beste Kosten-Nutzen-Verhältnis für automatisierte Tests. Was die Persistenzschicht betrifft, investiere ich normalerweise viel weniger Aufwand in automatisierte Tests und überlasse sie dedizierten manuellen Testern.

Wenn Sie jedoch Persistenztests wirklich automatisieren möchten (oder müssen), würde ich Ihnen empfehlen, Growing Object-Oriented Software, Guided by Tests, zu lesen . Dieses Buch enthält ein ganzes Kapitel über Persistenztests.

— Otavio Macedo
quelle