Wer macht testgetriebene Entwicklung?

Ich habe in den letzten 4 ½ Jahren im Unternehmensbereich gearbeitet und festgestellt, dass Unternehmen im Allgemeinen keine geeigneten Umgebungen für den Test-First-Entwicklungsstil sind. Projekte sind in der Regel kosten-, zeit- und wasserfallbasiert. Alle Unit-Tests werden, falls überhaupt, in der Regel nach der Entwicklung in der QS-Phase von einem anderen Team durchgeführt.

Bevor ich für ein Unternehmen gearbeitet habe, habe ich viele kleine und mittlere Unternehmen beraten, und keines von ihnen war bereit, für ein Entwicklungsprojekt im Test-First-Stil zu bezahlen. Normalerweise wollten sie, dass die Entwicklung sofort oder nach einer kurzen Designphase gestartet wird, dh etwas, das eher agil ist, obwohl einige Kunden wollten, dass alles wie ein Wasserfall dargestellt wird.

Mit welchen Arten von Shops, Unternehmen und Kunden funktioniert die testgetriebene Entwicklung am besten? Welche Arten von Projekten sind für TDD in der Regel förderlich?

Jede Codezeile, die ich schreibe, verwendet eine testgetriebene Entwicklung. Wenn das Management mit dem Schreiben von Tests nicht an Bord ist, erzähle ich es dem Management nicht. Ich bin der festen Überzeugung, dass testgetriebene Entwicklung ein besserer Prozess ist.

Mein Chef hat mir heute einen guten Tipp gegeben. Ich glaube, ich werde ihn stehlen, als würde er ihn jemand anderem stehlen.

"Würden Sie erwarten, dass ein Tischler das Brett misst, bevor er es schneidet?"

Ich habe in der High School einen Holzladen besucht und während der gesamten Schulzeit am Bau gearbeitet. Unser Mantra lautete immer "zweimal messen, einmal schneiden", woraufhin der sarkastische Satz "Ich habe es geschnitten und wieder geschnitten und es war immer noch zu kurz!"

Wenn Sie danach testen, erstellen Sie eine Überarbeitung, da der Code, den Sie geschrieben haben, nur schwer zu testen ist. Wenn Sie zuerst testen oder sogar ein wenig in der Mitte testen, aber bevor Sie die Software festschreiben, ist es einfacher, die von Ihnen erstellte Software zu testen. Ein Unternehmen, das Komponententests erstellt, nachdem Produktionscode geschrieben wurde, um eine Checkliste zu erfüllen, verschwendet Aufwand.

Die Integration in vorhandene, schwer zu testende Software verursacht zusätzlichen Aufwand, da Sie Testnähte erstellen müssen, um die Abhängigkeiten zu kontrollieren, die Ihr glänzender neuer, testgetriebener Code verbraucht. In einigen Fällen, wie zum Beispiel bei Frameworks, die stark von globalen Staats- und Gottobjekten Gebrauch machen, kann dies sehr schwierig zu erreichen sein. Die wahrgenommene Schwierigkeit einer testgetriebenen Entwicklung beruht häufig auf einer Kombination aus Unerfahrenheit beim Schreiben guter Tests und dem Versuch, eng gekoppelten Code zu testen.

Sie können den Drive Code auch in einem Wasserfallprojekt testen. Dies ist eine technische Disziplin und keine Projektmanagement-Technik.

Ich bin keineswegs ein TDD-Fan, aber es bringt Ihnen viel über Software-Design bei.

Nehmen Sie mich mit, da dies einen unverwechselbaren .Net-Geschmack haben wird: p

In Bezug auf Arten von Projekten, die für den Test-First-Ansatz geeignet sind, möchte ich Folgendes beachten:

• haben Sie es mit einer vorhandenen Codebasis zu tun? Das Nachrüsten einer Testsuite ist oft unerschwinglich teuer. Machen Sie sich ein Bild davon, wie viel technische Schulden es gibt
• Bestimmte Plattformen und Frameworks sind von Natur aus testunfreundlich. Jüngste Erfahrungen, die mir in den Sinn kommen - SharePoint zum Beispiel ist für TDD sehr schwierig (aber nicht unmöglich). Für solche Dinge müssen Sie möglicherweise auf ein kommerzielles Isolatorprodukt zurückgreifen, wie TypeMock.
• Bestimmte Implementierungsansätze eignen sich besser für TDD als andere. Zum Beispiel ASP.Net mit Code-Behinds - nicht so testbar. ASP.Net MVC - testbar. Silverlight mit Code-Behinds - nicht so testbar. Silverlight mit MVVM - testbar.

Letztendlich kann "die Organisation" zwar viel dazu beitragen, die Umstellung auf Test-First zu unterstützen, aber der entscheidende Wandel, der stattfinden muss, liegt in den Köpfen der Entwickler. Ich habe den Ansatz "Du sollst zuerst deine Tests schreiben" aufgegeben und suche stattdessen nach lehrbaren Momenten.

+1 zu mpenrows Kommentar, dass sie mgmt nicht mitteilen sollen, wenn sie ein Problem damit haben: p

Ihre Situation wird sich nicht schnell ändern, und der Schlüssel, um es zu schaffen, besteht darin, es zu einem Teil Ihrer persönlichen Disziplin zu machen und darin gut zu sein, bevor Sie versuchen, es anderen aufzuzwingen. Wenn Sie als Beispiel dienen können, sollten Ihre Manager objektive Vorteile sehen.

Sie können auch gute Business Cases erstellen:

• TDD kann einfach als "Spezifikation, anhand derer sich das System automatisch verifizieren kann" zusammengefasst werden. Es wird nicht anders programmiert, es wird kein anderes Produkt erstellt.

• Unit Testing ist eigentlich nur eine Form des automatisierten Testens. Das heißt, Sie lassen den Computer für sich selbst tun, wofür das Unternehmen wahrscheinlich Fleischraumingenieure manuell bezahlt. Automatisierte Tests werden schneller, konsistenter ausgeführt und liefern - wenn sie gut geschrieben sind - schnelles, präzises und genaues Feedback sowie Beschreibungen und Anweisungen für das Problem

• Wenn TDD von jemandem ausgeführt wird, der weiß, was er tut, führt dies genauso schnell zu Ergebnissen wie Code-First. Es wird eine Lern- / Schulungskurve geben (und wenn Ihre Ingenieure aus dem unteren Bereich des Talentpools stammen, kann dies Ihre Chancen, TDD voranzutreiben, völlig zunichte machen. In diesem Fall ist es das Beste, das Sie tun können, um es weiter zu fördern und das Management fragen sie eher als TDD)

• Bei TDD geht es vor allem darum, die anstehende Aufgabe zu überdenken, bevor sie gestartet wird. Es entspricht dem Motto "zweimal messen, einmal schneiden" - die zusätzliche Messung verlängert die Aufgabe geringfügig, vermeidet jedoch, Ihre wertvollste Ressource - die Entwicklungsstunden - wegzuwerfen.

... und erinnere dich einfach; Das Wichtigste, was Sie tun können, ist, mit gutem Beispiel voranzugehen. Wenn Sie sich mit TDD nicht so gut auskennen, investieren Sie ein paar zusätzliche Stunden, um besser zu werden. Sobald Sie sich auskennen, fangen Sie einfach bei der Arbeit an (würden sich Ihre Manager wirklich darüber beschweren, dass Sie Tests schreiben?). Kämpfe einen Kampf nach dem anderen und mache Schritte darauf zu - wenn du den ganzen Schebang spielst, wirst du wahrscheinlich scheitern und die Schuld liegt bei dir, wenn du hart dafür drängst.

Ich mache. Es ist meine bevorzugte Art der Entwicklung, und ich arbeite für ein großes Finanzunternehmen, das sich freut, dass ich so arbeite, wie ich es für richtig halte, solange ich die Fristen einhalte und Qualitätscode produziere. Bei korrekter Ausführung muss die Entwicklung des ersten Tests nicht länger dauern als die Entwicklung nach dem Test. Vergessen wir auch nicht, dass die anderen Tests weniger Fehler aufwiesen, die später beim Testen des Systems anfielen.

Der Schlüssel zum Ausführen von TDD besteht darin, es einfach als Teil des Schreibens Ihres Codes zu tun, und falls erforderlich, sagen Sie niemandem, dass Sie es tun. Es ist nicht notwendig, alles zu erklären, was Sie tun. Ihr Endergebnis ist Arbeitscode.

Wenn du erklärst "Ich schreibe Tests", dann können die Mächte sagen "Oh, wir können das beseitigen!" Aber wenn Sie niemandem davon erzählen, dann haben Sie immer noch die Tests als Rest des Codierungsprozesses.

Programmieren ist mehr als das Eintippen von Arbeitsanweisungen in einen Editor. Wenn die Leute damit nicht umgehen können, dann schütze sie vor dieser Wahrheit, bis sie bereit sind, damit umzugehen. "Bereit, damit umzugehen" bedeutet in diesem Fall, dass Sie ein oder zwei abgeschlossene Projekte pünktlich mit soliden, zuverlässigen Codes abgeschlossen haben und dass Sie auch Unit-Tests dafür haben.

Leider habe ich selbst keine Chance bekommen, es im wahrsten Sinne des Wortes zu benutzen, also kann ich nicht "Ich! Ich! Ich mache es!" Sagen. Ich gehe davon aus, dass sich die Frage stellt, "welche Branchen / Unternehmen TDD auf breiter Front einsetzen" und nicht "ob jemand TDD in ihr tägliches Leben einschleichen kann". Ich bin damit einverstanden, dass ein einzelner Entwickler TDD vollständig ausführen kann, ohne dass die gesamte Gruppe dazu gezwungen wird. Ich denke nur, das war nicht der springende Punkt.

Mein Eindruck von der Branche ist, dass Sie TDD mit größerer Wahrscheinlichkeit in den meisten Entwicklungsgruppen eines Unternehmens in Situationen sehen, in denen:

• Vor der Einführung von TDD war keine große Codebasis vorhanden

• Das Unternehmen ist nicht riesig und hat daher nicht viele Pushbacks "Wir haben es immer in die andere Richtung gemacht".

• Das Unternehmen hat keinen enormen Buy-In für den formalisierten Prozess. Das heißt nicht, dass Sie TDD nicht beispielsweise in einem CMMI-zertifizierten Unternehmen implementieren konnten. Wenn Sie jedoch einen Nicht-TDD-Prozess hatten, kann es eine große Investition sein, alle Prozesse, die Sie mit CMMI überwachen, zu aktualisieren.

• Tests können mit Skripten erstellt werden - dies ist eine äußerst komplexe Codebasis, da Sie auch dann einige der internen Skripten erstellen können, wenn Sie die dem Benutzer am nächsten liegende Ebene nicht einfach skripten können. Aber ich sehe Situationen mit gut entwickelten Optionen für die Testautomatisierung als die besten Punkte für TDD an, da es darauf beruht, eine ganze Reihe von Tests erneut auszuführen und nicht zu unterbrechen, bei denen Sie sehr schnell Feedback zum Testen benötigen. Meiner Meinung nach ist eine eigenständige Web-App ein gutes TDD-Ziel. Ein System mit umfassender COTS-Integration oder Eingaben, die nicht auf der Benutzeroberfläche basieren, kann schwierig sein.

• Systeme in einem nicht prototypisierten Zustand. Idealerweise die nächste große Version nach dem Prototyp - wo der Proof of Concept abgeschlossen ist und das Projekt finanziert wird, aber jeder weiß, dass der nächste Versuch einen Qualitätssprung bedeuten muss.

• Stakeholder, die in den Prozess investiert sind.

Ich habe es versucht, wo es möglich ist - aber ich denke, es hängt wirklich von der Unternehmensumgebung ab, in der Sie sich befinden. Ich habe viele Jahre in der Spieleindustrie gearbeitet (übrigens als Künstler), und es gab kein Konzept für TDD - nur einen Brute-Force-QA-Ansatz. Ich bin in die Webentwicklung eingestiegen und habe noch nicht in einer Agentur mit einer formalen Anerkennung (oder Kenntnissen von ...) von Unit Testing / TDD gearbeitet. Gleiches gilt für die meisten meiner Kollegen in der Branche, die in einem breiten Spektrum von Disziplinen arbeiten.

In einer vertriebsorientierten Agentur bietet TDD dem Kunden nur einen sehr geringen kurzfristigen ROI. Daher ist es schwierig, ihn bei der Planung eines Projekts an die Vorgesetzten zu verkaufen. Je größer ein Projekt wird, desto überzeugender wird es.

Angesichts der Tatsache, dass Bücher wie der Todesmarsch auf ein weit verbreitetes Phänomen hinweisen, dh auf eine Branche, die von "Crunch" - und "Milestone" -getriebenen Entwicklungen geplagt wird - wette ich, dass TDD außerhalb gut finanzierter Startups oder monolithischer Unternehmensshops wahrscheinlich selten ist. Es ist nicht so, dass die Menschen dort nicht an den Wert von TDD glauben - aber es ist zu abstrakt, um es an ihre Kunden zu verkaufen.

Ich versuche, selbst in TDD einzusteigen. Ich denke, solange du Routen folgst, die du bereits kennst (die tägliche Arbeit), ist es ziemlich einfach. Aber ich kann mich einfach nicht mit Tests für die Benutzeroberflächenteile beschäftigen oder wenn Sie eine neue Lösung für ein Problem finden müssen, auf das Sie noch nie gestoßen sind. Oder mit einem Framework, das Sie nicht kennen.

Ich denke, Sie müssen eine Art von Lerntests durchführen, separate Proof-of-Concept-Tests durchführen und diese anschließend umschreiben, usw., oder irre ich mich?

Und (ich weiß, dass es eine alte ist, aber ich habe noch keine gute Antwort gesehen): Wie codieren Sie Algorithmen mit TDD (wenn die Ergebnisse zu komplex sein könnten, um sie wirklich mit Leichtigkeit zu "behaupten")?

Ich kann die positiven Seiten von TDD und ich auf dem Boot wirklich sehen, aber es ist sehr schwierig für Anfänger, wenn der Code, den Sie schreiben, Sie fast doppelt so lange braucht (und Sie haben Kollegen, die die Profis überhaupt nicht sehen und Sie verspotten mit RAD)

Ich habe es ein paar Mal versucht und es hat super funktioniert. Leider verschiebe ich die meiste Zeit, wenn ich meine App manuell testen kann, Unit-Tests, bis ich mich zu gelangweilt fühle, um etwas anderes zu implementieren, oder es gibt einen Fehler, den ich nicht einfach beheben kann.

Ich tue es. Der Fortschritt unserer User Stories wird auf einem Kanban-Board mit der Aufschrift "Has a Test?" Spalte links (stromaufwärts) von Development.

Dieses etwas ungewöhnliche Layout macht eine Richtlinie explizit: Es muss ein fehlgeschlagener automatischer Abnahmetest (in der Regel einige davon) vorhanden sein. Es muss auf eine Kundenanforderung rückführbar sein. Die Abnahmetests ergeben sich aus Zufriedenheitsbedingungen , die aus Gesprächen resultieren , die mit einer Story Card beginnen . Ich führe regelmäßige Workshops durch, in denen wir Brainstorming-Anforderungen durchführen, Lücken identifizieren und die wichtigsten Akzeptanztests herausfinden, mit denen sichergestellt wird, dass der Benutzerwert erreicht wird, wenn sie bestanden werden (die Definition von erledigt ). Es ist eine gemeinschaftliche Aktivität, an der Programmierer, Geschäftsanalysten und manchmal Tester beteiligt sind.

Die Feedbackschleife zum Akzeptanztest ist ziemlich lang: Es kann mehrere Tage dauern, bis die Story fertig ist. Die Entwicklung hat ihre eigenen, kürzeren TDD-Rückkopplungsschleifen.

"[... kein Test-First-Style ...] ähnlicher wie Agile ...."

Dies ist eine vollständige Falschdarstellung von Agile. Die Definition von erledigt ist eine Schlüsselkomponente von Agile und eine der Säulen, auf denen es beruht, ist das automatisierte Akzeptanztesten (was ich oben beschrieben habe, ist eine Möglichkeit, dies zu tun.) Wenn extreme Programmierung (XP) als agile Implementierungsmethode verwendet wird, dann ATDD / BDD und TDD sind vorgeschrieben.

Das tue ich, aber im Allgemeinen nur für Nicht-UI-Komponenten, und wenn ich weiß, dass ich nicht den gesamten Algorithmus für ein Modul auf einmal im Kopf behalten kann, oder wenn das Modul ein neuer Teil des Systems ist, an dem ich arbeite, Daher kann ich mich nicht darauf verlassen, dass die meisten Bibliotheken, die ich verwende, stark getestet wurden.

Im Grunde tue ich das, wenn die Komplexität der Anforderungen bedeutet, dass ich mich sonst im Code verlieren könnte.

Es ist eine schwierige Angewohnheit, mit dem Management-Buy-In zu beginnen, aber wenn Ihre Tests nach der Hälfte der Entwicklungszeit abbrechen, kann dies lebensrettend sein!

Ich wollte genau diese Frage stellen, um zu sehen, wie viele Unternehmen tatsächlich TDD praktizieren.

In den elf Jahren, in denen ich beruflich programmiert habe, waren sich nur die letzten beiden Organisationen überhaupt der Verbreitung von TDD bewusst (dies erstreckt sich über fast fünf Jahre, bevor TDD nicht mehr so ​​populär war wie heute). Ich komme auf den Punkt und beantworte Ihre Frage, bevor ich mich mit meinem Verkaufsargument für TDD beschäftige :)

Bei der letzten Firma, für die ich gearbeitet habe (akademischer Online-Verlag für geistes- und naturwissenschaftliche Sammlungen), wussten wir, dass wir TDD praktizieren mussten, aber wir sind nie ganz dort angekommen. Zu unserer Verteidigung hatten wir eine 250-KB-Codebasis, sodass das Hinzufügen von Tests zu einer nicht testbaren Codebasis dieser Größe als unüberwindlich empfunden wurde (ich habe das Gefühl, dass ich das jetzt schreibe!). Auch die Besten von uns machen Fehler .

Wer auch nur eine kleine Menge von TDD weiß , wie schmerzhaft Nachrüsten Tests braun Feld untestable Code getan werden kann ... Die Hauptursachen sind implizite Abhängigkeiten (Sie alle Hebel assert Ergebnisse aus dem Code nicht ziehen kann - nicht Mock können Szenarien) und Verletzung des Einzelverantwortungsprinzips (Tests sind kompliziert, erfunden, erfordern zu viel Setup und sind schwer zu verstehen ).

Wir haben unser QA-Team vorübergehend erweitert (von einem, vielleicht zwei Personen auf ein halbes Dutzend oder mehr), um die Plattform vor jeder Veröffentlichung zu testen . Es war sehr zeitaufwändig und finanziell gesehen, einige Veröffentlichungen würden drei Monate dauern, um das Testen abzuschließen. Schon damals wussten wir, dass wir Probleme hatten, sie waren einfach keine „Blocker“ oder „Kritisch“, sondern nur „Hochpriorität“.

Wenn Sie über jahrelange Erfahrung im kaufmännischen Bereich verfügen, werden Sie zu schätzen wissen, dass jedes Unternehmen kritische Aufgaben wahrnimmt und dann eine höhere und höchstwahrscheinlich auch eine höhere Prioritätsstufe einführt - insbesondere, wenn jemand von oben ein Feature / eine Fehlerbehebung vorantreibt. Ich schweife ab ...

Ich freue mich, Ihnen mitteilen zu können, dass ich in meinem derzeitigen Unternehmen (Entwicklungshaus für Telekommunikation, Web und mobile Apps) TDD praktiziere, zusammen mit Jenkins CI, um andere statische Analyseberichte zu erstellen (die Codeabdeckung ist am nützlichsten, nachdem die Testsuite bestanden wurde). . Die Projekte, für die ich TDD verwendet habe, sind ein Zahlungssystem und ein Grid-Computing-System.

Das Verkaufsgespräch ...

Es kann oft ein harter Kampf sein, der automatisierte Tests für nichttechnische Teammitglieder rechtfertigt. Das Schreiben von Tests erhöht zwar den Entwicklungsaufwand, aber ... die Zeit, die Sie jetzt in das Testen investieren, spart Ihnen später Wartungsaufwand. Sie leihen sich wirklich nur Zeit . Je länger das Produkt in Gebrauch ist, desto mehr sparen Sie - und desto weniger müssen Sie umschreiben .

Zuerst testen bedeutet, dass Sie zuerst Ihre Absicht codieren und dann bestätigen, dass Ihr Code diese Absicht erfüllt. Dies bietet Fokus und destilliert Ihren Code, um nur das zu tun, was beabsichtigt ist und nicht mehr (read no bloat). Es ist gleichzeitig eine ausführbare Spezifikation und Dokumentation (wenn Ihr Test gut geschrieben ist und die Tests so lesbar / sauber sein sollten wie Ihr Systemcode, wenn nicht mehr!).

Nicht-Programmierer werden (oft) nicht über diese Einsicht verfügen und daher ist TDD für sie nicht besonders wertvoll und wird als Wegwerfverknüpfung zu einem früheren Veröffentlichungsdatum angesehen.

Das Programmieren ist unsere Domäne, und aus meiner Sicht liegt es in unserer Verantwortung , als Profis Empfehlungen für bewährte Verfahren wie TDD abzugeben. Die Projektmanager müssen nicht entscheiden, ob dies zur Verkürzung der Entwicklungszeit erfolgt, da dies außerhalb ihrer Zuständigkeit liegt . Ebenso wenig teilen sie Ihnen mit, welches Framework, welche Caching-Lösung oder welcher Suchalgorithmus verwendet werden soll, und sie sollten Ihnen nicht mitteilen, ob Sie automatisierte Tests durchführen sollen.

In meiner Meinung nach ist die Software - Entwicklung der Industrie (im Großen und Ganzen) derzeit unterbrochen, die Tatsache , dass Tests für Ihre Software zu haben ist nicht die Norm.

Stellen Sie sich das in anderen Branchen vor: Medizin, Luftfahrt, Automobil, Kosmetik, Plüschtiere, alkoholische Getränke usw. Ich habe meine Verlobte gebeten, eine Branche zu nennen, in der das Produkt nicht getestet wird und sie es nicht konnte!

Vielleicht ist es unfair zu sagen, dass keine Tests stattfinden, weil dies der Fall ist ... aber in Unternehmen ohne automatisierte Tests ist dies ein sehr manueller / menschlicher Prozess (Lesen klobig und oft fehleranfällig).

Einen Punkt möchte ich in Ihrer Frage ansprechen ...

Sie wollten normalerweise, dass die Entwicklung sofort oder nach einer kurzen Designpause beginnt. Mehr wie bei Agile.

Da "Agile" keine Vorgehensweise ohne Tests vorschreibt, ist Kent Beck , der Schöpfer von XP und TDD , das erste auf agilemanifesto.org aufgeführte Mitglied !

Zwei Bücher, die ich wärmstens empfehlen kann, wenn Sie an TDD interessiert sind oder sie einfach nicht gelesen haben und ein begeisterter Programmierer sind (lesen das alle richtig?;)

Wachsende objektorientierte Software, die von Tests geleitet wird

Sauberer Code - Serie von Robert C Martin ("Onkel Bob")

Diese beiden Bücher ergänzen sich und verdichten viel Sinn auf wenige Seiten.

Danke, dass du diese Frage gestellt hast :)

Diejenigen, die Klone implementieren. Ich kann mir keinen besseren Prozess vorstellen, wenn Sie etwas entwickeln, das genau wie ein bestehendes Programm funktioniert.

Offensichtlich ist dies ein ziemlich ungewöhnlicher Fall, aber die Entwickler von SQLite verwenden Tests ausgiebig. (Ich gehe davon aus, dass der Entwicklungsprozess zuerst getestet wird, obwohl ich mir nicht sicher bin.)

• 73.000 Codezeilen
• 91.378.600 Zeilen Testcode

Siehe http://www.sqlite.org/testing.html