Wie beginnt man mit Unit-Tests oder TDD?

Question

Ich habe viele Beiträge gelesen, die mich davon überzeugt haben, dass ich anfangen sollte, Unit-Tests zu schreiben. Ich habe auch angefangen, Dependency Injection (Unity) zu verwenden, um das Mocking zu vereinfachen, aber ich bin mir immer noch nicht ganz sicher, auf welcher Stufe ich anfangen sollte, die Unit-Tests und Mocks zu schreiben, und wie oder wo ich anfangen soll.

Wäre es besser, die Unit-Tests vor den Methoden zu schreiben, wie in der TDD-Methodik beschrieben?

Gibt es eine andere Methodik oder Vorgehensweise für Unit-Tests?

Answer 1

Erst testen / dann testen:

Es sollte beachtet werden, dass "Test first" als Teil von TDD genauso viel (wenn nicht mehr) mit Design zu tun hat wie mit Unit-Tests. Es ist eine eigenständige Softwareentwicklungstechnik - das Schreiben der Tests führt zu einer ständigen Verfeinerung des Designs.

Auf einer separaten Anmerkung: Wenn es einen bedeutenden Vorteil zu TDD aus einer reinen Unit-Testing-Perspektive gibt, ist es, dass es viel schwieriger (wenn auch nicht unmöglich) ist, einen Test zu schreiben, der falsch ist, wenn man TDD macht. Wenn Sie den Test im Voraus schreiben, sollte er immer fehlschlagen, weil die zum Bestehen des Tests erforderliche Logik noch nicht existiert. Wenn Sie den Test nachträglich schreiben, wird die Logik sollte vorhanden sein, aber wenn der Test fehlerhaft ist oder das Falsche testet, kann er trotzdem bestehen.

Wenn Sie also vorher einen schlechten Test schreiben, kann es sein, dass Sie ein grünes Licht bekommen, obwohl Sie ein rotes erwarten (Sie wissen also, dass der Test schlecht ist). Wenn Sie danach einen schlechten Test schreiben, erhalten Sie ein grünes Licht, obwohl Sie ein grünes erwartet haben (ohne zu wissen, dass der Test schlecht ist).

Bücher

Das pragmatische Unit-Testing-Buch ist einen Blick wert, ebenso wie Roy Osheroves "The Art of Unit Testing". Das pragmatische Buch ist enger auf die verschiedenen Arten von Testeingaben fokussiert, die Sie versuchen können, um Fehler zu finden, wohingegen TAOUT ein breiteres Spektrum an Themen abdeckt, wie z.B. Testdopplungen, Strategien, Wartbarkeit usw. Beide Bücher sind gut; es kommt darauf an, was Sie von ihnen erwarten.

Außerdem ist hier ein Link zu einem Vortrag von Roy Osherove über Einheitstests . Es lohnt sich, den Film anzuschauen (ebenso wie einige der von ihm aufgezeichneten Testvideos, in denen er auf verschiedene Probleme und Do's/Don'ts sowie auf die Gründe dafür hinweist).

Wie man beginnt

Es gibt nichts Besseres als Code zu schreiben. Suchen Sie sich eine recht einfache Klasse, die auf nicht viel anderes verweist. Beginnen Sie dann, einige Tests zu schreiben.

Fragen Sie sich immer: "Was will ich mit diesem Test versuchen und beweisen?", bevor Sie ihn schreiben, und geben Sie ihm dann einen vernünftigen Namen (der in der Regel die aufgerufene Methode, das Szenario und das erwartete Ergebnis beinhaltet, z. B. auf einem Stapel: "Pop WhenStackIsEmpty ThrowsException").

Denken Sie an alle Eingaben, die Sie machen können, an verschiedene Kombinationen von Methoden, die interessante Ergebnisse liefern können, und so weiter.

Answer 2

Wenn Sie neugierig auf Unit-Tests sind, lernen Sie sie am besten, indem Sie sie ausprobieren. Wahrscheinlich werden Sie zunächst Integrationstests schreiben, aber das ist in Ordnung. Wenn sie Ihnen zu schwierig oder zu arbeitsaufwändig erscheinen, lesen Sie mehr über die verschiedenen Arten von Tests (Unit-, Funktions- und Integrationstests) und versuchen Sie, den Unterschied zu erkennen.

Wenn Sie daran interessiert sind, mit TDD zu beginnen, ist Uncle Bob eine gute Quelle. Partikulär diese .

Mehr über Unit-Tests

Stellen Sie sicher, dass Sie konsistente Testergebnisse erhalten. Die wiederholte Durchführung desselben Tests sollte stets zu denselben Ergebnissen führen.

Die Tests sollten keine Konfiguration erfordern.

Die Reihenfolge der Tests sollte keine Rolle spielen. Das bedeutet, dass partielle Testläufe korrekt funktionieren können. Wenn Sie diese Entwurfsphilosophie im Hinterkopf behalten, wird sie Ihnen wahrscheinlich bei der Erstellung von Tests helfen.

Denken Sie daran, dass jede Prüfung besser ist als keine Prüfung. Die Schwierigkeit besteht darin, gute, saubere Einheitstests zu schreiben, die die Erstellung und Wartung erleichtern. Je schwieriger der Testrahmen ist, desto größer ist die Ablehnung, ihn einzusetzen. Testen ist Ihr Freund.

Answer 3

In C# und mit Visual Studio finde ich folgende Vorgehensweise sehr hilfreich:

1. Denken! Machen Sie einen kleinen Entwurf im Voraus. Sie müssen ein klares Bild davon haben, welche Klassen Sie brauchen und wie die Objekte zueinander in Beziehung stehen sollen. Konzentrieren Sie sich nur auf eine Klasse/ein Objekt (die Klasse/das Objekt, das Sie implementieren wollen) und eine Beziehung. Andernfalls entsteht ein zu schwerfälliger Entwurf. Ich habe oft mehrere Skizzen (nur ein paar Kästchen und Pfeile) auf einem freien Blatt Papier.

2. Erstellen Sie die Klasse im Produktionscode und benennen Sie sie entsprechend.

3. Wählen Sie eine Verhaltensweise der Klasse, die Sie implementieren möchten, und erstellen Sie einen Methoden-Stub für diese. Mit Visual Studio ist das Erstellen leerer Methoden-Stubs ein Kinderspiel.

4. Schreiben Sie einen Test dafür. Dazu müssen Sie das Objekt initialisieren, die Methode aufrufen und eine Assert erstellen, um das Ergebnis zu überprüfen. Im einfachsten Fall erfordert die Behauptung einen weiteren Methoden-Stub oder eine Eigenschaft im Produktionscode.

5. Kompilieren Sie und lassen Sie sich vom Test Runner den roten Balken zeigen!

6. Codieren Sie das erforderliche Verhalten im Produktionscode, damit der grüne Balken erscheint.

7. Gehen Sie zum nächsten Verhalten über.

Bei diesem Verfahren sind zwei Dinge sehr wichtig:

• Sie brauchen eine klare Vorstellung davon, was Sie wollen und wie die Klasse/das Objekt aussehen soll. Verbringen Sie zumindest einige Zeit damit.
• Denken Sie über die Verhaltensweisen der Klasse/des Objekts nach. Dadurch werden die Tests und der Produktionscode verhaltensorientiert, was ein sehr natürlicher Ansatz ist, um über Klassen/Objekte nachzudenken.

Erst testen oder nicht testen?

Ich finde es in der Regel schwieriger, Tests in bestehenden Produktionscode einzubauen. In den meisten Fällen ist dies auf verworrene Abhängigkeiten zu anderen Objekten zurückzuführen, wenn das zu testende Objekt initialisiert werden muss. TDD vermeidet dies in der Regel, da man das Objekt in den Testfällen mit möglichst wenig Aufwand initialisieren möchte. Dies führt zu einer sehr losen Kopplung.

Wenn ich Tests nachrüste, ist die mühsamste Aufgabe die Initialisierung des zu testenden Objekts. Auch die Assertions können aufgrund von verworrenen Abhängigkeiten viel Arbeit machen. Hierfür müssen Sie den Produktionscode ändern und Abhängigkeiten aufbrechen. Durch den richtigen Einsatz von Dependency Injection sollte dies kein Problem darstellen.

Answer 4

はい。 bevorzugt TDD besteht darin, den Test zuerst zu schreiben (wie der Name schon sagt). Testgetriebene Entwicklung ). Wenn man mit TDD anfängt, kann es schwierig sein zu wissen, wo man mit dem Schreiben der Tests beginnen soll, daher würde ich vorschlagen, pragmatisch vorzugehen. Schließlich besteht der wichtigste Teil unserer Arbeit darin, funktionierenden Code zu liefern, und nicht so sehr darin, wie der Code erstellt wurde.

Sie können also damit beginnen, Tests für vorhandenen Code zu schreiben. Wenn Sie erst einmal herausgefunden haben, wie die Unit-Tests strukturiert sind, welche Tests gut funktionieren und welche weniger gut, dann wird es Ihnen leichter fallen, sich mehr auf den Test-First-Ansatz einzulassen. Ich habe festgestellt, dass ich im Laufe der Zeit immer mehr Tests zuerst schreibe. Mit zunehmender Erfahrung wird es einfach natürlicher.

Answer 5

Steve Sanderson hat einen großartigen Bericht über TDD Best Practices.

http://feeds.codeville.net/~r/SteveCodeville/~3/DWmOM3O0M2s/

Auch gibt es eine große Reihe von Tutorials für die Durchführung eines ASP.net MVC-Projekt, dass eine Menge TDD Prinzipien diskutiert (wenn Sie nichts dagegen haben, lernen ASP.net MVC auf dem Weg) http://www.asp.net/learn/mvc-videos/ Achten Sie auf die Serie "Schaufenster" am Ende der Seite.

MOQ scheint in letzter Zeit das angesagte Mocking-Framework zu sein, das sollten Sie vielleicht auch in Betracht ziehen

Zusammenfassend lässt sich sagen, dass Sie versuchen sollten, einen Test zu schreiben, um etwas zu validieren, das Sie zu archivieren versuchen, und dann den Code zu implementieren, damit es funktioniert.

Das Muster ist bekannt als Rot - Grün - Refactor. Bemühen Sie sich auch, Abhängigkeiten zu minimieren, damit sich Ihre Tests auf eine Komponente konzentrieren können.

Ich persönlich verwende Visual Studio Unit Tests. Ich bin kein Hardcore-TDD-Entwickler, aber was ich gerne tue, ist dies:

1. Erstellen Sie ein neues Projekt und definieren Sie einige der grundlegenden Klassen auf der Grundlage des Systementwurfs (auf diese Weise kann ich zumindest etwas Intellisense erhalten)
2. ein Unit-Tests-Projekt erstellen und mit dem Schreiben von Unit-Tests beginnen, um die Funktionalität zu erfüllen, die ich zu implementieren versuche.
3. Lass sie scheitern
4. Lassen Sie sie passieren (umsetzen)
5. Refactor
6. Ich wiederhole, versuche, den Test strenger zu gestalten oder weitere Tests zu erstellen, bis ich das Gefühl habe, dass er solide ist.

Ich denke auch, dass es sehr nützlich ist, Funktionen zu einer bestehenden Codebasis hinzuzufügen. Wenn Sie eine neue Funktion hinzufügen möchten, erstellen Sie zunächst den Unit-Test für das, was Sie hinzufügen möchten, gehen Sie den Code durch, um zu sehen, was Sie ändern müssen, und führen Sie dann den TDD-Prozess durch.