Wie startet man Unit Testing oder TDD?

Zuerst testen /test nach:

Es sollte angemerkt werden, dass 'test first' als Teil von TDD ist einfach so viel (wenn nicht mehr) mit design zu tun als es zu tun mit unit-Tests. Es ist ein software-Entwicklungs-Technik, in seinem eigenen Recht-schreiben die Ergebnisse der Prüfungen in einem ständigen Verfeinerung des Designs.

Auf einem separaten beachten Sie: Wenn es einen signifikanten Vorteil zu TDD von einem reinen unit-Tests Perspektive ist es, dass es viel schwieriger (aber nicht unmöglich), einen test schreiben, das ist falsch, wenn dabei TDD. Wenn Sie schreiben, das vorher noch testen, sollte es immer scheitern, weil die Logik erforderlich, um die Prüfung zu machen pass ist noch nicht vorhanden. Wenn Sie schreiben, den test danach, der Logik sollte da sein, aber wenn der test verbuggt ist oder ist das testen der falschen Sache, kann es passieren, unabhängig.

I. e. wenn Sie schreiben, ein schlechter test vor, Sie können Holen Sie sich a grünes Licht, wenn Sie erwarten, einen roten (so dass Sie wissen, dass der test schlecht ist). Wenn Sie schreiben, einen schlechten test danach erhalten Sie ein grünes Licht, wenn Sie erwarten eine grüne (bewusst von den schlechten test).

Bücher

Die pragmatische Komponententests Buch ist auch einen Blick Wert, wie Roy Osherove ' s "The Art of Unit Testing". Die pragmatische Buch ist mehr eng fokussiert auf die verschiedenen Arten von test-Eingaben können Sie versuchen, Fehler zu finden, in der Erwägung, dass TAOUT deckt eine breitere Streuung der Themen wie test-doubles, Strategien, Wartbarkeit, etc. Entweder Buch ist gut; es hängt davon ab, was Sie von ihm wollen.

Auch hier ist eine link zu einem Vortrag von Roy Osherove hat auf unit-Tests. Es lohnt sich, eine Uhr (so sind einige der test-review-videos, die er aufgenommen, wie er betont, verschiedene Probleme und die dos/don ' TS zusammen mit Gründen, warum).

Wie zu Beginn

Gibt es nichts besseres, als das schreiben von code. Finden Sie eine ziemlich einfache Klasse, die nicht auf viel anderes. Dann schreiben beginnen einige tests.

Sich immer Fragen, "was will ich, um zu versuchen und beweisen mit diesem test?", bevor Sie es schreiben, dann gib ihm einen anständigen Namen (in der Regel mit der Methode, die aufgerufen wird, die Szenario und das erwartete Ergebnis, z.B. auf einem Stapel: "Pop WhenStackIsEmpty ThrowsException").

Denken alle Eingänge können Sie werfen es an, verschiedene Kombinationen von Methoden, die führen kann zu interessanten Ergebnissen, und so weiter.

InformationsquelleAutor der Antwort Mark Simpson

In C# und mit visual studio finde ich folgende Vorgehensweise sehr hilfreich:

1. Denken! Machen Sie ein kleines vorab-design. Sie müssen ein klares Bild, welche Klassen Sie benötigen und wie Objekte miteinander in Beziehung treten. Konzentrieren Sie sich nur auf eine Klasse/Objekt (der Klasse/Objekt, das Sie implementieren möchten) und eine Beziehung. Andernfalls Sie am Ende mit einer allzu schwere Ausführung. Ich bin oft am Ende mit mehreren Skizzen (nur ein paar Kästchen und Pfeile) auf ein Ersatz-Blatt Papier.

2. Erstellen Sie die Klasse in die Produktion von code und nennen Sie es entsprechend.

3. Pick Verhalten der Klasse, die Sie implementieren möchten, und erstellen Sie eine stub-Methode für Sie. Mit visual studio erstellen von leeren Methoden-stubs ist ein Stück Kuchen.

4. Einen test schreiben. Dafür müssen Sie initialisieren das Objekt, rufen die Methode und machen geltend machen, um das Ergebnis zu überprüfen. Im einfachsten Fall ist die Geltendmachung erfordert eine andere Methode der stub oder einer Eigenschaft in der Produktion von code.

5. Kompilieren Sie und lassen Sie die test-runner zeigen Sie die rote bar!

6. Code das erforderliche Verhalten in der Produktion code, um zu sehen, die grünen Balken erscheinen.

7. Bewegen, um die nächste Verhalten.

Für dieses Verfahren sind zwei Dinge sehr wichtig:

• Sie brauchen ein klares Bild, was Sie wollen und wie die Klasse/Objekt Aussehen soll. Mindestens verbringen einige Zeit es.
• Denken Sie über Verhaltensweisen der Klasse/Objekt. Dies macht die tests und die Produktion von code Verhalten-zentrisch, was einen sehr natürlichen Ansatz zum nachdenken über Klassen/Objekte.

Erst testen oder nicht testen Sie zuerst?

Ich finde es in der Regel schwieriger zu nachrüsten tests zu bestehenden Produktions-code. In den meisten Fällen ist dies aufgrund der Wirren Abhängigkeiten zu anderen Objekten, wenn das Objekt unter test initialisiert werden muss. TDD in der Regel vermeidet dies, weil Sie möchten, initialisieren Sie das Objekt in den test-Fällen mit weniger Aufwand wie möglich. Dies führt zu einer sehr losen Kopplung.

Wenn ich nachrüsten tests, die müssen mühselig Arbeit ist die Aufgabe initialisieren Sie das Objekt unter test. Auch die Behauptungen kann eine Menge Arbeit sein, weil der Wirren Abhängigkeiten. Für diese benötigen Sie zum ändern der Produktions-code und die Abhängigkeiten zerstören. Durch die Verwendung von dependency injection richtig, dies sollte kein Problem sein.

InformationsquelleAutor der Antwort Theo Lenndorff

Steve Sanderson hat einen großen Kommentar auf TDD best practices.

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

Außerdem gibt es eine große Reihe von tutorials für eine ASP.net mvc-Projekt erörtert, dass eine Menge TDD-Prinzipien (wenn es Sie nicht stört das lernen ASP.net MVC auf dem Weg)
http://www.asp.net/learn/mvc-videos/ Blick für das "Schaufenster" - Reihe am unteren Rand der Seite.

MOQ zu sein scheint, die-hot-mocking framework in letzter Zeit, möchten Sie vielleicht zu schauen, wie gut

In der Zusammenfassung, versuchen Sie, einen test schreiben zu validieren, etwas, das Sie ' uns ' re versuchen, zu archivieren, dann implementieren Sie den code, damit es funktioniert.

Das Muster ist bekannt als Red - Green - Refactor. Auch tun Ihr bestes, um Abhängigkeiten minimieren, so dass Sie Ihre tests konzentrieren sich auf eine Komponente.

Persönlich, ich benutze Visual Studio Unit-Tests. Ich bin kein hardcore-TDD-Entwickler, aber das, was ich mag zu tun ist:

1. Erstellen eines neuen Projekts und definieren ein paar der grundlegenden Klassen, basierend auf der system-design (so kann ich zumindest einige intellisense)
2. erstellen eines unit-tests Projekt und starten Sie das schreiben von unit-tests zu erfüllen, die Funktionalität, die ich bin versucht zu implementieren.
3. Machen Sie nicht
4. Machen Sie Sie gehen (Umsetzung)
5. Umgestalten
6. Wiederholen, versuchen Sie, um die Prüfung zu machen, die strenger oder erstellen Sie weitere tests, bis ich das Gefühl seiner festen.

Fühle ich auch seine sehr nützlich, um die Funktionalität hinzufügen, auf eine vorhandene code-Basis. Wenn Sie möchten, fügen Sie einige neue feature, erstellen Sie zunächst die unit-test für das, was Sie hinzufügen möchten, Schritt für Schritt durch den code, um zu sehen, was Sie ändern müssen, gehen Sie dann durch den TDD-Prozess.

InformationsquelleAutor der Antwort TJB

Ich würde auf TDD, test-first-Entwicklung, vor mocks und dependency injection. Um sicher zu sein, trotzt der Ihnen helfen kann, Ihre Einheiten besser zu isolieren und damit besser machen Einheit testen - aber meiner Meinung nach, Spott und DI sind mehr fortgeschrittene Konzepte, die stören können, mit der Klarheit nur zu schreiben, Ihre ersten tests.

Verspottet, und DI, haben Ihren Platz; Sie sind gute Instrumente, um in Ihren Werkzeugkasten. Aber Sie nehmen einige Raffinesse, eine erweiterte Verständnis, als die typischen Tests neophyte hat. Schreiben Sie Ihre ersten tests, jedoch genau so einfach, wie es klingt. So ist es einfacher, auf sich zu nehmen, und es ist mächtig alle von selbst (ohne verhöhnt und DI). Erhalten Sie die frühere, einfachere Gewinne durch das schreiben von mock-freie tests zuerst, als durch den Versuch, mit zu beginnen, verspottet, und TDD, und DI alles auf einmal.

Start mit test-first; wenn Sie sind sehr komfortabel mit es, und wenn Ihr code sagt Ihnen, Sie müssen mocks, dann nehmen verhöhnt.

InformationsquelleAutor der Antwort Carl Manaster

Sich auf Steve Freeman 's Antwort: Dave Astel' s Buch nennt sich "Test-driven Development - A practical guide". Wenn die Art der Anwendung, die Sie schreiben, ist eine GUI Anwendung, dann sollte dies hilfreich sein. Ich lese Kent Becks Buch, aber ich konnte nicht herausfinden, wie man ein Projekt mit TDD. Astel ' s book test-drives eine komplette nicht-triviale GUI-Anwendung von Anfang bis Ende Geschichten. Es hat mir sehr geholfen, um tatsächlich starten Sie mit TDD, zeigte Sie mir wo und wie ich anfangen soll.

InformationsquelleAutor der Antwort

Lesen Pragmatic Unit Testing in C# with NUnit. Es hat umfassende Informationen über die Gründung schreiben, Hoden und Strukturierung der code, damit es mehr unit-Tests freundlich.

InformationsquelleAutor der Antwort TheVillageIdiot

Ich lieber KentBeck Ansatz, das ist schön erklärt in dem Buch, Test-Driven Development by Example - Kent Beck.

aus Ihrer Frage kann ich ableiten, Sie sind sich nicht sicher, mit dem test-frame-Arbeit - bei der Auswahl der richtigen test-frame-Arbeit ist sehr wichtig für TDD oder schreiben von unit-tests(im Allgemeinen).

Einzige praktische problem mit TDD ist "Refactoring"(wir müssen Refactoring test code) nimmt sich viel Zeit.

InformationsquelleAutor der Antwort FL4SOF