2008-12-29 8 views
16

Ich habe mich gefragt, wann die meisten Leute ihre Unit Tests geschrieben haben, wenn überhaupt. Ich schreibe normalerweise Tests, nachdem ich meinen ursprünglichen Code geschrieben habe, um sicherzustellen, dass es so funktioniert, wie es sein soll. Ich repariere dann, was kaputt ist.Schreiben Sie Ihre Komponententests vor oder nach der Codierung einer Funktion?

Ich war ziemlich erfolgreich mit dieser Methode, habe mich aber gefragt, ob es vielleicht vorteilhaft wäre, zuerst den Test zu schreiben?

+0

Siehe [are-you-really-using-unit?] (Http://stackoverflow.com/questions/286587/are-you-really-using-unit-tests) – nawfal

Antwort

35

wann immer möglich versuche ich einen reinen TDD Ansatz zu folgen:

  1. schreiben die Einheit für das Feature testet entwickelt; dies zwingt mich für eine bessere Abdeckung auf der öffentlichen Schnittstelle (n)
  2. Code die Funktion so schnell wie möglich (so einfach wie möglich, aber nicht einfacher)
  3. richtig/refactor/Retest
  4. zusätzliche Tests erforderlich, um zu entscheiden, ob, außergewöhnliche Pfade usw. [selten, aber eine Überlegung wert]
  5. Wiederholung mit dem nächsten Feature

es ist leicht, sich aufzuregen und ersten Codierung der Funktion starten, aber das bedeutet oft, dass Sie nicht durch alle die denken öffentliche Schnittstellen im Voraus.

EDIT: beachten Sie, dass, wenn Sie den Code zuerst schreiben, ist es einfach unbeabsichtigt schreiben Sie den Test, um den Code zu entsprechen, anstatt den anderen Weg 'rund!

+0

@Steven - das ist leicht die Beste Antwort hier. – tvanfosson

+0

Kent Becks Buch, Test-Driven Development, ist der beste Überblick über TDD. – Todd

+2

Sie sollten nicht zuerst alle Komponententests schreiben. Schreiben Sie nur genug von einem Komponententest, um einen Fehler zu erhalten, dann genug Produktionscode, um es zu bestehen, und dann (falls erforderlich) beide zu refaktorieren. Es sollte eine viel engere Schleife sein, als Sie hier angeben. –

1

Wir versuchen und schreiben sie vor der Hand, aber ich gebe voll und ganz zu, dass unsere Umgebung manchmal chaotisch ist, und manchmal wird dieser Schritt zunächst übergangen und später geschrieben.

0

Normalerweise schreibe ich eine Liste der Komponententests, die ich schreibe, bevor ich den Code schreibe und die Komponententests tatsächlich danach code, aber das ist, weil ich ein Programm verwende, um die Unit Test Stubs zu generieren und sie dann zu testen die passenden Fälle.

12

Ich wirklich wollen den Code zuerst schreiben, und oft tun. Aber je mehr ich echte TDD mache, wo ich mich weigere, irgendeinen Code ohne einen Test zu schreiben, desto mehr finde ich, dass ich mehr testbaren Code und besseren Code schreibe.

Also, ja, schreiben Sie zuerst den Test. Es braucht Willenskraft und Entschlossenheit, aber es bringt wirklich bessere Ergebnisse.

Als zusätzlichen Bonus hat TDD mir wirklich geholfen, in einer Umgebung mit Ablenkungen konzentriert zu bleiben.

0

Ich neige dazu, Komponententests zu verwenden, um den Code zu testen, während ich ihn schreibe. Auf diese Weise verwende ich das, was ich schreibe, da ich den Komponententest verwende, um Code zu testen, während ich ihn schreibe. Ähnlich wie eine Konsolen-App.

Manchmal habe ich sogar Tests geschrieben ohne behauptet, nur Debug-Ausgaben, nur um zu testen, dass, wie ich etwas verwende, funktioniert ohne Ausnahmen.

Also meine Antwort ist, nach ein wenig Codierung.

0

Ich benutze Test-Driven Development (TDD), um den Großteil meines Produktionscodes zu produzieren, also schreibe ich zuerst meine Komponententests, wenn ich nicht an nicht testbarem Legacy-Code arbeite (wenn der Balken zum Schreiben der Tests zu hoch ist).

Ansonsten schreibe ich funktionale Level-Abnahmetests, die der Code erfüllen soll.

Durch Schreiben der Komponententests kann ich genau wissen "wo ich bin": Ich weiß, dass das, was bisher codiert wurde, funktioniert und integriert oder an das Testteam gesendet werden kann; Es ist nicht fehlerfrei, aber es funktioniert.

4

Ich folge einem TDD-Ansatz, aber ich bin nicht so sehr puristisch wie einige. In der Regel werde ich in der Klasse/Methode mit einem Stub, der einfach eine NotImplementedException auslöst. Dann fange ich an, den Test (die Tests) zu schreiben. Ein Merkmal gleichzeitig, ein Test nach dem anderen. Oft werde ich feststellen, dass ich einen Test verpasst habe - vielleicht, wenn ich andere Tests schreibe oder wenn ich einen Fehler finde - dann gehe ich zurück und schreibe einen Test (und falls nötig den Bugfix).

Die Verwendung von TDD hilft dabei, Ihren Code in Einklang mit YAGNI zu halten (Sie werden es nicht brauchen), solange Sie nur Tests für Funktionen schreiben, die Sie entwickeln müssen UND nur den einfachsten Code schreiben, der Ihre Tests erfüllt.

0

Ich biete an, dass ich Schreibgeräte-Tests ziemlich neu bin und dass ich wünschte, ich hätte sie geschrieben, bevor ich meinen Code geschrieben habe. Oder zumindest ein besseres Verständnis davon, wie mehr testbarer Code geschrieben werden kann, sowie ein besseres Verständnis von Konzepten wie der Abhängigkeitsinjektion, die für das Schreiben von testbarem Code kritisch zu sein scheint.

0

Normalerweise schreibe ich Komponententests vor dem Code. Sie sind sehr nützlich und schreiben sie, bevor der Code nur Sinn ergibt. Die Abhängigkeitsinjektion eignet sich gut für Komponententests. Die Abhängigkeitsinjektion ermöglicht es, Teile Ihres Codes auszuspionieren, so dass Sie nur eine bestimmte Einheit testen, d. H. Ihr Code ist lose gekoppelt, und es ist daher leicht, ihn für eine andere (in diesem Fall verspottete) Implementierung auszutauschen.