Erfahren Sie, wie die Continuous Quality Platform von Parasoft dabei hilft, Testumgebungen zu steuern und zu verwalten, um zuverlässig hochwertige Software zu liefern. Für Demo registrieren >>

BLOG

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

4 Tipps zur Einführung von Test Driven Development (TDD) in Ihrem Unternehmen Lesezeit: 6 Minuten
Wie können Sie TDD erfolgreich in Ihrem Unternehmen einführen? In diesem Blog: Tipps zur Maximierung der Vorteile der Einführung von TDD und eine Untersuchung des Spektrums der Einführung von TDD von puristisch bis TDD.

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 der testgetriebenen Entwicklung (TDD)

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

1. Anwenden von TDD auf Legacy-Code

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. Anwenden von TDD auf Microservices

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 SOAtestkann dann automatisch Tests basierend auf diesen Definitionen erstellen. Jetzt können Sie die Funktionalität gemäß den Definitionen entwickeln, bis die SOAtest-Tests bestanden sind.

3. Aktivieren des Teams

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.

Durch die Nutzung der TDD-Praktiken auf API-Ebene, wie oben für Microservices beschrieben, können Sie das Problem begrenzter technischer Ressourcen lösen, indem Sie das Fachwissen der Tester nutzen, um Tests für den Vertrag zu definieren. Mit diesem Ansatz können Geschäftsanalysten, Tester und andere Ressourcen, die keine Entwickler sind, 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. TDD mit BDD erweitern

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 Klebercodes und der Schrittdefinitionen verringern, für die normalerweise Entwicklerressourcen erforderlich sind.

Fazit

Das Versprechen einer testgetriebenen Entwicklung basiert auf einem schlanken Entwicklungsethos. Es soll Ihnen helfen, effizienten, testbaren und wartbaren Code zu erstellen. Die realen Bedingungen machen die Einführung von TDD jedoch nicht immer einfach. Parasoft hilft Ihnen dabei, TDD-Praktiken auf eine für Ihr Unternehmen praktische Weise anzuwenden, sodass Sie Ihre Entwicklungs- / Testressourcen maximieren können. Kontaktieren Sie uns Einzelheiten dazu, wie wir Ihnen bei der Implementierung von TDD in Ihrem Unternehmen helfen können.

Geschrieben von

Mark Lambert

Mark, Vice President of Products bei Parasoft, ist dafür verantwortlich, dass Parasoft-Lösungen den Unternehmen, die sie einsetzen, einen echten Mehrwert bieten. Mark ist seit 2004 bei Parasoft und arbeitet mit einem breiten Querschnitt von Global 2000-Kunden zusammen, von spezifischen Technologieimplementierungen bis hin zu umfassenderen Initiativen zur Verbesserung von SDLC-Prozessen.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.