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

Ich gehe davon aus, dass mein Projekt ausreichend entkoppelt ist, um Unit-Tests zu ermöglichen. Aber wie groß muss mein Projekt in Bezug auf Klassen und Funktionen genau sein, damit sich das Testen von Einheiten lohnt?

Wir alle machen Fehler und niemand ist perfekt, aber ich betrachte mich als einen anständigen Programmierer, um die Fehler kleiner Projekte beim Durchstarten zu bewältigen. Oder ist Unit-Testing eine harte Notwendigkeit, egal wie groß Ihr Projekt ist?

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());
        }
    }

Ich habe mich noch nie für die Idee "Du musst alles testen" entschieden, obwohl es sicherlich Leute gibt, die das getan haben (siehe die Antwort der Mücke !).

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

1. Helfen Sie dabei, sicherzustellen, dass Änderungen nichts ändern.
2. Hilft Ihnen beim Entwerfen sinnvoller Schnittstellen zu Ihren Klassen (da Sie gezwungen sind, ein 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 benötigen, um Tests gegen diese Faktoren zu schreiben und aufrechtzuerhalten.

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

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

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 sich immer wieder überlegen: "Habe ich die magische Größe schon erreicht? Soll ich anfangen, Tests zu schreiben?" Jetzt sind Programmierer bekanntermaßen schlecht darin, die Zukunft vorherzusagen, und sie sind bekanntermaßen schlecht darin, ihre eigenen Fähigkeiten einzuschätzen. 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 bei dem Sie lediglich die entfernte Chance haben, nachzuschlagen, wie Sie etwas zuvor gelöst haben, wird erneut angefordert und es werden Änderungsanforderungen empfangen.

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 hundertprozentig sicher, welche Semantik tatsächlich zu testen ist. Da ich der Meinung bin, dass alle Programme mit Ausnahme trivialer Einmalprogramme von Unit-Tests profitieren, halte ich die Kosten für die Ausgaben für Tests, die nie wieder ausgeführt werden, für vernachlässigbar, da das Risiko besteht, nicht getesteten und nicht verstandenen Code zu erweitern.

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 einem umfangreichen Satz von Komponententests versehen wäre? Ein Satz, der sagen würde: „Wenn alle Tests erfolgreich sind , garantiere ich , dass Code immer noch tut , was es tun sollte , “ und wenn ein Test fehlschlägt es genau zeigt Ihnen , wo einige Verhalten gebrochen 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, in der man als Softwareentwickler sein kann. Mir ist aufgefallen, dass ich viel schneller vorankommen kann ...

Ich habe Vertrauen".

Dies ist wahrscheinlich der wichtigste Grund, warum Unit-Tests die Entwicklung im Unternehmenskontext beschleunigen.

Ich kann darauf vertrauen, dass alles noch funktioniert, wenn alle Tests erfolgreich sind. Wenn die Tests fehlschlagen, zeigen sie genau, wo das Problem liegt ...

... Sie müssen eine hohe Einheitentestabdeckung und gute Einheitentests haben . Wenn diese Bedingungen eingehalten werden, werden Sie feststellen, dass der Aufwand für das Hinzufügen neuer Funktionen fast unabhängig von der Größe der Anwendung ist und auf lange Sicht die Entwicklung beschleunigt .

Michael Feathers hat in einem seiner Bücher zwei Möglichkeiten vorgestellt, mit Änderungen im Code zu arbeiten:

• redigieren sie und beten sie,
• abdecken und modifizieren.

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

Laut Kent Beck in seiner Antwort auf die Frage zum Stapelüberlauf Wie tief sind Ihre Komponententests? , sollten Sie den Code testen, den Sie tendenziell falsch machen.

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

Unit-Tests werden durchgeführt, um Zeit zu sparen und Folgendes zu verbessern:

• Bug-Tracking
• Refactoring und / oder Neuschreiben von Code
• Integrationstests
• Regressionstests usw.

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

Wenn Sie sicher sind, dass das Schreiben von Unit-Tests in Zukunft keine Zeit spart, können Sie es überspringen. Sie werden es jedoch nie wissen, und ich persönlich kann mir keinen Fall vorstellen, in dem es günstiger ist (in Bezug auf Zeit, Geld und Nerven), Unit-Tests nicht zu schreiben, sondern alle Tests manuell durchzuführen.

"Sollte ich dies einmal testen" kann in der Regel durch Beantwortung der folgenden Frage beantwortet werden: "Ist es wichtig, dass diese Funktion ordnungsgemäß funktioniert, und ist es wichtig zu wissen, 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 für eine andere Funktion verwendet wird usw.

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-Unit-Tests ist der Unterschied zwischen den Kosten für das Schreiben und Ausführen des Tests und den Kosten für das manuelle Testen.

Wenn die Kosten für das Schreiben eines Komponententests 2 Minuten betragen 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 den Break Even erzielen, wenn Sie den Test zweimal ausgeführt haben.

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

Vor kurzem wurde ich ermutigt, Test Driven Development zu verwenden, und ich fand es eine vollständige Offenbarung. Ich bin jetzt fest davon überzeugt, dass ich nicht die Zeit habe, Unit-Tests nicht zu schreiben .

Wenn Sie mit Blick auf das Testen entwickeln, erhalten Sie meiner Erfahrung nach sauberere Schnittstellen, fokussiertere Klassen und Module und im Allgemeinen mehr SOLIDEN , testbaren Code.

Jedes Mal, wenn ich mit Legacy-Code arbeite, für den es keine Komponententests gibt, und ich etwas manuell testen muss, denke ich, dass dies viel schneller gehen würde, wenn für diesen Code bereits Komponententests vorhanden wären. Jedes Mal, wenn ich versuchen muss, dem Code mit hoher Kopplung Unit-Test-Funktionen hinzuzufügen, denke ich, dass dies so viel einfacher wäre, wenn er entkoppelt geschrieben worden wäre.

TL; DR- Version:

Schreiben Sie einen Test, wenn die Kosten für das Schreiben des Tests und die Kosten für das Ausführen des Tests so oft wie nötig geringer sind als die Kosten für das manuelle Testen so oft wie nötig.

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

Testen Sie , sobald Sie beobachten, dass Regressionen auftreten oder befürchten, dass einige durch Ihre Änderungen verursacht werden und Sie dies nicht bemerken.

Zünden Sie diese Angst an, lassen Sie es 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 von Unit-Tests besessen , weil in der Vergangenheit schlechte Mainstream-Testpraktiken praktiziert wurden. Aber wenn Sie noch nie zuvor getestet haben, sollten Sie sich wirklich auf das Testen im Allgemeinen konzentrieren . Unit-Tests allein werden die Probleme der Welt nicht lösen.

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

Wenn Sie an einem Proof of Concept oder an einem anderen Projekt arbeiten, bei dem das Ziel darin besteht, aus dem Coding zu lernen, ist ein Testen nicht erforderlich. Wenn das Projekt verwendet, vielleicht sogar in die Produktion geschickt werden soll, sollte es getestet werden.

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

Es ist wirklich keine Frage der Größe - es ist, was Sie damit machen (und wie alt es ist). Wenn ich mich damit beschäftige, zu lernen, 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 herumschnüffeln), sollten Sie Tests um den Code schreiben. TDD ist eine Konstruktionstechnik, noch bevor es eine Prüftechnik ist. Sie möchten ein klares Bild davon haben, was der Code tun soll, bevor Sie mit den Einzelheiten der Ausführung vertraut werden. Würde ich auch NICHTEs wird empfohlen, umfangreiche Komponententests mit großen Mengen an Legacy-Code zu schreiben. Versuchen Sie, die Teile zu identifizieren, die komplex sind (mit einer hohen zyklomatischen Komplexität / Spaghetti-Code-Gefühl), und die Teile, die häufig ausfallen (sie sind häufig gleich). Wie andere vorgeschlagen haben, würde ich Kent Becks Buch über TDD lesen und auf jeden Fall Michael Feders Buch lesen. Was sie nicht besonders 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. Alle anderen Ingenieurdisziplinen müssen (häufig mathematisch) nachweisen, dass ihre Arbeit den Spezifikationen entspricht. Wir sollten das Gleiche tun.

Es kann falsch sein, ein Projekt in Klassen- oder Funktionsgrenzen zu binden und dann zu beurteilen, ob dies für Unit-Tests geeignet ist. Es gibt zahlreiche Vorteile des Unit-Testens einer Anwendung, aber echte Schönheit beginnt, wenn Sie eine Anwendung warten oder in einer verteilten Umgebung arbeiten müssen. Die Wahl kommt also hierher. Selbst eine kleine Änderung Ihres Codes kann zu Katastrophen führen.
Ich würde nicht nur "Unit Testing" vorschlagen, sondern auch empfehlen, die Codeabdeckung zu überprüfen, um sicherzustellen, dass der maximale Umfang Ihres Codes durch Unit Test abgedeckt wird. Der Schwellenwert für die Codeabdeckung darf 95% nicht unterschreiten, und das Ziel muss bei 100% liegen . Sie können Tools verwenden, um die Codeabdeckung zu verfolgen und einen Bericht zu erstellen.
Visual Studio stellt Abdeckungsdaten bereit -http://msdn.microsoft.com/en-us/library/ms182496(v=vs.80).aspx
Sie können auch NCover oder dotCover verwenden.