it-swarm.com.de

Wie groß muss mein Projekt sein, damit ich es testen kann?

Ich gehe davon aus, dass mein Projekt so weit entkoppelt ist, dass Unit-Tests möglich sind. Aber wie groß muss mein Projekt in Bezug auf Klassen und Funktionen genau sein, damit sich Unit-Tests lohnen?

Wir alle machen Fehler und niemand ist perfekt, aber ich betrachte mich als einen anständigen Programmierer, der die Fehler kleiner Projekte mit Durchgehen behandelt. Oder ist Unit-Test eine schwierige Notwendigkeit, unabhängig von der Größe Ihres Projekts?

87
Lamin Sanneh

Ihr Projekt ist bereits groß genug.

Nach meiner Erfahrung waren eine Klasse und eine Funktion ausreichend, um die Notwendigkeit von Komponententests zu berücksichtigen.

    class Simple {
        boolean reallySimple() {
            return true; // how do we make sure it doesn't change to false?
        }
    }


    class SimpleTest {
        void assertReallySimple() {
            // ensure reallySimple return value isn't changed unexpectedly
            UnitTestFramework.assertTrue(new Simple().reallySimple());
        }
    }
206
gnat

Ich habe mich nie für die Idee "Sie müssen alles testen" entschieden, obwohl es sicherlich Leute gibt, die dies haben (siehe Mückenantwort !).

Für mich sind die Hauptvorteile von Unit-Tests:

  1. Helfen Sie dabei, sicherzustellen, dass Änderungen keine Probleme verursachen.
  2. Unterstützung beim Entwerfen sinnvoller Schnittstellen zu Ihren Klassen (da Sie dadurch gezwungen sind, Client für Ihren eigenen Code zu sein).
  3. Hilft zu dokumentieren, wie Ihr Code voraussichtlich verwendet wird.

Grundsätzlich müssen Sie die Zeit abwägen, die Sie zum Schreiben und Verwalten von Tests gegen diese Faktoren benötigen.

Nummer 1 reicht normalerweise aus, um Tests zu schreiben. Nach meiner Erfahrung werden> 95% des Codes früher oder später geändert.

110
vaughandroid

Es ist ganz einfach: Sie müssen keine Unit-Tests durchführen, wenn Sie das Programm nach einmaliger Ausführung verwerfen.

Wenn Ihnen dies übertrieben erscheint, überlegen Sie, was die Alternative bedeuten würde. Wenn es eine Größe gäbe, unter der sich Unit-Tests nicht auszahlen, müssten Sie immer wieder darüber nachdenken: "Habe ich die magische Größe schon erreicht? Soll ich anfangen, Tests zu schreiben?" Jetzt sind Programmierer notorisch schlecht darin, die Zukunft vorherzusagen, und sie sind notorisch schlecht darin, ihre eigenen Fähigkeiten zu beurteilen. Code, der für Sie jetzt kristallklar aussieht, wird selbst für Sie unverständlich, selbst wenn Sie einen Monat warten. Ein Projekt, von dem Sie absolut sicher sind, dass es nie wieder verwendet wird, und das Sie nur bei der entfernten Chance behalten, dass Sie nachschlagen möchten, wie Sie etwas zuvor gelöst haben, wird erneut angefordert werden, und erhalten Änderungswünsche.

Es ist daher sehr wahrscheinlich, dass Sie falsch einschätzen, ob das Testen hilfreich ist oder nicht, und wenn Sie anfangen, Tests zu benötigen, sind Sie sich bereits nicht 100% sicher, wie genau die zu testende Semantik tatsächlich ist. Da ich der Meinung bin, dass alle außer trivialen einmaligen Programmen von Komponententests profitieren, halte ich die Kosten für den Aufwand für Tests, die nie wieder ausgeführt werden, für vernachlässigbar gegen das Risiko, nicht getesteten und nicht verstandenen Code zu erweitern.

34
Kilian Foth

Vor einiger Zeit habe ich einen schönen Beitrag gefunden: Warum Unit-Tests die Entwicklung beschleunigen . Es kann Ihnen helfen, die Frage zu beantworten.

... Was wäre, wenn die Codebasis ... mit einer Reihe von Unit-Tests versehen wäre? Ein Satz, der sagen würde: "Wenn alle Tests erfolgreich sind, garantiere ich, dass der Code immer noch das tut, was er tun sollte" und wenn ein Test fehlschlägt, zeigt er Ihnen genau, wo ein Verhalten fehlerhaft ist. Das ist großartig, ich könnte den Code ändern, um Dinge hinzuzufügen, die ich möchte, ohne zu wandern, wenn der Code immer noch das tut, was er tun soll. Ich führe nur die ... Tests aus und ich habe Vertrauen. Dies ist eine großartige Welt für Softwareentwickler. Mir ist aufgefallen, dass ich viel schneller vorankommen kann ...

Ich habe "Glauben".

Dies ist wahrscheinlich der wichtigste Grund, warum Komponententests die Entwicklung im Unternehmenskontext beschleunigen.

Ich kann darauf vertrauen, dass alles noch funktioniert, wenn alle Tests bestanden sind. Wenn Tests fehlschlagen, werden sie genau darauf hinweisen, wo das Problem liegt ...

... Sie müssen eine hohe Unit-Test-Abdeckung und gute Unit-Tests . Wenn diese Bedingungen eingehalten werden, befinden Sie sich in einer Situation, in der der Aufwand für das Hinzufügen neuer Funktionen nahezu unabhängig von der Größe der Anwendung ist und diese auf lange Sicht schneller wird Entwicklung .

Michael Feathers stellte in einem seiner Bücher zwei Möglichkeiten vor, mit Codeänderungen zu arbeiten:

  • bearbeiten und beten,
  • abdecken und modifizieren.

Es spielt keine Rolle, wie groß die Codebasis ist.

23
Marcin Sanecki

Laut Kent Beck in seiner Antwort auf die Frage zum Stapelüberlauf Wie tief sind Ihre Komponententests? sollten Sie den Code testen, bei dem Sie häufig Fehler machen.

Wenn ich normalerweise keinen Fehler mache (wie das Setzen der falschen Variablen in einem Konstruktor), teste ich nicht darauf.

19
Mansuro

Unit-Tests werden implementiert, um Zeit zu sparen und zu verbessern:

  • bug-Tracking
  • refactoring und/oder Umschreiben von Code
  • integrationstests
  • regressionstests usw.

Es ist ein Muss, Unit-Tests für relativ komplexe Teile des Programms zu schreiben.

Wenn Sie sicher sind, dass das Schreiben von Komponententests Ihre Zeit in Zukunft nicht spart, können Sie dies überspringen. Sie wissen es jedoch nie, und ich persönlich kann mir keinen Fall vorstellen, in dem es billiger ist (im Sinne von Zeit, Geld und Nerven), keine Komponententests zu schreiben, sondern alle Tests manuell durchzuführen.

5
superM

Wenn Sie keinen Code schreiben, ohne ihn zu testen, fallen immer die Kosten für das Testen an.

Der Unterschied zwischen Unit-Tests und Nicht-Tests besteht im Unterschied zwischen den Kosten für das Schreiben des Tests und den Kosten für dessen Durchführung im Vergleich zu den Kosten für das manuelle Testen.

Wenn die Kosten für das Schreiben eines Komponententests 2 Minuten und die Kosten für das Ausführen des Komponententests praktisch 0 betragen, die Kosten für das manuelle Testen des Codes jedoch 1 Minute betragen, können Sie die Gewinnschwelle erreichen, wenn Sie den Test zweimal ausgeführt haben.


Viele Jahre lang hatte ich das Missverständnis, dass ich nicht genug Zeit hatte, um Unit-Tests für meinen Code zu schreiben. Wenn ich Tests schrieb, waren sie aufgebläht, schwere Dinge, die mich nur ermutigten zu denken, dass ich Unit-Tests nur schreiben sollte, wenn ich wusste sie gebraucht wurden.

Kürzlich wurde ich ermutigt, Test Driven Development zu verwenden, und ich fand, dass dies eine vollständige Offenbarung ist. Ich bin jetzt fest davon überzeugt, dass ich nicht die Zeit habe nicht um unit- zu schreiben Tests.

Nach meiner Erfahrung erhalten Sie durch die Entwicklung unter Berücksichtigung von Tests sauberere Schnittstellen, fokussiertere Klassen und Module und im Allgemeinen mehr SOLIDEN , testbaren Code.

Jedes Mal, wenn ich mit Legacy-Code arbeite, der keine Komponententests enthält, und ich etwas manuell testen muss, denke ich immer wieder: "Dies wäre viel schneller, wenn dieser Code bereits Komponententests hätte." Jedes Mal, wenn ich versuchen muss, Code mit hoher Kopplung um Unit-Test-Funktionen zu erweitern, denke ich immer wieder: "Dies wäre viel einfacher, wenn es entkoppelt geschrieben worden wäre.".


TL; DR Version:

Schreiben Sie einen Test, wenn die Kosten für das Schreiben des Tests zuzüglich der Kosten für die Ausführung so oft wie nötig wahrscheinlich geringer sind als die Kosten für das manuelle Testen so oft wie Sie müssen.

Denken Sie jedoch daran, dass bei Verwendung von TDD die Kosten für das Schreiben von Tests wahrscheinlich sinken, wenn Sie besser werden. Wenn der Code nicht absolut trivial ist, werden Sie Ihre Tests wahrscheinlich häufiger ausführen als erwartet.

4
Mark Booth

Testen Sie, sobald Sie beobachten Sie, dass Regressionen auftreten oder befürchten, dass sie einige verursachen mit Ihren Änderungen und ohne es zu bemerken.

Zünden Sie diese Angst an und lassen Sie sie auf eine angemessene Größe anwachsen: Je früher Sie testen, desto besser.

Bitte beachten Sie: Abhängig von Ihrer Rolle im Projekt sind Unit-Tests möglicherweise nicht die einzige Art von Tests, die Sie schreiben möchten.

Jeder ist zu Recht besessen von Unit-Tests , weil in der Vergangenheit schlechte Mainstream-Testpraktiken angewendet wurden. Wenn Sie jedoch noch nie zuvor getestet haben, sollten Sie sich wirklich auf Tests im Allgemeinen konzentrieren . Unit-Tests allein lösen die Probleme der Welt nicht.

4
ZJR

"Sollte ich dies einem Unit-Test unterziehen?" Kann normalerweise durch Beantwortung der folgenden Frage beantwortet werden: "Ist es wichtig, dass diese Funktion ordnungsgemäß funktioniert, und ist es wichtig, dass ich weiß, wann sie nicht mehr funktioniert?"

Natürlich ist es viel komplizierter, aber das ist ein guter Anfang. Schließlich werden Sie auch abwägen, ob der Code bereits getestet wird, weil er in einer anderen Funktion verwendet wird, oder ob Ihre Zeit besser in einer anderen Funktion usw. verbracht wird.

4
Bryan Oakley

Ich glaube, dass es nicht die Größe des Projekts ist, sondern die Art des Projekts, die entscheidet, ob es Tests verwenden soll oder nicht.

Wenn Sie an einem Proof of Concept oder an einem anderen Projekt arbeiten, bei dem das Ziel darin besteht, aus der Codierung zu lernen, sind keine Tests erforderlich. Wenn das Projekt verwendet werden soll, vielleicht sogar in die Produktion geschickt werden soll, sollte es getestet werden.

Ein Zitat aus Robert C. Martins "Clean Code" : "Wenn das Schreiben trivial ist, ist das Testen trivial", daher gibt es keine Entschuldigung, das Testen für kurze und triviale Programme zu überspringen.

Es ist wirklich keine Frage der Größe - es ist das, was Sie damit machen (und wie alt es ist). Wenn ich lernen möchte, wie eine Technologie funktioniert, und vorhabe, das Ding wegzuwerfen (wir nennen dies eine Spitze in Scrum), codiere ich einfach, ohne viel zu testen. Wenn Sie vorhaben, es weiterzuentwickeln (auch wenn Sie nur herumnudeln), sollten Sie Tests rund um den Code schreiben. TDD ist eine Designtechnik, noch bevor es sich um eine Testtechnik handelt. Sie möchten ein klares Bild davon haben, was der Code tun soll, bevor Sie sich mit den Einzelheiten der Ausführung befassen. Ich würde auch NICHT empfehlen, umfangreiche Unit-Tests für große Mengen von Legacy-Code zu schreiben. Versuchen Sie, diejenigen Teile zu identifizieren, die komplex sind (eine hohe zyklomatische Komplexität/Spaghetti-Code-Haptik aufweisen) und diejenigen Teile, die häufig ausfallen (sie sind häufig gleich). Wie andere vorgeschlagen haben, würde ich Kent Becks Buch über TDD lesen und definitiv Michael Feathers Buch lesen. Was sie nicht sehr gut behandeln, ist der politische Aspekt beim Schreiben von Unit-Tests rund um Code. Viele Entwickler hassen es, ihren Code ändern zu müssen, um ihn testbar zu machen, und viele Entwickler haben nicht das Bedürfnis, Code überhaupt zu testen. Daran müssen wir als Beruf arbeiten. Jede andere technische Disziplin muss (oft mathematisch) nachweisen, dass ihre Arbeit der Spezifikation entspricht. Wir sollten das gleiche tun.

0
John Dahle