Von oben nach unten - TDD für Webanwendungen

Ich bin ein „Testing-Fanatiker“, aber ich verstehe nichts von testgetriebener Entwicklung. Dachte ich jedenfalls.

Ich habe einige Bücher und zahlreiche Blogbeiträge darüber gelesen, und alle haben ein großes Problem:

Die Beispiele sind immer zu einfach .

Diese Beispiele könnten hilfreich sein, wenn Sie beruflich einfache Texteditoren oder Taschenrechner schreiben. Ich mache das nicht und die Chancen stehen gut, dass du mit mir im selben Boot sitzt.

Wie Sie vielleicht bereits wissen, schreibe ich beruflich Webanwendungen mit Spring Framework. Lassen Sie uns herausfinden, welche Art von Problemen ich mit TDD hatte.

Lass uns ein Haus bauen

Wenn ich anfing, an einer neuen Aufgabe zu arbeiten, folgte ich normalerweise diesem Arbeitsablauf:

1. Erstellen Sie die Domänenmodellobjekte und die erforderlichen Datenbanktabellen.
2. Implementieren Sie die Repository-Schicht.
3. Implementieren Sie die Dienstebene.
4. Implementieren Sie die Webebene.

Wie Sie sehen können, baute ich Dinge gerne von unten nach oben auf, und ich hatte das Gefühl, dass TDD nicht gut zu diesem Ansatz passt. Da ich mich von unten nach oben vorgearbeitet habe, war es oft unmöglich, einen Testfall mit einer Geschäftsanforderung zu verknüpfen. Dies gab mir das Gefühl, dass ein Testfall keinen "echten" Wert hatte. Sein Wert war rein technischer Natur (stellen Sie sicher, dass der Code sauber ist und funktioniert).

Und dennoch ist es meine oberste Priorität als Softwareentwickler, das richtige Problem zu finden und es zu lösen. TDD konnte mir dabei nicht helfen, als ich diesem Arbeitsablauf folgte. Vielleicht ist das ein Grund, warum ich das Gefühl hatte, dass ich keinen Anreiz hatte, es zu benutzen.

Jedes Mal, wenn ich TDD ausprobierte, hatte ich das Gefühl, dass es mental anstrengend war, die Testfälle herauszufinden, bevor ich irgendeinen Code schrieb. Irgendwann hörte ich auf, es zu versuchen, und schrieb die Tests, nachdem mein Code fertig war. Es war supereinfach. Schließlich wusste ich genau, was getestet werden sollte, wenn mein Code fertig war.

Das ist vielleicht nicht gut .

Als ich meine Anwendungen von unten nach oben aufgebaut habe, habe ich eine wesentliche Information verpasst, die mich später oft in den Arsch beißt.

Was ist mit den Anforderungen?

Vor ein paar Tagen ging ich vom Fitnessstudio nach Hause und dachte über diesen Tweet von Kent Beck nach:

tdd ist eine gute Ausrede, um über das Problem nachzudenken, bevor man über die Lösung nachdenkt

Plötzlich machte alles Sinn für mich (das Training scheint gut für dein Gehirn zu sein). Mir wurde klar, dass TDD mich verwirrte, weil mein Arbeitsablauf fehlerhaft war. Anstatt vor der Lösung über das Problem nachzudenken, arbeitete ich mich von der Lösung zum Problem hoch.

Das bedeutet Ärger .

Wenn wir über die verschiedenen Schichten einer Webanwendung nachdenken, stellen wir fest, dass die Schicht, die dem gelösten Problem „am nächsten“ ist, die Webschicht ist. Es scheint fast offensichtlich, dass dies die Ebene ist, auf der wir mit unserer Arbeit beginnen sollten.

Lassen Sie uns darüber nachdenken, was passiert, wenn wir meinen alten Workflow umdrehen und von oben nach unten arbeiten. Das bedeutet, dass

1. Jede Ebene spezifiziert die Anforderungen für die darunter liegende Ebene . Das bedeutet, dass wir keinen Code schreiben, der nicht erforderlich ist. Natürlich ist nichts endgültig. Die Anforderungen können sich ändern und wir müssen unseren Code ändern. Dieser Ansatz eliminiert jedoch Änderungen, die durch Missverständnisse der Anforderungen verursacht wurden.
2. Wir können uns auf die Anforderungen konzentrieren und diese in Testfälle umwandeln . Wenn alle Testfälle bestanden sind, haben wir eine Software, die die gestellten Anforderungen erfüllt. Da wir die Anforderungen einer bestimmten Komponente verstehen, sollte es auch viel einfacher sein, die erforderlichen Testfälle herauszufinden, selbst wenn wir noch keinen Code geschrieben haben.

Je mehr ich darüber nachdenke, desto mehr Sinn ergibt TDD für mich. Ich habe diesen „neuen“ Ansatz mit TDD bereits ausprobiert und er sieht wirklich vielversprechend aus. Die bemerkenswerteste Verbesserung ist diese:

Es ist nicht mehr schwierig, aussagekräftige Testfälle zu finden. Ganz einfach.

Warum sollte dich dieser Scheiß interessieren?

Wenn Sie nicht daran interessiert sind, sich selbst herauszufordern, sollten Sie aufhören, Ihre Zeit zu verschwenden, und HÖREN SIE JETZT AUF ZU LESEN . Ich habe schon genug von deiner kostbaren Zeit verschwendet.

Mir ist aufgefallen, dass Entwickler manchmal denken, dass der Quellcode der Anwendung das wichtigste Ergebnis eines Softwareprojekts ist.

Das Problem ist, dass der Quellcode keinen Wert hat, wenn wir ihn nicht beweisen können

1. Löst das Problem richtig.
2. Funktioniert wie erwartet.

Aus diesem Grund ist es wichtig, automatisierte Tests zu schreiben.

Es macht mich traurig zu sehen, dass viele Entwickler ständig nach Möglichkeiten suchen, ihre Programmierkenntnisse zu verbessern, aber nur wenige dieser Entwickler suchen nach neuen Wegen, Tests zu schreiben.

Wacht auf, Leute! Tests sind auch Code!