Was ist eine typische Schätzung für Codierungseinheitstests, wenn eine Schätzung für die Codierung neuer Funktionen gegeben wird? Ist das bei Schätzungen anders, um Code zu pflegen?Verhältnis der Zeit, die für die Codierung im Vergleich zur Einheitsprüfung aufgewendet wurde
Meine Zeit ist ungefähr gleich zwischen Zeit für Komponententests und Zeit für Funktionscode.
Einige Leute würden dies betrachten und sagen, dass es Zeitverschwendung ist, aber wenn Ihre einzige andere Option ist, die App zu starten und alle möglichen Pfade zu durchlaufen, die die App nehmen kann, dann ist die Zeit für Unit-Tests tatsächlich weniger als die Zeit, die Sie für Entwickler testen würden. Natürlich, wenn Sie nicht viel Entwickler testen, werden Sie die Zeit damit verbringen, Fehler zu beheben, die von QA zurückkommen.
In jedem Fall spart die Zeit, die für das Schreiben des Einheitentests benötigt wird, tatsächlich Zeit von der Menge, die ich für das Projekt ausgeben würde.
Wenn es an der Zeit ist, den Code zu pflegen (leichte Änderungen, kleine Ergänzungen in der Funktionalität), könnte es einen Unterschied geben. Wenn der Code, der geändert wird, bereits vollständig abgedeckt ist und Ihre Änderungen keine Änderungen an den Tests erfordern, ist Ihre Zeit 0. Sonst ist es offensichtlich nicht, wahrscheinlich ist es wieder gleich.
Aber Ihre Zeiteinsparungen in der Testzeit ist viel größer; Sie haben die Tests bereits erstellt, um den Rest des Codes abzudecken, sodass Sie alle zufälligen Änderungen, die sich aus Ihrer Änderung ergeben, ohne neuen Code aufdecken oder die App ausführen.
Ich würde sagen, ich verbringe etwa 50% der Zeit Codiereinheit Tests. es ist schwer, außer aus eigener Erfahrung, es ist Gewinn zu messen, aber ich finde es drei wesentliche Vorteile bietet:
Ich finde, dass es je nach variiert auf dem Code, mit dem Sie arbeiten - wenn Sie etwas von Grund auf schreiben, testgesteuert, dauert es wahrscheinlich ungefähr die gleiche Zeit, um die Funktion zu implementieren, als ohne Tests, aber Sie sparen längerfristig die Menge der Fehler, die gefunden werden Wie einfach können Sie diese Codebasis beibehalten und erweitern? Man könnte argumentieren, dass es in diesem Fall schneller ist, mit Tests zu schreiben, da Sie die Kopf kratzenden Momente vermeiden, in denen der Code sich nicht wie erwartet verhält und Sie einen Debugger verwenden müssen, um herauszufinden, was passiert Änderungsset, das TDD normalerweise erlaubt.
Wenn Sie versuchen, Features auf einer vorhandenen "Legacy" -Code-Basis zu implementieren (wie Michael Feathers Legacy definieren würde), dauert es oft wesentlich länger, das Feature mit Tests zu implementieren als ohne, aufgrund der Menge an Ein sorgfältiges Refactoring, das vor dem Schreiben von Tests durchgeführt werden muss, ist normalerweise möglich. In diesem Fall werden Schreibgeräte-Tests immer noch von langfristigem Nutzen sein, aber Sie müssen darüber nachdenken, ob dieser langfristige Nutzen für die unmittelbaren Kosten gerechtfertigt ist.
Im Allgemeinen würde ich immer auf irgendeine Art von automatisiertem Testen drängen, ob Einheit oder Funktion, trotz der zusätzlichen Kosten für Legacy-Code-Basen. Ohne sie werden Sie wahrscheinlich mit einer Code-Basis konfrontiert, die sehr schwierig zu warten ist und ständige, sich wiederholende manuelle Tests erfordert, um sicherzustellen, dass sie weiterhin funktioniert, mit häufigen Regressionen.