Testgetriebene Entwicklung entschlüsselt

Das Customer Care Technology Team der New York Times nutzt Scrum als Hauptprozess, um Sprints zu planen, den Backlog durchzugehen, Stories auszuwählen und diese den Ingenieuren zuzuweisen, die die Story dann erledigen. Aufgrund unvorhergesehener Hindernisse wurden die Stories jedoch meist in den nächsten Sprint verschoben. Um dies zu lösen, begannen sie, für ganze Sprints zusammenzuarbeiten (Swarming) und sich jeweils nur mit einer kleinen Anzahl von Stories zu beschäftigen. Beim Swarming konzentrieren sich agile Entwicklungsteams auf eine Story, um sie abzuschließen, bevor sie mit einer neuen Story beginnen. Eine der wichtigsten Techniken des Swarming, die sie anwendeten, war die testgetriebene Entwicklung (TDD), bei der man zuerst den Test schreibt, ihn fehlschlagen sieht und anschließend die Funktion schreibt. Während ein Ingenieur Komponententests und Integrationstests schrieb, arbeitete ein anderer Ingenieur an der zugrunde liegenden Funktionalität.

Testgetriebene Entwicklung hat sich als erstaunliche Lösung für ein großes Unternehmen wie die New York Times erwiesen. Aber wie ist so etwas wie TDD entstanden? Die Agile Alliance gibt an, dass die Veröffentlichung von "Test Driven Development: By Example" von Kent Beck im Jahr 2003 zur Entstehung von TDD führte.

Technology Conversations definiert TDD als einen "Softwareentwicklungsprozess, der auf der Wiederholung eines sehr kurzen Entwicklungszyklus beruht: Zuerst schreibt der Entwickler einen (zunächst fehlschlagenden) automatisierten Testfall, der eine gewünschte Verbesserung oder neue Funktion definiert, dann produziert er die minimale Menge an Code, um diesen Test zu bestehen, und schließlich refaktorisiert er den neuen Code auf akzeptable Standards."

Sie unterscheidet sich von traditionellen Tests, wie in der folgenden Tabelle beschrieben.

Es gibt verschiedene Tools, die für die testgetriebene Entwicklung nützlich sein können. Zum Beispiel ist JUnit ein Unit-Testing-Framework, das für die Java-Programmierungssprache entwickelt wurde. Oder Sie können JMeter für Last-/Performance-Tests verwenden. Mockito, als Open-Source-Testing-Framework für Java, kann ebenfalls eine große Hilfe sein.

Die testgetriebene Entwicklung folgt einem "Red-Green-Refactor"-Zyklus. Zuerst erstellen Sie einen Test, gefolgt von gerade genug Code, um das Programm zu kompilieren, aber nicht genug, um den Test fehlschlagen zu lassen. Dann erstellen Sie gerade genug Code, um den Test zu bestehen. Nun beginnt der Refactoring-Prozess, bei dem Sie das Design des Codes verbessern, den Sie gerade implementiert haben. Sie führen Unit-Tests erneut aus, und die Tests sollten bestanden werden. Dann wiederholen Sie den Zyklus jeden Tag zwischen ein paar neuen Tests pro Minute bis zu ein paar Minuten pro neuem Test.

Die testgetriebene Entwicklung folgt einem "Red-Green-Refactor"-Zyklus

Das Beste an TDD ist, dass es Ihnen erlaubt, beim Schreiben von Software kleine Schritte zu machen. Zum Beispiel haben Sie vielleicht etwas neuen funktionalen Code hinzugefügt, kompiliert und getestet. Ihre Tests könnten durch Defekte im neuen Code unterbrochen werden, und es ist viel einfacher, diese Defekte zu finden und zu beheben, wenn Sie drei neue Codezeilen geschrieben haben als dreitausend. Die meisten Beschwerden über TDD beziehen sich auf die Geschwindigkeit und die Menge an zusätzlichem Code, die benötigt wird, um die Dinge zum Laufen zu bringen.

Joe Birch, ein leitender Android-Ingenieur bei Buffer, sagt, dass die TDD-Praxis die Entwicklungszeit für sein Team tatsächlich reduziert hat. Und Nitzan Blouin, Director of Engineering bei Spotify, hat Test Certified für Data-Focused Teams implementiert, ein spielerisches, mehrstufiges Programm, um Teams dazu zu bringen, ihre Testpraktiken und die Testabdeckung zu verbessern. Arylee McSweaney, die Test Engineering und Strategie bei Etsy leitet, sagt, dass die Fokussierung auf Testautomatisierung Etsy geholfen hat, die Engineering-Produktivität zu steigern, die Codequalität zu verbessern und das Vertrauen in die auf der Website eingeführten Funktionen zu erhöhen.

Daher bedeutet die Natur von TDD, dass die Ausübung von TDD Ihre Programmiererfahrung in einen fortwährenden Strom von Momenten verwandelt, in denen die Schritte eines Tests, der zuvor einen Fehler geworfen hatte, beginnen, bestanden zu werden. Das transformativste an der testgetriebenen Entwicklung ist, dass es eine befriedigendere Art der Entwicklung ist und Sie am Ende eine Testsuite und einen saubereren Code erhalten, der funktioniert.