4 Tipps zur Einführung von Test Driven Development (TDD) in Ihrem Unternehmen

Wie führen Sie TDD erfolgreich in Ihrem Unternehmen ein?

Erfahren Sie, wie Sie die Vorteile der Einführung von TDD maximieren können, und erkunden Sie das Spektrum der Einführung von TDD, von puristisch bis TDD-artig.

Bei der testgetriebenen Entwicklung (TDD) geht es darum, schlanken und mittleren Code mit einer hohen Testabdeckung zu schreiben. Entwickler schreiben den Test für eine Anforderung, bevor sie den Code schreiben, und der Code gilt als beendet, sobald der Test bestanden ist. Hört sich gut an, aber wie können Sie TDD erfolgreich in Ihrem Unternehmen einführen? Wir werden dies hier untersuchen und Ihnen einige Tipps geben, um die Vorteile der Einführung von TDD zu maximieren.

Warum TDD?

Der Hauptvorteil von TDD besteht darin, dass Entwickler wartbaren und testbaren Code erstellen können. TDD verhindert auch das Kriechen von Merkmalen und das „Vergolden“ des Codes, indem sichergestellt wird, dass der zur Implementierung der Funktionalität erforderliche Mindestcode erstellt wird. Durch die Überprüfung, ob der richtige Code geschrieben wird, werden die Teams effizienter und es wird vermieden, wertvolle Entwicklungsressourcen für den Aufbau der falschen Funktionalität zu verschwenden.

Das Befolgen von TDD erzwingt Unit-Tests als eine Praxis innerhalb der Organisation. Dies ist jedoch kein Unit-Test, um Unit-Tests zu ermöglichen. Auf diese Weise können Sie sicherstellen, dass Sie testbaren Code erstellen, um die Wartungskosten zu senken und die technischen Schulden niedrig zu halten. Indem Sie sicherstellen, dass Sie über eine solide Regressionssuite verfügen, werden Sie sofort benachrichtigt, wenn aufgrund von Codeänderungen ein Fehler auftritt.

Ein wichtiger Grund für das zunehmende Interesse an TDD ist, dass viele Unternehmen auf agile Entwicklungspraktiken umsteigen und erkennen, dass ihre bestehenden Testpraktiken zu stark auf manuellen Tests am Ende des Zyklus beruhen. Es gibt sicherlich einen Platz für End-to-End-Testpraktiken, aber um Entwicklungsinnovationen mit der Geschwindigkeit zu skalieren, die erforderlich ist, um wettbewerbsfähig zu bleiben, müssen Unternehmen die Testbemühungen nach links verlagern. TDD ist ein Prozess, der beinahe garantiert, dass Sie Entwicklungsprojekte mit einer gesunden Testbasis starten, um die Softwarequalität während des gesamten Entwicklungslebenszyklus sicherzustellen.

Das TDD-Spektrum

Aus praktischen Gründen folgen nur sehr wenige Menschen, die Software entwickeln, aus mehreren Gründen der reinen Vision von TDD. Bei der modernen Softwareentwicklung werden normalerweise Bibliotheken integriert, Legacy-Code verbunden und vorhandene Funktionen erweitert. Viele Menschen haben nicht den Luxus, völlig neuen Code zu schreiben, daher ist reines TDD in vielen Fällen nicht praktikabel. Stattdessen sitzen viele Leute, die TDD machen, irgendwo in einem Spektrum, das ungefähr so ​​aussieht:

Während jede Organisation ihre eigenen spezifischen Herausforderungen mit TDD hat, passen die Probleme, über die wir von unseren Kunden am meisten hören, in die drei oben genannten Grundtypen. Innerhalb dieses Spektrums gibt es jedoch viele Arten von TDD-Praktikern:

TDD-Ninjas

An einem Ende des Spektrums stehen Menschen, die erfolgreich TDD auf der Ebene des „schwarzen Gürtels“ praktizieren. Diese Leute sind voll und ganz den TDD-Prinzipien verpflichtet und schreiben nicht etwas vor dem Schreiben von Tests - kein Skelett, keine Definitionen, kein Nuthin '- und sind fertig, sobald der Test bestanden ist. Infolgedessen ist der Code hocheffizient und in hohem Maße wartbar. Wenn wir mit TDD-Ninjas sprechen, erkennen sie häufig an, dass ihr Erfolg bei der Implementierung von TDD in den Teams innerhalb ihrer Organisation uneinheitlich ist.

TDD Pragmatiker

Die nächsten im Spektrum sind Personen, die möglicherweise Klassen, Methodensignaturen usw. entwerfen und dann Tests anhand dieser Definitionen schreiben. Auf API-Ebene entspricht dies dem Schreiben der OpenAPI / Swagger- oder WSDL-Definition. Wir nennen dies den pragmatischen Ansatz für TDD.

Dieser Ansatz ist etwas einfacher anzuwenden, da er mehr Struktur und Klarheit bietet. Alles wird kompiliert, damit ein Team leichter zusammenarbeiten kann. Der mögliche Kompromiss besteht jedoch darin, dass TDD-Pragmatiker möglicherweise nicht immer das hocheffiziente, minimale Code-Design erreichen, das von TDD-Ninjas erreicht wird.

TDD für Legacy

Es gibt viele Menschen, die sich gerne voll und ganz für TDD engagieren würden, aber nicht den Luxus haben, mit Greenfield-Code zu beginnen. Diese Leute erstellen häufig Tests, um einen Fehler zu reproduzieren oder das erwartete Verhalten zu testen, um vorhandene Funktionen basierend auf Legacy-Code zu ändern oder zu erweitern.

Nach unserer Erfahrung befindet sich ein großer Teil derjenigen, die sich selbst als praktizierende TDD identifizieren, an oder nahe diesem Punkt im Spektrum. Die Logik ist, dass der Test und der Code zwar untrennbar miteinander verbunden sind, der Test jedoch nicht unbedingt vorausgehen der Code. Tests gehen jedoch dem voraus Änderungen zum Code.

TDD-artig

Am anderen Ende unseres Spektrums derjenigen, die sich selbst als TDD identifizieren, stehen Menschen, die parallel testen und codieren. Für TDD-Praktiker gilt die Entwicklung als testgetrieben, solange Test und Code gemeinsam festgeschrieben und verwaltet werden.

4 Tipps zur Implementierung von testgetriebener Entwicklung (TDD)

Wie können Sie TDD erfolgreich einführen? Befolgen Sie die folgenden vier Tipps, um einen TDD-Erfolg zu erzielen.

1. TDD auf Legacy-Code anwenden

Ein häufiges TDD-Implementierungsproblem ist hässlich, wenn eine Organisation nicht testbaren Code geerbt hat und nicht in der Lage ist, die technischen Schulden zu begleichen. Sollte der Code überarbeitet werden? Wenn ja, wie viel Refactoring ist erforderlich, um TDD auf sinnvolle und erreichbare Weise zu üben?

Wenn es ein Mandat gibt, TDD für Legacy-Code auszuführen, funktioniert der Versuch, ein ideales TDD zu implementieren, nicht. Der Code, den Sie erben, wurde nicht unter Berücksichtigung der Testbarkeit erstellt. Der ursprüngliche Autor befindet sich möglicherweise nicht mehr im Team oder sogar in der Organisation, die abhängigen Bibliotheken haben sich möglicherweise geändert und so weiter.

Wenn der Legacy-Code bereits vorhanden ist und funktioniert, ist das mit der technischen Verschuldung verbundene Risiko im Verhältnis zum Risiko neuer, nicht getesteter Arbeiten gering. Indem Sie TDD auf den neuen Code anwenden, den Sie schreiben, dh Änderungen am vorhandenen Code, minimieren Sie das Risiko und erhöhen nicht die technische Verschuldung.

Um die Herausforderungen beim Testen des vorhandenen Codes zu bewältigen, können Sie verwenden Parasoft Jtest's Unit-Testing-Fähigkeit, um schnell aussagekräftige Tests zu erstellen. Parasoft Jtest analysiert den Legacy-Code und seine Abhängigkeiten und reduziert so den Zeitaufwand für die Erstellung von JUnit-Testfällen und die Implementierung des komplexen Stubbing/Mocking, das für den bereits vorhandenen Code erforderlich ist.

2. Wenden Sie TDD auf Microservices an

Microservice-basierte Architekturen weisen weitaus mehr Abhängigkeiten und Komplexität auf als herkömmliche Anwendungsstapel, wodurch die Testumgebung erheblich volatiler wird. Das Erstellen von Tests für Anwendungen, die auf Microservices und anderen komplexen Architekturen basieren, kann schwierig sein, da fortgeschrittenes Verspotten und Stubben erforderlich ist.

Eine auf Mikroservices basierende Architektur bietet jedoch die Möglichkeit, TDD-Best Practices auf sehr effiziente Weise zu nutzen. Wenn Sie darüber nachdenken, den Microservice als Einheit und nicht als Kompilierungseinheit zu behandeln, ist der pragmatistische Ansatz von TDD sehr nützlich.

Bei der Anwendung von TDD auf API-Ebene wird Ihre API im Vertrag definiert (OpenAPI/Swagger, WSDL). Ein API-Testlösung, sowie Parasoft SOAtest, kann dann basierend auf diesen Definitionen automatisch Tests erstellen. Sie sind bereit, Funktionalität gemäß den Definitionen zu entwickeln, bis die SOAtest-Tests bestanden sind.

3. Aktivieren Sie den Trupp

TDD wird allgemein als eine auf Entwickler ausgerichtete Aktivität angesehen, die normalerweise durch das Erstellen von Tests in einem gekapselt wird Unit-Test-Framework, wie JUnit oder NUnit. Die meisten Organisationen haben jedoch einfach nicht genug Entwickler oder Zeit, um alle ihre Anwendungsfälle abzudecken. Dies ist besonders ein Problem für Unternehmensorganisationen, die eine Mischung aus Rollen und Fähigkeiten haben, die zu ihren Projekten beitragen.

Die Nutzung von TDD-Praktiken auf API-Ebene, wie oben für Microservices beschrieben, hilft Ihnen, das Problem der begrenzten technischen Ressourcen anzugehen, indem Sie das Fachwissen der Tester nutzen können, um Tests gegen den Vertrag zu definieren. Mit diesem Ansatz können Geschäftsanalysten, Tester und andere Nicht-Entwicklerressourcen zu den TDD-Testbemühungen beitragen.

Sie können auch eine Service-Virtualisierungslösung verwenden, z Parasoft Virtualisieren, um sofort simulierte Funktionen zu erstellen, mit denen Sie Tests erstellen und ausführen können, bevor Code geschrieben wird.

4. Verbessern Sie TDD mit BDD

Wie wir bereits besprochen haben, bietet die Implementierung von TDD mehrere Vorteile, aber TDD selbst übersetzt nicht unbedingt in Code, der den Anforderungen entspricht. Es wird nur sichergestellt, dass der Code von Tests abgedeckt wird und die Tests bestanden werden. Hier ist wo Verhalten-driven Development (BDD) kommt ins Spiel. Anstatt Code zu schreiben, bis der Test bestanden ist, schreiben Entwickler Code, bis das Verhalten implementiert ist.

Es sei darauf hingewiesen, dass in der Vergangenheit versucht wurde, den Funktionsrahmen vor dem Schreiben des Codes zu definieren. (Erinnert sich jemand an Design by Contract (DbC)?) Tatsächlich ist BDD der jüngste Versuch, einen solchen Ansatz umzusetzen. In BDD (oder DbC) müssen die Vor- und Nachbedingungen definiert werden, bevor ein Test oder Code erstellt wird.

BDD stellt eine Gelegenheit dar, TDD auf die nächste Stufe zu heben. Wenn Sie eine BDD-Sprache wie Gherkin verwenden, können Sie Automatisierungstests skalieren. Und Parasoft SOAtest (für API-Tests) und Parasoft Selenic (für Selengesteuerte UI-Tests) kann die technische Komplexität beim Schreiben des erforderlichen Glue-Codes und der Schrittdefinitionen verringern, die normalerweise Entwicklerressourcen erfordern.

Fazit

Das Versprechen der testgetriebenen Entwicklung basiert auf einem schlanken Entwicklungsethos. Es soll Ihnen dabei helfen, effizienten, testbaren und wartbaren Code zu erstellen. Aber reale Bedingungen machen die Einführung von TDD nicht immer einfach. Parasoft hilft Ihnen, TDD-Praktiken auf eine für Ihr Unternehmen praktische Weise anzunehmen, sodass Sie Ihre Entwicklungs-/Testressourcen maximieren können.