Warum fehlt in Joels Test die testgetriebene Entwicklung?

Ich habe diesen Blog von Joel Spolsky über 12 Schritte zu besserem Code gelesen . Das Fehlen von Test Driven Development hat mich wirklich überrascht. Also möchte ich die Frage an die Gurus werfen. Lohnt sich TDD nicht wirklich?

Testgetriebene Entwicklung war praktisch unbekannt, bevor Kent Becks Buch im Jahr 2002 herauskam, zwei Jahre nachdem Joel diesen Beitrag geschrieben hatte. Die Frage ist dann, warum Joel seinen Test nicht aktualisiert hat, oder ob TDD 2000 besser bekannt gewesen wäre, hätte er ihn zu seinen Kriterien gezählt?

Ich glaube, er hätte es nicht getan, aus dem einfachen Grund, dass es wichtig ist, dass Sie einen genau definierten Prozess haben, nicht die spezifischen Details dieses Prozesses. Aus dem gleichen Grund empfiehlt er die Versionskontrolle, ohne ein bestimmtes Versionskontrollsystem anzugeben, oder empfiehlt eine Bug-Datenbank, ohne eine bestimmte Marke zu empfehlen. Gute Teams verbessern und passen sich kontinuierlich an und verwenden Tools und Prozesse, die für ihre jeweilige Situation zu dieser bestimmten Zeit gut geeignet sind. Für einige Teams bedeutet das definitiv TDD. Für andere Teams nicht so sehr. Wenn Sie TDD einführen, stellen Sie sicher, dass es sich nicht um eine Frachtkultmentalität handelt .

Joel hat dies an einigen Stellen konkret angesprochen.

Er hat erklärt, dass die Dinge Tests nicht in der Lage sind, viele wichtige Fragen zu erfassen, insbesondere subjektive Fragen wie "ist die Benutzeroberfläche dieser Software scheiße?" Seiner Meinung nach haben wir uns bei Windows Vista zu sehr auf automatisierte Tests verlassen.

Er hat geschrieben, dass nach seiner Erfahrung die Arten von Fehlern, die Benutzer tatsächlich finden, in zwei Kategorien fallen: 1) diejenigen, die im allgemeinen Sprachgebrauch auftreten und die die Programmierer selbst gefunden hätten, wenn sie ihren eigenen Code ausgeführt hätten, bevor sie ihn verwendeten , oder 2) Randfälle, die so undurchsichtig sind, dass niemand daran gedacht hätte, Tests zu schreiben, um sie überhaupt abzudecken. Er hat angegeben, dass nur ein sehr kleiner Prozentsatz der Fehler, die er und sein Team in FogBugz behoben haben, die Art von Dingen sind, die Unit-Tests abgefangen hätten. (Ich kann diesen Artikel jetzt nicht finden, aber wenn jemand weiß, welchen ich meine, können Sie den Link hier bearbeiten.)

Und er schreibt, dass es mehr Ärger geben kann, als es sich lohnt, besonders wenn Ihr Projekt zu einem sehr großen Projekt mit vielen Komponententests heranwächst und Sie dann (absichtlich) etwas ändern und am Ende eine sehr große Anzahl defekter Komponententests erhalten. Er verwendet speziell die Probleme, die Unit-Tests verursachen können, als Grund, warum er sie nicht als 13. Punkt in den Joel-Test aufgenommen hat, selbst wenn die Leute vorschlagen, dass er sollte.

Joel Spolsky selbst hat diese Frage bereits 2009 beantwortet :

Joel: Es gibt eine Debatte über testgetriebene Entwicklung ... sollten Sie Unit-Tests für alles haben, diese Art von Sachen ... schreiben mir viele Leute, nachdem sie den Joel-Test gelesen haben, um zu sagen: "Sie sollten eine 13 haben Sache hier: Unit-Tests, 100% Unit-Tests Ihres gesamten Codes. "

Und das scheint mir ein bisschen zu doktrinär in Bezug auf etwas, das Sie vielleicht nicht brauchen. Die ganze Idee der agilen Programmierung besteht darin, Dinge nicht zu tun, bevor Sie sie brauchen, sondern sie nach Bedarf durchzublättern. Ich habe das Gefühl, dass ein automatisiertes Testen von allem oft nicht hilfreich ist. Mit anderen Worten, Sie werden eine Menge Unit-Tests schreiben, um sicherzustellen, dass der Code wirklich funktioniert, und Sie werden auf jeden Fall herausfinden, ob er nicht funktioniert [wenn Sie es nicht tun] schreibe die tests] funktioniert eigentlich noch, ... ich weiß nicht, ich werde solche flammenpost dafür bekommen, weil ich es nicht so gut ausdrücke. Aber ich glaube, wenn ein Team wirklich 100% Code-Abdeckung seiner Unit-Tests hätte, gäbe es ein paar Probleme. Eins, Sie hätten sehr viel Zeit damit verbracht, Unit-Tests zu schreiben, und wären nicht in der Lage, diese Zeit in verbesserter Qualität zu bezahlen. Ich meine, sie hätten eine verbesserte Qualität und die Möglichkeit, Dinge in ihrem Code zu ändern, mit der Gewissheit, dass sie nichts kaputt machen, aber das war's.

Wie ich herausgefunden habe, besteht das eigentliche Problem bei Komponententests darin, dass die Art der Änderungen, die Sie im Verlauf der Codeentwicklung vornehmen, einen konstanten Prozentsatz Ihrer Komponententests beeinträchtigt. Manchmal werden Sie eine Änderung an Ihrem Code vornehmen, die irgendwie 10% Ihrer Komponententests bricht. Absichtlich. Weil Sie das Design von etwas geändert haben ... Sie haben ein Menü verschoben, und jetzt ist alles, was sich darauf verlassen hat, dass dieses Menü da ist ... das Menü ist jetzt woanders. Und so brechen all diese Tests jetzt. Und Sie müssen in der Lage sein, diese Tests erneut zu erstellen, um die neue Realität des Codes widerzuspiegeln.

Das Endergebnis ist also, dass, wenn Ihr Projekt immer größer wird und Sie wirklich viele Komponententests haben, der Betrag an Investitionen in die Pflege dieser Komponententests, die Aktualisierung und die Pflege dieser Komponenten erforderlich ist Wenn sie vergehen, wird dies überproportional zu der Höhe des Nutzens, den Sie daraus ziehen.

Niemand außer Joel konnte das mit Sicherheit beantworten. Aber wir können einige Gründe / Beobachtungen ausprobieren.

Zuallererst fehlt das Testen beim Joel-Test nicht

• Tests werden zweimal in 12 Schritten direkt erwähnt (10 und 12)
• Die Existenz eines Builds ist einer der ersten Punkte. Die Idee, Builds zu haben, ist, die Kapazität zu bekommen, um zu sehen, ob sie kaputt gehen, also sprechen wir hier (auch) über Tests.

Zweitens besteht die ganze Idee des Joel-Tests (so wie ich es verstehe) darin, schnelle Ja-Nein-Fragen zu stellen. "Machst du TDD?" wird nicht genau passen (Antwort könnte sein: "einige von uns", "für diesen Teil des Codes" oder "wir machen Unit-Test".

Drittens, glaube ich, hat niemand gesagt (selbst Joel), dass diese Punkte, bei denen "die Einzigen Zeit wert sind" (übrigens "programmieren Sie"), nicht darauf stehen, nur dass dies gute, schnelle Fragen sind, die Sie stellen sollten, wenn Sie kommen mit einem Software-Team in Kontakt zu treten, sei es als zukünftiges Teammitglied oder sogar als Kunde - dies ist eine Liste, die ich einigen nicht-technischen Leuten in meiner Umgebung gegeben habe, die nach Hinweisen suchten, wie gut / schlecht ihre eigene IT-Abteilung war. Es ist nicht alles, aber es ist wirklich schlimm, in drei Minuten zu schlagen.