Wie viel Zeit verbringen Sie mit Unit-Tests?

In einem Unternehmen, für das ich gearbeitet habe, bestanden die Führungskräfte darauf, dass die Codeabdeckung bei Unit-Tests mindestens 99% betragen muss. Dies führte dazu, dass mehr Tests als Code geschrieben wurden. Es dauerte buchstäblich 3 Tage, um Tests für eine einzelne Klasse zu schreiben, deren Implementierung einen Tag in Anspruch nahm.

Als Ergebnis habe ich jedoch viel über TDD, Testwerkzeuge, Praktiken usw. gelernt.

In der Firma, für die ich danach gearbeitet habe, war Unit Testing eine unbekannte Sache. Es war etwas, was jemand vielleicht schon einmal gehört hat. Ich hatte Mühe, sie in das Konzept des Unit-Testings einzuführen, aber ohne Wirkung.

Nun frage ich mich als Selbstständiger, wie viel Zeit wirklich für Unit-Tests benötigt wird? Als hauptsächlich iPhone / Android-Entwickler, welche Teile des Codes sollten in Tests abgedeckt werden?

Der Umfang der erforderlichen Einzelprüfungen hängt von mehreren Faktoren ab:

• Produktgröße (Je größer das Projekt ist, desto größer ist die Notwendigkeit, mindestens einige Komponententests durchzuführen.)
• Erforderliche Qualitätsstufe (Wenn Sie schnell Software zusammenstellen, die so schnell wie möglich veröffentlicht werden muss, und einige kleinere Fehler akzeptabel sind, müssen Sie möglicherweise einige Tests wie Unit-Tests überspringen.)
• Produkttyp (Benutzeroberflächen können Unit-getestet werden, manchmal ist es jedoch einfacher, Unit-Tests in umfangreichen GUI-Abschnitten eines Projekts zu überspringen und stattdessen manuell zu testen.)
• Ihre Codierungsfähigkeit / -historie (Welche Art von Fehlern verursachen Sie normalerweise? Sind es Dinge, die Unit-Tests normalerweise erkennen oder Dinge, die ein anderer Typ von Tests normalerweise findet? Wenn Sie wissen, dass Sie mehr oder weniger Unit-Tests durchführen müssen)

In unserer Produktgruppe streben wir eine Codeabdeckung von 50-70% aus Komponententests und eine Abdeckung von 90% aus Komponententests und Testautomatisierung zusammen an. Die für das Schreiben von Komponententests vorgesehene Zeit beträgt in der Regel etwa 1 Tag für jede Funktion, für die 3-4 Tage für die Heads-Down-Codierung erforderlich sind. Das kann aber mit vielen Faktoren variieren.

99% Code-Abdeckung ist großartig. Unit-Tests sind großartig. Aber eine Codeabdeckung von 99% allein durch Unit-Tests? Es fällt mir schwer zu glauben, dass Sie so viel Berichterstattung allein durch Unit-Tests erhalten können.

Für den Fall, dass Sie 3 Tage damit verbracht haben, Tests für eine Klasse zu schreiben, deren Implementierung ansonsten 1 Tag gedauert hat. Sie haben nicht herausgefunden, warum es so lange gedauert hat oder warum Sie Code geteilt haben. Aus Spekulationen schätze ich, dass Sie nicht wirklich einen echten Komponententest für Ihre Klasse geschrieben haben, sondern Testautomatisierung . Und daran ist eigentlich nichts auszusetzen - solange Sie den Unterschied zwischen den beiden verschiedenen Arten von Tests erkennen.

Aber Sie sagten, die drei Tage des Testschreibens waren nur für eine einzelne Klasse. Vielleicht war die Klasse selbst nicht für Unit-Tests gedacht. Implementiert die Klasse die Benutzeroberfläche? Vernetzung? Datei I / O? In diesem Fall haben Sie möglicherweise mehr Code zum Testen der Java-Laufzeit geschrieben als Ihre Geschäftslogik, die mit der Laufzeit interagiert.

TDD bringt Sie dazu, über Schnittstellen und Schnittstellen zu Abhängigkeiten nachzudenken. Diese einzelne Klasse, die die Benutzeroberfläche, das Netzwerk und file / io für ein einzelnes Feature implementiert, lässt sich möglicherweise besser in mehrere Klassen aufteilen - eine für das Netzwerk, eine für file / io und die in ein Modell-Viewer-Controller-Design aufgeteilte Benutzeroberfläche. Anschließend können Sie mit einfachen Mock-Objekten für die Abhängigkeiten jeweils entsprechende Tests implementieren. All dies nimmt natürlich mehr Zeit in Anspruch. Anstatt 1 Tag für die Codierung und 3 Tage für das Schreiben von Tests, kann diese Art von Design 3 Tage für die Codierung und 1 Tag für das Schreiben von Tests erfordern. Der Code ist jedoch weitaus besser wartbar und wiederverwendbar.

Unit-Tests zahlen sich zur Wartungszeit aus. Wenn Sie vorhaben, eine langlebige Anwendung zu haben, verbringen Sie mehr Zeit mit der Pflege als Sie jetzt denken (wenn Sie dies noch nicht ausprobiert haben, werden Sie überrascht sein, wie lange ein erfolgreiches Projekt noch bestehen kann).

Was Sie wollen, ist, dass, wenn Sie versehentlich Ihre Funktionalität ändern , Ihre Tests brechen, damit Sie diese Dinge so schnell wie möglich finden. Kunden mögen es nicht, wenn sich die Funktionalität unerwartet ändert.

Wenn Sie TDD durchführen, schreiben Sie die Tests gleichzeitig mit dem Code und wechseln zwischen ihnen alle paar Minuten (oder weniger). Es wird keine bestimmte Zeit für Tests aufgewendet. Durch die Verwendung von TDD wird es viel einfacher zu erkennen, dass Sie eine solide Testabdeckung haben.

Wenn Sie nachträglich Unit-Tests durchführen, müssen Sie die Tests schreiben, die Ihnen mitteilen, ob der Code aufgrund von Änderungen fehlerhaft ist. Ich würde mich hier nicht auf Coverage-Metriken verlassen, sondern auf Use Cases und Parameter für öffentliche Schnittstellen. Dies hängt letztendlich von Ihrem guten Geschmack und Ihrer Erfahrung ab.

Wenn Sie keine Zeit für Tests aufwenden, verbringen Sie noch mehr Zeit mit dem Debuggen von Live-Code.
So verbringen Sie so viel Zeit wie nötig mit Tests, um alle (oder 99% des Codes) abzudecken.

Wie bereits erwähnt, hängt dies weitgehend von der Art der Software ab. Das von Ihnen erwähnte 3: 1-Test- / Entwicklungszeitverhältnis ist für durchschnittliche Projekte möglicherweise etwas zu hoch, für geschäftskritische Apps jedoch durchaus in Ordnung und für ein lebenswichtiges System möglicherweise sogar zu niedrig.

Eine Testabdeckung von 99+% ist im Falle einer durchschnittlichen App ebenfalls zu viel, für ein lebenswichtiges Projekt jedoch zu wenig.

Wenn man bedenkt, dass ein erheblicher Teil des Produktionscodes Fehlerbehandlungscode ist, würde meiner Erfahrung nach eine Abdeckung von 80-90% für die meisten Apps ausreichen, und dies könnte ungefähr die gleiche Zeit erfordern, die für das Schreiben von Unit-Tests wie für Produktionscode aufgewendet wird. (Andererseits, wenn man ernsthaft auf TDD-Art arbeitet, sind die beiden völlig miteinander verflochten, um praktisch eine einzige Aufgabe zu werden, so dass man nur das tatsächliche Verhältnis schätzen kann.)