vorhandenen Code Umzug in Driven Development Test

Question

diese Methode der Entwicklung vor kurzem entdeckt hat, ich bin es eine ziemlich schöne Methode zu finden. Also, für mein erstes Projekt, habe ich den Wert einer kleinen DLL-Code (in C # .NET, für das, was es wert ist), und ich möchte eine Reihe von Tests für diesen Code machen, aber ich bin ein wenig verloren, wie und wo ich anfangen soll.

Ich bin mit NUnit und VS 2008, irgendwelche Tipps, welcher Art von Klassen mit zu beginnen, was für Tests zu schreiben, und alle Tipps im Allgemeinen, wie etwa Bewegen Code über gehen auf der Grundlage der Entwicklung testen würde sehr geschätzt .

Answer 1

Sehen Sie das Buch Effektives Arbeiten mit Legacy-Code von Michael Feathers.

Insgesamt ist es eine Menge Arbeit vorhandenen Code in prüfbar Refactoring und Code getestet; Manchmal ist es zu viel Arbeit, praktisch zu sein. Es hängt davon ab, wie groß die Code-Basis ist, und wie viel die verschiedenen Klassen und Funktionen voneinander abhängig ist.

Refactoring ohne Tests werden Veränderungen im Verhalten einzuführen (das heißt Bugs). Und Puristen werden sagen, dass es nicht wirklich vor sich Refactoring, weil der Mangel an Tests zu prüfen, ob das Verhalten nicht ändert.

Rather Test auf der ganzen Linie auf Ihre gesamte Anwendung auf einmal als Zugabe, Tests hinzufügen, wenn Sie in einem Gebiet von Code arbeiten. Höchstwahrscheinlich werden Sie wieder auf diese „Hotspots“ zurückkehren.

In Tests von unten nach oben. Testen wenig, unabhängige Klassen und Funktionen für die Richtigkeit

In Tests von oben nach unten: Test ganze Subsysteme als schwarzes Kästchen zu sehen, ob ihr Verhalten mit Änderungen im Code ändert. Und so kann man durch sie Schritt, um herauszufinden, was los ist. Dieser Ansatz wird Sie wahrscheinlich den größten Nutzen bringen.

Haben Sie keine allzu besorgt zunächst nicht mit dem, was die „richtige“ Verhalten ist, während Sie Tests hinzufügen, schauen, um Verhaltensänderungen zu erkennen und zu vermeiden. Große, nicht getesteten Systeme haben oft interne Verhaltensweisen, die falsch zu sein scheint, sondern dass andere Teile des Systems abhängig sind.

Denken Sie über Abhängigkeiten wie Datenbank, Dateisystem, Netzwerk zu isolieren, so dass sie für mock Datenanbieter während des Tests ausgelagert werden können.

Wenn das Programm keine internen Schnittstellen, Linien, die die Grenze zwischen einem Subsystem / Schicht und einem anderen definieren, dann können Sie versuchen, müssen diese und Test bei ihnen einzuführen.

Auch automatische spöttischen Frameworks wie RhinoMocks oder Moq könnte hier Mock vorhandenen Klassen helfen. Ich habe nicht wirklich die Notwendigkeit, dass sie im Code gefunden für Testbarkeit entworfen.

Answer 2

Effektives Arbeiten mit Legacy Code ist meine Bibel, wenn es um die Migration Code kommt ohne Tests zu einer Einheit geprüfte Umgebung, und es bietet auch eine Menge Einblicke in das, was macht Code einfach und zu testen, wie es zu testen.

Ich fand auch Test Driven Development von Beispiel und Pragmatische Unit Testing. mit NUnit C # in dieser Umgebung eine anständige Einführung in Unit-Tests sein

Ein einfacher Ansatz TDD zu starten ist das Schreiben von Tests beginnen erst von diesem Tag an und stellen Sie sicher, dass, wenn Sie benötigen, um Ihre vorhandenen (un-Einheit-geprüft) Code zu berühren, Sie Tests schreiben vorbei, das bestehende Verhalten des Systems überprüfen bevor Sie es ändern, so dass Sie diese Tests erneut ausführen können, nachdem Ihr Vertrauen zu erhöhen, dass Sie nichts gebrochen haben.

Answer 3

ich es "Test Driven Reverse Engineering" nennen.

Start „am unteren Rand“ - jede Klasse getrennt und ein Test für ihn geschrieben untersucht werden. Im Zweifelsfall raten.

Wenn Sie in Vorwärtsrichtung gewöhnliche TDD tun, behandeln Sie den Test als heilig und gehen davon aus, dass der Code wahrscheinlich gebrochen. Manchmal ist der Test falsch, aber Ihr Ausgang-Aus-Position ist, dass es der Code ist.

Wenn Sie TDRE tun, ist der Code heilig - bis Sie können beweisen , dass der Code eine langjährige Bug hat. Im umgekehrten Fall, schreiben Sie Tests rund um den Code, die Tests zwicken, bis sie arbeiten und behaupten, der Code funktioniert.

Dann können Sie in den schlechten Code graben. Einige schlechte Cade wird vernünftige Testfälle haben - dies muss nur gereinigt werden. Einige schlechten Code, jedoch werden auch einen Testfall, die sinnlos ist. Dies kann ein Problem sein, oder ungeschickt Design, das Sie in der Lage sein können, korrigieren.

Um zu beurteilen, ob der Code tatsächlich falsch ist, müssen Sie auch mit dem gesamten Testfällen an der Spitze beginnen. Live-Daten, die tatsächlich funktioniert, ist ein Anfang. Live-Daten auch, dass jede der bekannten Bugs, auch ein guter Ausgangspunkt erzeugt.

Ich habe wenig Code-Generatoren geschrieben, um Live-Daten in Unittest Fälle zu drehen. Auf diese Weise habe ich eine einheitliche Grundlage für die Prüfung und Refactoring.

Answer 4

Prüfbar Code ist leicht zu erkennen - durch die begleitenden Tests. Wenn es etwas gibt, muss es testbar sein. Wenn es keine gibt - das Gegenteil annehmen. ;)

Wie gesagt: Test Driven Development (TDD) ist nicht so sehr eine Teststrategie, da es eine Designstrategie ist. Die Tests, die Sie bei der Gestaltung der Schnittstelle Ihrer Klassen erste Hilfe zu schreiben, sowie in den Umfang Ihrer Klassen bekommen (oder Subsysteme für diese Angelegenheit) rechts.

Mit den Tests, die Sie während der TDD erstellt und Ausführung macht sie später gute Tests, aber nur ein (sehr willkommen) Nebeneffekt dieser Designphilosophie.

Dieser sagte, einen gewissen Widerstand aus dem Code erwarten gegen getestet. Hören Sie auf Ihren Code und ändern Sie die Schnittstelle, um leicht überprüfbar zu sein. Sie werden höchstwahrscheinlich es neu zu gestalten, wenn Sie das Schreiben von Tests starten.

Answer 5

Ihre DLL stellt eine Art von Service. Für jeden Dienst, was Sie haben, bevor man diesen Dienst zu tun, welche Parameter sollten Sie diesen Dienst übergeben zu bekommen, wie würden Sie wissen, dass der angeforderte Dienst korrekt ausgeführt werden?

Wenn Sie die Antworten auf diese Fragen haben, können Sie einen ersten Test schreiben. Solche Tests eher nennen würde Charakterisierungstests als Unit-Tests, aber wäre wahrscheinlich einfacher als Komponententests zu schreiben, wenn die DLL nicht TDD entwickelt wurde mit.

Charakterisierung Tests werden auch in M. Federn ‚Effektives Arbeiten mit Legacy Code‘ diskutiert, die in anderen Antworten empfohlen.

Auch sicher sein, eine fehlerhafte Prüfung zu schreiben, bevor sie eine neue Codezeile hinzuzufügen.