Vier Tipps für die Einführung
Effizienter mit Test-Driven Development
Fortsetzung des Artikels von Teil 1
Mehr Abhängigkeiten
2. TDD auf Microservices
Auf Microservices basierende Architekturen weisen deutlich mehr Abhängigkeiten und Komplexität auf als traditionelle Applikations-Stacks, wodurch die Testumgebung deutlich volatiler wird. Das Erstellen von Tests für Anwendungen auf der Basis von Microservices und anderen komplexen Architekturen kann sich wegen der Forderung nach umfangreichem Mocking und Stubbing schwierig gestalten. Allerdings bietet eine auf Microservices basierende Architektur die Gelegenheit, erprobte TDD-Verfahrensweisen höchst effizient anzuwenden. Betrachtet man den Microservice als das Modul und nicht als die Kompilierungseinheit, erweist sich die Vorgehensweise des TDD-Pragmatikers als sehr nützlich. Wendet man das TDD auf der API-Ebene an, wird das API im Vertrag definiert (OpenAPI/Swagger, WSDL). In einem solchen Fall kann eine API-Testlösung (beispielsweise Parasoft SOAtest) anschließend automatisch Tests auf der Basis dieser Definitionen erstellen; danach lassen sich Funktionalitäten gemäß den Definitionen entwickeln, bis diese die Tests bestehen.
Jobangebote+ passend zum Thema
3. Die ganze Mannschaft ins Boot holen
Gemeinhin wird das TDD als eine entwicklergetriebene Aktivität betrachtet, die meist in sich abgeschlossen ist, indem die Tests in einem Modultest-Framework wie JUnit oder NUnit erstellt werden. Die meisten Unternehmen aber verfügen über weder genügend Entwickler noch die notwendige Zeit, um sämtliche Testfälle abzudecken.
Die Anwendung der TDD-Praktiken auf der API-Ebene, wie es zuvor für Microservices beschrieben wurde, hilft bei der Lösung des Problems der eingeschränkten technischen Ressourcen, indem man die Möglichkeit erhält, beim Definieren von Tests anhand der Verträge auf Tester-Know-how zurückzugreifen. Bei dieser Vorgehensweise können Analysten, Tester und andere Ressourcen neben den Entwicklern zu den TDD-Testvorhaben beitragen. Hier bietet sich auch der Einsatz einer Service-Virtualisierungslösung (beispielsweise Parasoft Virtualize) an, zur sofortigen Realisierung von simulierter Funktionalität, die sich zum Erstellen und Ausführen von Tests nutzen lässt, bevor irgendwelcher Code geschrieben wird.
4. Aufwertung von TDD durch BDD
Auch wenn das TDD-Konzept viele Vorteile mit sich bringt, führt es von sich aus nicht zu Code, der den Anforderungen entspricht. Es stellt nur sicher, dass der Code von Tests abgedeckt wird und dass er diese Tests besteht. An dieser Stelle kommt die verhaltensgetriebene Entwicklung (Behavior-Driven Development, BDD) ins Spiel. Hier wird der Code nicht so geschrieben, dass er den Test besteht, sondern dass das vorgesehene Verhalten implementiert wird.
Schon früher gab es Ansätze, den funktionalen Rahmen zu definieren, bevor der Code geschrieben wird – Stichwort Design by Contract. BDD ist tatsächlich der neueste Versuch, ein solches Konzept zu implementieren. Beim BDD (oder gern auch DbC) müssen die vorher und nachher geltenden Bedingungen definiert werden, bevor es ans Testen oder Codieren geht. BDD bietet eine Chance, mit TDD ein neues Niveau zu erreichen. Arbeitet man mit einer BDD-Sprache wie Gherkin, können Tools wie Parasoft SOAtest die mit der Implementierung von BDD einhergehenden technischen Hürden reduzieren. Es erzeugt automatisch Tests aus dem Feature-File und verringert die technische Komplexität für das Schreiben von Glue-Code, der normalerweise Entwickler-Ressourcen beansprucht.
Die Erwartungen an die testgetriebene Entwicklung basieren auf dem Konzept der schlanken Entwicklung. Das TDD soll beim Erstellen von effizientem, prüf- und pflegbarem Code helfen. Allerdings machen die in der Praxis herrschenden Bedingungen die Einführung des TDD nicht immer leicht. Damit Unternehmen Entwicklungs- und Testressourcen maximal ausschöpfen können, sollten sie nicht zögern, Unterstützung in Anspruch zu nehmen.
- Effizienter mit Test-Driven Development
- Mehr Abhängigkeiten
Lesen Sie mehr zum Thema
