Die Mitarbeiter meines Unternehmens betrachten Unit-Tests als eine Menge zusätzlicher Arbeit, die weniger Vorteile bietet als die bestehenden funktionalen Tests. Sind Unit- und Integrationstests es wert? Beachten Sie eine große bestehende Codebasis, die nicht mit Blick auf Tests entwickelt wurde.
Antworten
Zu viele Anzeigen?Den meisten Menschen ist nicht bewusst, wozu automatisierte Einheitstests dienen:
- Experimentieren mit einer neuen Technologie
- Dokumentieren, wie ein Teil des Codes zu verwenden ist
- Damit ein toter Käfer tot bleibt
- Damit Sie den Code neu strukturieren können
- Damit Sie alle wichtigen Teile des Codes ändern können
- Schaffen Sie eine untere Wassergrenze, unter die die Qualität Ihres Produkts unmöglich fallen kann.
- Erhöhen Sie die Entwicklungsgeschwindigkeit, denn jetzt können Sie wissen dass etwas funktioniert (anstatt zu hoffen, dass es funktioniert, bis ein Kunde einen Fehler meldet).
Wenn also einer dieser Gründe für Sie von Vorteil ist, sind automatisierte Einheitstests genau das Richtige für Sie. Wenn nicht, dann verschwenden Sie Ihre Zeit nicht.
(Ich gehe davon aus, dass Sie mit "Funktionstest" einen Test meinen, bei dem das gesamte System oder die gesamte Anwendung in Betrieb ist).
Ich würde Unit-Test neu Funktionalität, wie ich sie geschrieben habe, aus drei Gründen:
- So komme ich schneller zu funktionierendem Code. Die Durchlaufzeit für "Unit-Test fehlgeschlagen, Code korrigiert, Unit-Test bestanden" ist im Allgemeinen ein Los kürzer als "Funktionstest fehlgeschlagen, Code korrigiert, Funktionstest bestanden".
- Es hilft mir, meinen Code sauberer zu gestalten.
- Es hilft mir, meinen Code zu verstehen und zu verstehen, was er tun soll, wenn ich ihn pflegen muss. Wenn ich eine Änderung vornehme, kann ich mich darauf verlassen, dass ich nichts kaputt gemacht habe.
(Dazu gehören auch Fehlerkorrekturen, wie von Epaga vorgeschlagen).
Ich empfehle nachdrücklich Michael Feathers' "Effizientes Arbeiten mit altem Code" um Ihnen Tipps zu geben, wie Sie mit Unit-Tests für eine Codebasis beginnen können, die nicht dafür konzipiert wurde.
Es hängt davon ab, ob Ihre funktionalen Tests automatisiert oder manuell durchgeführt werden. Wenn letzteres der Fall ist, dann ist jede Art von automatisierter Test-Suite nützlich, da die Kosten für die Durchführung dieser Unit-/Integrationstests weitaus geringer sind als für manuelle Funktionstests. Sie können hier einen echten ROI vorweisen. Ich würde empfehlen, mit dem Schreiben einiger Integrationstests zu beginnen, und wenn es die Zeit bzw. das Budget zulässt, dann auch Unit-Tests in Angriff zu nehmen.
Das nachträgliche Schreiben von Unit-Tests für Legacy-Code lohnt sich oft nicht. Bleiben Sie bei funktionalen Tests, und automatisieren Sie diese.
Dann haben wir die Richtlinie aufgestellt, dass alle Fehlerbehebungen (oder neue Funktionen) von Unit-Tests begleitet werden müssen, die zumindest die Behebung testen. Auf diese Weise kann man das Projekt zumindest in die richtige Richtung lenken.
Und ich muss Jon Skeet zustimmen (wie könnte ich nicht?) und empfehle " Effizientes Arbeiten mit altem Code "Es war wirklich hilfreich, es zu überfliegen/lesen.
Zufälligerweise habe ich gelesen ein Papier gestern Abend zu genau diesem Thema. Die Autoren vergleichen Projekte innerhalb von vier Gruppen bei Microsoft und IBM, wobei sie im Nachhinein Projekte, bei denen sowohl Unit-Tests als auch funktionale Tests eingesetzt wurden, mit Projekten vergleichen, bei denen nur funktionale Tests eingesetzt wurden. Um die Autoren zu zitieren:
"Die Ergebnisse der Fallstudien zeigen, dass die Vorabversion Fehlerdichte der vier Produkte zwischen 40% und 90% im Vergleich zu gegenüber ähnlichen Projekten, die nicht die TDD-Praxis. Subjektiv erlebten die Teams einen Anstieg von 15 bis 35 % bei der anfänglichen Entwicklungszeit nach der Einführung von TDD."
Dies zeigt, dass es sich auf jeden Fall lohnt, Unit-Tests durchzuführen, wenn Sie neue Funktionen zu Ihrem Projekt hinzufügen.
- See previous answers
- Weitere Antworten anzeigen