Wie pflegen Menschen ihre Testsuite?

Insbesondere bin ich neugierig auf folgende Aspekte:

1. Woher wissen Sie, dass Ihre Testfälle falsch (oder veraltet) sind und repariert (oder verworfen) werden mussten? Ich meine, selbst wenn ein Testfall ungültig würde, könnte er dennoch bestehen und still bleiben, was Sie fälschlicherweise glauben lassen könnte, dass Ihre Software in Ordnung funktioniert. Wie erkennen Sie solche Probleme in Ihrer Testsuite?

2. Woher wissen Sie, dass Ihre Testsuite nicht mehr ausreicht und dass neue Testfälle hinzugefügt werden sollten? Ich denke, dies hat etwas mit den Änderungen der Anforderungen zu tun. Gibt es jedoch einen systematischen Ansatz, um die Angemessenheit der Testsuite zu überprüfen?

Kurze Antwort: Verwenden Sie bekannte Tools, mit denen die Qualität von Testfällen aufrechterhalten werden kann, z. B. die folgenden Tools zur Codeabdeckung und -qualität: Cobertura, PMD, Sonar usw., mit denen Sie feststellen können, wenn eine kritische Komponente des Programms nicht ausreichend getestet wird. Schreiben Sie außerdem Integrationstests, bei denen die Wahrscheinlichkeit am größten ist, dass sie zuerst unterbrochen werden, wenn ein Fehler auftritt.

Lange Antwort:

Woher wissen Sie, dass Ihre Testfälle falsch (oder veraltet) sind und repariert (oder verworfen) werden mussten? Ich meine, selbst wenn ein Testfall ungültig würde, könnte er dennoch bestehen und stumm bleiben, was Sie fälschlicherweise glauben lassen könnte, dass Ihre Software in Ordnung funktioniert. Wie erkennen Sie solche Probleme in Ihrer Testsuite?

• Mit Codeabdeckungstools wie Cobertura können Sie feststellen, dass Testfälle für eine bestimmte Klasse oder komplexe Methoden nicht mehr ausreichen. Sie müssen nicht überall eine Codeabdeckung von 100% erreichen, und in den meisten Fällen ist dies schwierig und nicht unbedingt sinnvoll. Tests für die kritischsten Aspekte eines Programms sollten jedoch mit einem Ziel von mindestens 80% der Codeabdeckung durchgeführt werden.
• Mit fortlaufenden Build- und Integrationstools wie Jenkins, die ich sehr mag, in Kombination mit dem Sonar- Plugin können Sie Auslöser festlegen, die E-Mails und andere Arten von Warnungen an Personen senden, die für die neuesten Änderungen verantwortlich sind. Verschiedene Grafiken und Statistiken (Sonar verwendet neben vielen anderen Tools auch Cobertura) helfen Code-Reviewern und Testfall-Entwicklern, sich auf das Wesentliche zu konzentrieren.

Woher wissen Sie, dass Ihre Testsuite nicht mehr ausreicht und dass neue Testfälle hinzugefügt werden sollten? Ich denke, dies hat etwas mit den Änderungen der Anforderungen zu tun. Gibt es jedoch einen systematischen Ansatz, um die Angemessenheit der Testsuite zu überprüfen?

Was ich für die erste Frage geschrieben habe, ist Teil der Antwort auf Ihre zweite Frage. Ich werde hier auch die folgenden Punkte hinzufügen:

• Schreiben Sie zusätzlich zu den Testfällen auch Integrationstestfälle (oder "Business" -Fälle, wenn Sie dies vorziehen). Diese ändern sich am wahrscheinlichsten zuerst, da sie häufig von mehreren Klassen / Methoden abhängen. Und da sie oft brechen, ist es weniger wahrscheinlich, dass sie vergessen werden. Der einzige Ansatz / die einzige Methode, die meiner persönlichen Erfahrung nach dazu beiträgt, gute Tests zu schreiben, ist die testgetriebene Entwicklung . Insbesondere, wenn die Person, die den Testfall schreibt, NICHT dieselbe Person ist, die den Code dafür schreibt. Gute Testfälle mit TDD zu schreiben, braucht ebenfalls Zeit, aber die Ergebnisse waren zumindest für mich äußerst zufriedenstellend.
• Wenn ein Fehler auftritt, schreiben Sie den Fix und den Testfall, der damit geliefert wird. Der Testfall sollte nur diesen bestimmten Fehler abdecken. Da Sie den Code, der für den Fehler verantwortlich ist, vollständig abgedeckt haben, sollte er nicht erneut ausgegeben werden.

Es gibt wirklich keine Möglichkeit, sicherzustellen , dass Ihre Testfälle korrekt sind, es sei denn, Sie konzentrieren sich beim Erstellen richtig auf die Anforderungen, verstehen den Code und stellen sicher, dass sie übereinstimmen. Der Sinn einer Testsuite besteht darin, dass Sie dies nur einmal tun müssen. Von da an können Sie die Tests erneut ausführen und prüfen, ob sie bestanden wurden, während Sie sich ohne eine Testsuite die ganze Zeit sehr konzentrieren müssten , dh wann immer Sie irgendetwas an Ihrer Codebasis tun. Das grundlegende Problem, dass Sie sicherstellen müssen, dass Sie das Richtige tun, bleibt jedoch bestehen - Computer sind einfach nicht intelligent genug, um uns von dieser Aufgabe zu entlasten.

Daher gibt es (1) keine einfache Möglichkeit, dies zu erkennen, wenn Ihre Testsuite unvollständig ist. Eine Code-Coverage-Analyse kann nachweisen, dass einige Codezeilen niemals ausgeführt werden, dh dass die Suite in irgendeiner Weise fehlerhaft ist, jedoch nicht, wie schwerwiegend dieser Fehler ist, und kann niemals nachweisen, dass er ausreichend ist. Selbst bei 100% Codeabdeckung können Sie nicht garantieren, dass alle relevanten Zustände vorliegendes Systems ausgeübt werden, und eine vollständige staatliche Abdeckung ist für jedes realistische System aufgrund der kombinatorischen Anzahl von Staaten, die existieren könnten, nicht erreichbar. Eine gute Methode, um sicherzustellen, dass Ihr Testfall für die Überprüfung der zu überprüfenden Elemente mindestens korrekt ist, besteht darin, den Test zu schreiben, zu überprüfen, ob er tatsächlich fehlschlägt, den Code zu schreiben / zu ändern und dann zu überprüfen, ob er jetzt erfolgreich ist. Daher die Begeisterung für testgetriebene Entwicklung: Sie können sicher sein, dass ein einzelner Test das Richtige tut, und wenn Sie Ihre gesamte Codebasis auf diese Weise erstellen, können Sie auch in einem großen System ein ähnliches Maß an Vertrauen erzielen.

(2) Eine Testsuite wird normalerweise unzureichend, wenn sich die Anforderungen ändern - Sie müssen nicht raten. Wenn der Kunde möchte, dass ein bestimmtes Verhalten geändert wird und Ihre Tests sowohl vor als auch nach der Änderung erfolgreich sind, haben sie diese bestimmte Eingabe / Ausgabe-Beziehung offensichtlich nicht ausgeübt.

Bei Legacy-Systemen ohne Testabdeckung oder wenn Sie nicht wissen, wie die Abdeckung ist, gibt es keinen formalen Beweis, aber (Hinweis für Eltern: persönliche Meinung folgt!) Aus Erfahrung ist es mit überwiegender Wahrscheinlichkeit möglich, dass die Tests durchgeführt werden sind nicht ausreichend. Wenn das Testen als eine nachträgliche, optionale, qualitätssteigernde, aber nicht wirklich notwendige Aktivität betrachtet wird, ist es in der Regel unvollständig und unsystematisch, da der Anreiz, sicherzustellen, dass die Tests mit der Codebasis Schritt halten, nicht gegeben ist nicht da.