Sollten Komponententests geschrieben werden, bevor der Code geschrieben wird?

Question

Ich weiß, dass eines der grundlegenden Prinzipien der Test-getriebenen Entwicklung ist, dass Sie zuerst Ihre Komponententests schreiben und dann Code schreiben, um diese Komponententests zu bestehen, aber ist es notwendig, dies auf diese Weise zu tun?

Ich habe festgestellt, dass ich oft nicht weiß, was ich teste, bis ich es geschrieben habe, hauptsächlich weil die letzten paar Projekte, an denen ich gearbeitet habe, eher aus einem Proof of Concept entwickelt wurden .

habe ich versucht, vor meinen Unit-Tests zu schreiben und es kann nützlich sein, aber es mir nicht natürlich erscheinen.

Answer 1

Einige gute Kommentare hier, aber ich denke, dass eine Sache ignoriert wird.

Schreiben Tests fährt zuerst Ihr Design. Dies ist ein wichtiger Schritt. Wenn Sie die Tests "zur gleichen Zeit" oder "bald danach" schreiben, fehlen Ihnen möglicherweise einige Designvorteile, TDD in Mikroschritten auszuführen.

Es fühlt sich wirklich auf dem ersten kitschig, aber es ist erstaunlich, was vor Ihren Augen in ein Design entfalten zu sehen, dass man nicht von ursprünglich dachte. Ich habe es gesehen.

TDD ist hart, und es ist nicht für jedermann. Aber wenn Sie Unit-Tests bereits kennen, dann probieren Sie es für einen Monat aus und sehen Sie, was es zu Ihrem Design und Ihrer Produktivität führt.

Sie verbringen weniger Zeit im Debugger und mehr Zeit darüber nachzudenken, von außen nach innen Design. Das sind zwei gigantische Pluspunkte in meinem Buch.

Answer 2

Nicht immer, aber ich finde, dass es wirklich hilft, wenn ich es tue.

Answer 3

Ich neige dazu, sie zu schreiben, während ich meinen Code schreibe. Am besten werde ich die Tests schreiben, wenn die Klasse/das Modul existiert, bevor ich es schreibe.

ich nicht weit genug vor, dass viel Detail planen einen Test vor dem Code zu schreiben, um es testen wird.

Ich weiß nicht, ob dies ein Fehler in meinem Denken oder Methode des oder einfach nur TIMTOWTDI.

Answer 4

Ich schreibe nicht zuerst die eigentlichen Komponententests, aber ich mache eine Testmatrix, bevor ich mit der Codierung aller möglichen Szenarien beginne, die getestet werden müssen. Ich mache auch eine Liste von Fällen, die getestet werden müssen, wenn eine Änderung an irgendeinem Teil des Programms im Rahmen von Regressionstests vorgenommen wird, die die meisten grundlegenden Szenarien in der Anwendung abdecken, zusätzlich zum vollständigen Testen des Code-Teils geändert.

Answer 5

Es gab studies, die zeigen, dass Komponententests, die nach dem Schreiben des Codes geschrieben wurden, bessere Tests sind. Der Nachteil ist jedoch, dass die Leute nicht dazu neigen, sie nach dem Event zu schreiben. TDD ist also ein guter Kompromiss, da zumindest die Tests geschrieben werden.

Also, wenn Sie Tests schreiben, nachdem Sie Code geschrieben haben, gut für Sie, ich würde vorschlagen, dass man sich daran halten.

Ich neige dazu, dass ich eine Mischung mache. Je mehr ich die Anforderungen verstehe, desto mehr Tests kann ich vorschreiben. Wenn die Anforderungen - oder mein Verständnis des Problems - schwach sind, tendiere ich dazu, Tests zu schreiben.

Answer 6

Ich beginne mit, wie ich meine "Einheit" nennen und es kompilieren möchte. wie:

picker = Pick.new 
item=picker.pick('a') 
assert item 

dann ich

class Pick 
def pick(something) 
return nil 
end 
end 

dann erzeuge ich halten Sie die Auswahl in meinem „test“ Fall, so konnte ich über die Verwendung sehen, wie ich es genannt werden möchte und wie ich behandeln verschiedene Verhaltensweisen. Immer wenn ich merke, dass ich an einigen Grenzen oder einer Art von Fehler/Ausnahme Schwierigkeiten haben könnte, versuche ich, es in Brand zu setzen und einen neuen Testfall zu bekommen.

Also kurz gesagt. Ja. Das Verhältnis Test vorher ist viel höher als das nicht.

Answer 7

Denken Sie daran, mit Extreme Programmierung Ihre Tests effektiv sind Sie Dokumentation. Wenn Sie also nicht wissen, was Sie testen, wissen Sie nicht, was Sie von Ihrer Anwendung erwarten?

Sie können mit „Geschichten“ beginnen, die

so etwas wie

Dann

sein könnte, wie Sie Code schreiben beginnen „Benutzer Liste von Fragen erhalten können“ die Unit-Tests zu lösen. Um das oben genannte zu lösen, benötigen Sie mindestens eine Benutzer- und eine Frageklasse. So können Sie über die Felder zu denken beginnen:

"Benutzerklasse-Adresse Name DOB TelNo Locked Fields"

usw. Hoffe, es hilft.

Crafty

Answer 8

Ja, wenn Sie einen echten TDD Prinzipien verwenden. Ansonsten, solange Sie die Komponententests schreiben, geht es Ihnen besser als den meisten.

Nach meiner Erfahrung ist es in der Regel einfacher, die Tests vor dem Code zu schreiben, denn durch das so tun Sie sich selbst ein einfaches Debugging-Tool geben zu verwenden, wie Sie den Code schreiben.

Answer 9

Ich schreibe sie zur gleichen Zeit. Ich erstelle den Skelett-Code für die neue Klasse und die Test-Klasse, und dann schreibe ich einen Test für einige Funktionen (was mir hilft zu sehen, wie das neue Objekt aufgerufen werden soll) und implementiere es im Code.

Normalerweise, ich am Ende nicht um das erste Mal mit elegantem Code auf, es ist normalerweise ziemlich hacky. Aber sobald alle Tests funktionieren, können Sie wegräumen, bis Sie mit etwas ziemlich ordentlich, ordentlich und beweisbar, um solide zu sein.

Answer 10

Ich denke, dass das Schreiben des Tests zuerst hilft zu definieren, was der Code eigentlich tun sollte. Zu oft haben die Leute keine gute Definition dessen, was der Code tun soll oder wie er funktionieren soll. Sie fangen einfach an zu schreiben und machen es, während sie weitermachen. Wenn Sie den Test zuerst erstellen, konzentrieren Sie sich auf den Code.

Answer 11

Das Schreiben der Tests definiert zunächst, wie Ihr Code aussehen wird - d. H. Er macht Ihren Code tendenziell modularer und testbarer, sodass Sie keine "bloat" -Methoden mit sehr komplexen und überlappenden Funktionen erstellen. Dies hilft auch, alle Kernfunktionen in separaten Methoden zu isolieren, um das Testen zu erleichtern.

Answer 12

Bei TDD geht es nicht um die Tests, sondern darum, wie die Tests Ihren Code steuern. Also im Grunde schreiben Sie Tests, um eine Architektur auf natürliche Weise entstehen zu lassen (und vergessen Sie nicht, sie umzugestalten, sonst werden Sie nicht viel davon profitieren). Dass Sie ein Arsenal von Regressionstests und ausführbarer Dokumentation haben, ist ein schöner Nebeneffekt, aber nicht der Hauptgrund für TDD.

So ist meine Stimme: -Test erste

PS: Und nein, das nicht, dass Sie vor Ihrer Architektur nicht planen, bedeutet zu tun haben, sondern dass Sie könnte es zu überdenken, wenn die Tests, die Sie sagen, tun Sie dies !!!!

Answer 13

Richtlinien sind Vorschläge, wie Sie Dinge tun können, um die Gesamtqualität oder Produktivität oder sogar beide des Endprodukts zu verbessern. Sie sind in keiner Weise gehorchenden Gesetzen, so wenig wie Sie von dem Gott der richtigen Kodierungspraxis blitzartig geschlagen werden.

Hier ist mein Kompromiss auf der Take und ich fand es ziemlich nützlich und produktiv.

Normalerweise ist der schwierigste Teil, um richtig zu werden, die Anforderungen und direkt dahinter die Verwendbarkeit Ihrer Klasse, API, Paket ... Dann ist die eigentliche Implementierung.

1. Schreiben Sie Schnittstellen (sie wird sich ändern, aber wird ein langer Weg gehen zu wissen, was getan werden muss)
2. ein einfaches Programm schreiben, die Schnittstellen (sie dumm Haupt) zu verwenden. Dies hilft bei der Bestimmung der WIE wird es verwendet werden (gehen Sie zurück zu 1 so oft wie nötig)
3. Schreiben Sie Tests auf der Schnittstelle (Das Bit, das ich von TDD integriert habe, gehe wieder wie oft auf 1 zurück je nach Bedarf)
4. schreiben den eigentlichen Code hinter den Schnittstellen
5. Schreibtests auf die Klassen und die tatsächliche Umsetzung, ein Coverage Tool sicher, dass Sie nicht vergessen, Pfade weid Ausführung

so machen, ja ich schreibe Tests vor dem Codieren, aber nie zuvor habe ich herausgefunden, was mit einem bestimmten Detaillierungsgrad getan werden muss. Dies sind in der Regel High-Level-Tests und behandeln nur das Ganze als Black Box. Gewöhnlich bleibt es als Integrationstest und ändert sich nicht viel, sobald sich die Schnittstellen stabilisiert haben.

Dann schreibe ich eine Reihe von Tests (Unit-Tests) über die Umsetzung dahinter, werden diese sehr viel detaillierter sein und wird oft ändern, wie die Umsetzung entwickelt, wie es ist optimiert und erweitert bekommen.

Ist das streng genommen TDD? Extrem? Agil ...? was auch immer... ? Ich weiß es nicht, und es ist mir ehrlich gesagt egal. Es funktioniert für mich. Ich passe es so an, wie es nötig ist und wie sich mein Verständnis von Softwareentwicklungspraxis weiterentwickelt.

my 2 cent

Answer 14

ich in den letzten 6-7 Jahren führen Entwicklungsteams haben. Ich kann mit Sicherheit sagen, dass es als Entwickler und Entwickler, mit denen ich gearbeitet habe, einen phänomenalen Unterschied in der Qualität des Codes macht, wenn wir wissen, wo unser Code in das Gesamtbild passt.

Test Driven Development (TDD) hilft uns zu beantworten "Was?" bevor wir antworten "Wie?" und es macht einen großen Unterschied.

Ich verstehe, warum es Befürchtungen geben kann, nicht in PoC Art der Entwicklung/Architekt Arbeit zu folgen. Und Sie haben Recht, es mag keinen vollständigen Sinn haben, diesem Prozess zu folgen.Gleichzeitig möchte ich betonen, dass TDD ein Prozess ist, der in die Entwicklungsphase fällt (ich weiß, dass es obsolet klingt, aber Sie bekommen den Punkt :), wenn die Low-Level-Spezifikation klar ist.

Answer 15

Persönlich glaube ich, Unit-Tests verlieren viel von ihrer Wirksamkeit, wenn nicht vor dem Schreiben des Codes getan.

Das uralte Problem beim Testen ist, dass wir, egal wie sehr wir darüber nachdenken, nie jedes mögliche Szenario aufstellen werden, um einen Test zu schreiben.

Offensichtlich verhindert Unit Test selbst dies nicht vollständig, da es restriktive Tests gibt, die nur eine Codeeinheit betrachten, die die Interaktionen zwischen diesem Code und allem anderen nicht abdeckt, aber es bietet eine gute Grundlage für das Schreiben von cleanem Code erster Stelle, die zumindest die Chancen für Fragen der Interaktion zwischen Modulen einschränken sollte. Ich habe immer daran gearbeitet, den Code so einfach wie möglich zu halten - ich glaube, das ist eines der Hauptprinzipien von TDD.

Also beginnen mit einem Test, der im Grunde sagt, dass Sie eine Klasse dieses Typs erstellen und es theoretisch aufbauen können, einen Test für jede Codezeile schreiben oder mindestens jede Route durch einen bestimmten Codeabschnitt abdecken. Entwerfen wie du gehst! Offensichtlich basiert auf einem rauhen Frontdesign, das anfänglich produziert wurde, um Ihnen einen Rahmen zu geben, um zu arbeiten.

Wie Sie sagen, es ist sehr unnatürlich zu beginnen und kann wie eine Verschwendung von Zeit scheinen, aber ich habe mich selbst gesehen, dass es auf lange Sicht auszahlt, wenn Fehler Statistiken kommen und die Module zeigen, die waren vollständig mit TDD geschrieben haben weit geringere Mängel im Laufe der Zeit als andere.

Answer 16

Ich programmiere seit 20 Jahren, und ich habe so gut wie nie eine Codezeile geschrieben, auf der ich keine Art von Komponententest durchgeführt habe - ehrlich gesagt, ich weiß, dass Leute es die ganze Zeit tun, aber wie Jemand kann eine Codezeile versenden, die noch nicht getestet wurde.

Oft, wenn es kein Testframework gibt, schreibe ich einfach eine main() in jede Klasse, die ich schreibe. Es fügt Ihrer App ein wenig Gruft hinzu, aber jemand kann es immer löschen (oder auskommentieren), wenn sie es wollen. Ich wünschte wirklich, es gäbe nur eine test() -Methode in Ihrer Klasse, die automatisch für Releasebuys kompiliert würde - ich liebe meine Testmethode in der gleichen Datei wie mein Code ...

Also habe ich beides gemacht Test Driven Entwicklung und Tested Entwicklung. Ich kann Ihnen sagen, dass TDD wirklich helfen kann, wenn Sie ein beginnender Programmierer sind. Es hilft Ihnen, Ihren Code "Von außen" zu sehen, was eine der wichtigsten Lektionen ist, die ein Programmierer lernen kann.

TDD hilft Ihnen auch, wenn Sie stecken bleiben. Du kannst einfach ein sehr kleines Stück schreiben, von dem du weißt, dass es dein Code zu tun hat, dann führe es aus und repariere es - es macht süchtig.

Auf der anderen Seite, wenn Sie bestehenden Code hinzufügen und ziemlich genau wissen, was Sie wollen, ist es eine Toss-Up. Ihr "Anderer Code" testet Ihren neuen Code oft an Ort und Stelle. Sie müssen immer noch sicher sein, dass Sie jeden Pfad testen, aber Sie erhalten eine gute Abdeckung, indem Sie die Tests vom Front-End aus durchführen (außer für dynamische Sprachen - für diejenigen, die wirklich Unit-Tests für alles haben sollten, egal was).

Übrigens, als ich auf einem ziemlich großen Ruby/Rails-Projekt war, hatten wir einen sehr hohen Prozentsatz der Testabdeckung. Wir haben eine große, zentrale Modellklasse in zwei Klassen unterteilt. Es hätte zwei Tage gedauert, aber mit all den Tests, die wir umgestalten mussten, war es knapp zwei Wochen her. Tests sind NICHT komplett kostenlos.

Answer 17

Es hilft, wenn Sie etwas schreiben, dass Sie schreiben schreiben, um zuerst alles zu schreiben, was Sie regelmäßig überprüfen würden und dann diese Funktionen schreiben.Mehr Zeiten, dann sind diese Funktionen nicht das Wichtigste für die Software, die Sie schreiben. Jetzt, auf der anderen Seite, gibt es keine silbernen Kugeln und das Ding sollte nie genauestens befolgt werden. Entwicklerbeurteilung spielt eine große Rolle bei der Entscheidung, testgetriebene Entwicklung gegenüber letzter Testentwicklung zu verwenden.

Answer 18

Vor, während und nach. Bevor ist Teil der Spezifikation, der Vertrag, die Definition der Arbeit Während ist, wenn Sonderfälle, schlechte Daten, Ausnahmen bei der Umsetzung aufgedeckt werden. After ist Wartung, Entwicklung, Änderung, neue Anforderungen.

Answer 19

Ich bin mir nicht sicher, aber aus Ihrer Beschreibung spüre ich, dass es ein Missverständnis darüber geben könnte, was Test-First eigentlich bedeutet. Es tut nicht bedeutet, dass Sie alle Ihre Tests zuerst schreiben. Es bedeutet, dass Sie einen sehr engen Zyklus haben

1. schreiben einen einzigen, minimalen Test
2. den Testdurchlauf erforderlich durch das Schreiben des minimalen Produktionscode machen
3. den nächsten Test schreiben, der wird scheitern
4. machen alle vorhandenen Tests bestehen, indem den bestehenden Produktionscode auf möglichst einfache Art und Weise zu ändern
5. umgestalten den Code (beide Test und Produktion!), so dass es nicht Vervielfältigung enthält und ausdruck
6. weiter mit 3. bis Sie können nicht von einem anderen vernünftigen Test denken

Ein Zyklus (3-5) in der Regel dauert nur ein paar Minuten. Unter Verwendung dieser Technik entwickeln Sie das Design, während Sie Ihre Tests und Produktionscode parallel schreiben. Es gibt überhaupt nicht viel Frontdesign.

Auf die Frage, es sei "notwendig" - nein, ist es offensichtlich nicht. Es gab unzählige Projekte, die ohne TDD erfolgreich waren. Aber es gibt einige starke Beweise dafür, dass die Verwendung von TDD typischerweise zu einer signifikant höheren Qualität führt, oft ohne negative Auswirkungen auf die Produktivität. Und es macht auch Spaß!

Oh, und da es sich nicht "natürlich" anfühlt, ist es nur eine Frage dessen, was Sie gewohnt sind. Ich kenne Leute, die ziemlich süchtig danach sind, alle paar Minuten einen grünen Balken zu bekommen (das typische xUnit-Zeichen für "alle Tests bestanden").

Answer 20

Es gibt so viele Antworten jetzt und sie sind alle unterschiedlich. Dies ähnelt perfekt der Realität da draußen. Jeder macht es anders. Ich denke, es gibt ein großes Missverständnis über Unit Testing. Es scheint mir, als hätten die Leute von TDD gehört und sie sagten, es sei gut. Dann begannen sie Unit Tests zu schreiben, ohne wirklich zu wissen, was TDD wirklich ist. Sie haben nur den Teil "oh yeah wir müssen Tests schreiben" und sie stimmen damit überein. Sie haben auch davon gehört "Sie sollten zuerst Ihre Tests schreiben", aber sie nehmen das nicht ernst.

Ich denke, es ist, weil sie die Vorteile von Test-First nicht verstehen, die wiederum Sie nur verstehen können, sobald Sie es auf diese Weise seit einiger Zeit getan haben. Und sie scheinen immer 1.000.000 Entschuldigungen zu finden, warum sie nicht gerne zuerst die Tests schreiben. Weil es zu schwierig ist, herauszufinden, wie alles zusammenpasst usw. usw. Meiner Meinung nach ist es alles Ausreden für sie, sich vor ihrer Unfähigkeit zu verstecken, sich einmal selbst zu disziplinieren, den Test-First-Ansatz zu versuchen und die Vorteile zu sehen.

Die lächerlichste Sache, wenn sie beginnen zu argumentieren "Ich bin nicht über diesen Test-erste Sache überzeugt, aber ich habe es nie so gemacht" ...toll ...

Ich frage mich, woher Unit-Test ursprünglich stammt. Denn wenn das Konzept wirklich von TDD stammt, ist es nur lächerlich, wie die Leute es falsch verstehen.