Was ist testgetriebene Entwicklung (TDD)? Beispiel

Was ist testgetriebene Entwicklung (TDD)?

Testgetriebene Entwicklung (TDD) ist ein Softwareentwicklungsansatz, bei dem Testfälle entwickelt werden, um zu spezifizieren und zu validieren, was der Code tun wird. Vereinfacht ausgedrückt werden zuerst Testfälle für jede Funktionalität erstellt und getestet. Wenn der Test fehlschlägt, wird der neue Code geschrieben, um den Test zu bestehen und den Code einfach und fehlerfrei zu machen.

Testgetriebene Entwicklung beginnt mit dem Entwurf und der Entwicklung von Tests für jede kleine Funktionalität einer Anwendung. Das TDD-Framework weist Entwickler an, nur dann neuen Code zu schreiben, wenn ein automatisierter Test fehlgeschlagen ist. Dadurch wird eine Duplizierung des Codes vermieden. Die TDD-Vollform ist testgetriebene Entwicklung.

Das einfache Konzept von TDD besteht darin, die fehlgeschlagenen Tests zu schreiben und zu korrigieren, bevor neuer Code geschrieben wird (vor der Entwicklung). Dies trägt dazu bei, eine Duplizierung des Codes zu vermeiden, da wir jeweils nur eine kleine Menge Code schreiben, um die Tests zu bestehen. (Tests sind nichts anderes als Anforderungsbedingungen, die wir testen müssen, um sie zu erfüllen.)

Testgetriebene Entwicklung ist ein Prozess der Entwicklung und Durchführung automatisierter Tests vor der eigentlichen Entwicklung der Anwendung. Daher wird TDD manchmal auch als bezeichnet Testen Sie die erste Entwicklung.

So führen Sie einen TDD-Test durch

Die folgenden Schritte beschreiben, wie der TDD-Test durchgeführt wird.

1. Fügen Sie einen Test hinzu.
2. Führen Sie alle Tests aus und prüfen Sie, ob ein neuer Test fehlschlägt.
3. Schreiben Sie einen Code.
4. Führen Sie Tests aus und überarbeiten Sie den Code.
5. Wiederholen.

TDD-Zyklus definiert

1. Schreiben Sie einen Test
2. Lass es laufen.
3. Ändern Sie den Code, um ihn richtig zu machen, z. B. Refactor.
4. Vorgang wiederholen.

Einige Klarstellungen zu TDD:

• Beim TDD-Ansatz geht es weder um „Testen“ noch um „Design“.
• TDD bedeutet nicht: „Einige Tests schreiben und dann ein System aufbauen, das die Tests besteht.“
• TDD bedeutet nicht „viel testen“.

TDD vs. Traditionelles Testen

Im Folgenden ist der Hauptunterschied zwischen testgetriebener Entwicklung und herkömmlichem Testen aufgeführt:

Der TDD-Ansatz ist in erster Linie eine Spezifikationstechnik. Er stellt sicher, dass Ihr Quellcode auf Bestätigungsebene gründlich getestet wird.

• Bei herkömmlichen Tests werden bei einem erfolgreichen Test ein oder mehrere Fehler festgestellt. Es ist dasselbe wie TDD. Wenn ein Test fehlschlägt, haben Sie Fortschritte gemacht, weil Sie wissen, dass Sie das Problem lösen müssen.
• TDD stellt sicher, dass Ihr System die dafür definierten Anforderungen tatsächlich erfüllt. Es hilft, Ihr Vertrauen in Ihr System zu stärken.
• Bei TDD liegt der Schwerpunkt mehr auf Produktionscode, der überprüft, ob die Tests ordnungsgemäß funktionieren. Beim herkömmlichen Testen liegt der Schwerpunkt mehr auf dem Testfalldesign. Ob der Test die ordnungsgemäße/nicht ordnungsgemäße Ausführung der Anwendung zur Erfüllung der Anforderungen zeigt.
• Bei TDD erreichen Sie einen Abdeckungstest von 100 %. Im Gegensatz zu herkömmlichen Tests wird jede einzelne Codezeile getestet.
• Die Kombination aus traditionellem Testen und TDD führt dazu, dass das Testen des Systems wichtiger ist als die Perfektionierung des Systems.
• In Agile Modellierung (AM), sollten Sie „mit einem Ziel testen“. Sie sollten wissen, warum Sie etwas testen und auf welchem ​​Niveau es getestet werden muss.

Was ist Akzeptanz-TDD und Entwickler-TDD?

Es gibt zwei TDD-Ebenen

1. Akzeptanz TDD (ATDD): Mit ATDD schreiben Sie einen einzelnen Abnahmetest. Dieser Test erfüllt die Anforderung der Spezifikation bzw. stellt das Verhalten des Systems zufrieden. Schreiben Sie anschließend gerade genug Produktions-/Funktionscode, um diesen Abnahmetest zu bestehen. Der Abnahmetest konzentriert sich auf das Gesamtverhalten des Systems. ATDD war auch bekannt als Verhaltensgesteuerte Entwicklung (BDD).
2. Entwickler-TDD: Mit Developer TDD schreiben Sie einen einzelnen Entwicklertest, also einen Unit-Test, und dann gerade genug Produktionscode, um diesen Test zu erfüllen. Der Unit-Test konzentriert sich auf jede kleine Funktionalität des Systems. Entwickler-TDD wird einfach als bezeichnet TDD.Das Hauptziel von ATDD und TDD besteht darin, detaillierte, ausführbare Anforderungen für Ihre Lösung auf Just-in-Time-Basis (JIT) zu spezifizieren. JIT bedeutet, nur die Anforderungen zu berücksichtigen, die im System benötigt werden. Steigern Sie also die Effizienz.

Skalierung von TDD über Agile Model Driven Development (AMDD)

TDD ist sehr gut in der detaillierten Spezifikation und Validierung. Es gelingt ihm nicht, größere Themen wie das Gesamtdesign, die Verwendung des Systems oder die Benutzeroberfläche zu durchdenken. AMDD behebt die Probleme der agilen Skalierung, die TDD nicht löst.

Daher wird AMDD für größere Probleme eingesetzt.

Der Lebenszyklus von AMDD

Beim Model-Driven Development (MDD) werden umfangreiche Modelle erstellt, bevor der Quellcode geschrieben wird. Welche wiederum haben einen agilen Ansatz?

In der obigen Abbildung stellt jedes Kästchen eine Entwicklungsaktivität dar.

Die Visualisierung ist einer der TDD-Prozesse zum Vorhersagen/Vorstellen von Tests, die während der ersten Projektwoche durchgeführt werden. Das Hauptziel der Visualisierung ist die Identifizierung des Systemumfangs und der Systemarchitektur. Für eine erfolgreiche Visualisierung werden Anforderungen auf hoher Ebene und Architekturmodellierung durchgeführt.

Dabei handelt es sich um den Prozess, bei dem nicht eine detaillierte Spezifikation der Software/des Systems erstellt wird, sondern die Anforderungen der Software/des Systems untersucht werden, der die Gesamtstrategie des Projekts definiert.

Iteration 0: Vorstellung

Es gibt zwei Hauptunteraktivatoren.

1. Erste Anforderungsvorstellung.Es kann mehrere Tage dauern, bis die allgemeinen Anforderungen und der Umfang des Systems ermittelt sind. Der Hauptschwerpunkt liegt auf der Erforschung des Nutzungsmodells, des anfänglichen Domänenmodells und des Benutzeroberflächenmodells (UI).
2. Initiale Archistrukturelle Vorstellung. Es dauert auch mehrere Tage, die Architektur des Systems zu identifizieren. Dadurch können technische Richtungen für das Projekt festgelegt werden. Der Schwerpunkt liegt auf der Untersuchung von Technologiediagrammen, dem Benutzeroberflächenfluss (UI), Domänenmodellen und Änderungsfällen.

Iterationsmodellierung

Hier muss das Team die Arbeit planen, die für jede Iteration durchgeführt werden soll.

• Für jede Iteration wird ein agiler Prozess verwendet, d. h. während jeder Iteration werden neue Arbeitselemente mit Priorität hinzugefügt.
• Dabei werden zunächst höher priorisierte Arbeiten berücksichtigt. Hinzugefügte Arbeitselemente können jederzeit neu priorisiert oder aus dem Elementstapel entfernt werden.
• Das Team bespricht, wie es die einzelnen Anforderungen umsetzen wird. Zu diesem Zweck wird Modellierung eingesetzt.
• Für jede Anforderung, die in dieser Iteration implementiert werden soll, wird eine Modellierungsanalyse und ein Design durchgeführt.

Modelsturm

Dies wird auch als Just-in-Time-Modellierung bezeichnet.

• Bei dieser Modellierungssitzung ist ein Team von 2/3 Mitgliedern beteiligt, die Probleme auf Papier oder am Whiteboard besprechen.
• Ein Teammitglied wird ein anderes Teammitglied bitten, mit ihm zu modellieren. Diese Modellierungssitzung dauert etwa 5 bis 10 Minuten. Wo Teammitglieder zusammenkommen, um Whiteboard/Papier auszutauschen.
• Sie untersuchen Probleme, bis sie die Hauptursache des Problems nicht mehr finden. Wenn ein Teammitglied gerade noch rechtzeitig das Problem erkennt, das es lösen möchte, wird es schnell die Hilfe anderer Teammitglieder in Anspruch nehmen.
• Anschließend beschäftigen sich die anderen Gruppenmitglieder mit dem Thema und dann machen alle weiter wie bisher. Es wird auch als Stand-up-Modellierung oder Kunden-QA-Sitzung bezeichnet.

Testgetriebene Entwicklung (TDD)

• Es unterstützt bestätigende Tests Ihres Anwendungscodes und detaillierter Spezifikationen.
• Sowohl Abnahmetests (detaillierte Anforderungen) als auch Entwicklertests (Einheitentests) sind Eingaben für TDD.
• TDD macht den Code einfacher und klarer. Dadurch muss der Entwickler weniger Dokumentation pflegen.

Bewertungen

• Dies ist optional. Es umfasst Codeinspektionen und Modellüberprüfungen.
• Dies kann für jede Iteration oder für das gesamte Projekt erfolgen.
• Dies ist eine gute Möglichkeit, Feedback zum Projekt zu geben.

Testgetriebene Entwicklung (TDD) vs. Agile Model Driven Development (AMDD)

TDD	AMDD
TDD verkürzt die Programmier-Feedbackschleife	AMDD verkürzt die Modellierungs-Feedbackschleife.
TDD ist eine detaillierte Spezifikation	AMDD eignet sich für größere Probleme
TDD fördert die Entwicklung von qualitativ hochwertigem Code	AMDD fördert eine qualitativ hochwertige Kommunikation mit Stakeholdern und Entwicklern.
TDD spricht mit Programmierern	AMDD spricht mit Geschäft Analytikerin, Stakeholder und Datenexperten.
TDD nicht visuell orientiert	AMDD visuell orientiert
TDD hat einen begrenzten Anwendungsbereich für Softwarearbeiten	AMDD hat einen breiten Anwendungsbereich, der auch Interessengruppen einschließt. Es geht darum, auf ein gemeinsames Verständnis hinzuarbeiten
Beide unterstützen die evolutionäre Entwicklung	---------------

TDD-Frameworks

Hier ist die Liste der besten TDD-Frameworks (Test Driven Development).

1. Juni
2. TestNG
3. csUnit und NUnit
4. Rspez

Lassen Sie uns nun die testgetriebene Entwicklung anhand eines Beispiels erlernen.

Beispiel für TDD

Hier in diesem Beispiel für testgetriebene Entwicklung definieren wir ein Klassenkennwort. Für diese Klasse versuchen wir, die folgenden Bedingungen zu erfüllen.

Eine Bedingung für die Passwortakzeptanz:

• Das Passwort sollte zwischen 5 und 10 Zeichen lang sein.

In diesem TDD-Beispiel schreiben wir zunächst den Code, der alle oben genannten Anforderungen erfüllt.

Szenario 1: Um den Test auszuführen, erstellen wir die Klasse PasswordValidator ();

Wir werden die obige Klasse TestPassword () ausführen;

Die Ausgabe ist wie unten gezeigt PASSED;

Ausgang:

Szenario 2: Hier können wir sehen, dass in der Methode TestPasswordLength() keine Instanz der Klasse PasswordValidator erstellt werden muss. Instanz bedeutet das Erstellen einer Objekt der Klasse, um auf die Mitglieder (Variablen/Methoden) dieser Klasse zu verweisen.

Wir werden die Klasse PasswordValidator pv = new PasswordValidator() aus dem Code entfernen. Wir können das anrufen ist gültig () Methode direkt von PasswortValidator. IsValid („Abc123“). (Siehe Bild unten)

Also führen wir eine Umgestaltung (Codeänderung) wie folgt durch:

Szenario 3: Nach dem Refactoring zeigt die Ausgabe den Status „Fehlgeschlagen“ an (siehe Abbildung unten). Dies liegt daran, dass wir die Instanz entfernt haben. Es gibt also keinen Verweis auf eine nicht statische Methode ist gültig ().

Daher müssen wir diese Methode ändern, indem wir vor dem booleschen Wert ein „statisches“ Wort als öffentlichen statischen booleschen Wert isValid (String-Passwort) hinzufügen. Refactoring der Klasse PasswordValidator(), um den oben genannten Fehler zu entfernen und den Test zu bestehen.

Ausgang:

Nachdem wir Änderungen an der Klasse PassValidator() vorgenommen haben, wird die Ausgabe wie unten gezeigt als PASSED angezeigt, wenn wir den Test ausführen.

Vorteile von TDD

Im Folgenden sind die Hauptvorteile der testgetriebenen Entwicklung in der Softwareentwicklung aufgeführt:

Frühzeitige Fehlerbenachrichtigung.

• Entwickler testen ihren Code, aber in der Datenbankwelt besteht dies oft aus manuellen Tests oder einmaligen Skripten. Mit TDD bauen Sie im Laufe der Zeit eine Reihe automatisierter Tests auf, die Sie und jeder andere Entwickler nach Belieben wiederholen können.

Besser gestalteter, saubererer und erweiterbarer Code.

• Es hilft zu verstehen, wie der Code verwendet wird und wie er mit anderen Modulen interagiert.
• Dies führt zu einer besseren Entwurfsentscheidung und einem besser wartbaren Code.
• TDD ermöglicht das Schreiben kleinerer Codes mit einer einzelnen Verantwortung anstelle monolithischer Prozeduren mit mehreren Verantwortlichkeiten. Dadurch ist der Code einfacher zu verstehen.
• TDD zwingt außerdem dazu, nur Produktionscode zu schreiben, um Tests basierend auf Benutzeranforderungen zu bestehen.

Vertrauen in Refactor

• Wenn Sie Code umgestalten, kann es zu Brüchen im Code kommen. Mit einer Reihe automatisierter Tests können Sie diese Fehler vor der Veröffentlichung beheben. Wenn bei der Verwendung automatisierter Tests Unterbrechungen festgestellt werden, wird eine entsprechende Warnung ausgegeben.
• Die Verwendung von TDD sollte zu einem schnelleren, erweiterbareren Code mit weniger Fehlern führen, der mit minimalen Risiken aktualisiert werden kann.

Gut für die Teamarbeit

• Wenn kein Teammitglied anwesend ist, können andere Teammitglieder problemlos den Code übernehmen und daran arbeiten. Es unterstützt auch den Wissensaustausch und macht das Team dadurch insgesamt effektiver.

Gut für Entwickler

• Obwohl Entwickler mehr Zeit für das Schreiben von TDD-Testfällen aufwenden müssen, nimmt das Debuggen und die Entwicklung neuer Funktionen viel weniger Zeit in Anspruch. Sie werden saubereren, weniger komplizierten Code schreiben.

Zusammenfassung

• TDD steht für Testgetriebene Entwicklung.
• TDD-Bedeutung: Es handelt sich um einen Prozess, bei dem der Code geändert wird, um einen zuvor entwickelten Test zu bestehen.
• Der Schwerpunkt liegt mehr auf Produktionscode als auf Testfalldesign.
• Bei der testgetriebenen Entwicklung handelt es sich um einen Prozess, bei dem der Code geändert wird, um einen zuvor entwickelten Test zu bestehen.
• In Software Engineering, Es wird manchmal als bekannt „Testen Sie die erste Entwicklung.“
• TDD-Tests umfassen das Refactoring eines Codes, dh das Ändern/Hinzufügen einer bestimmten Codemenge zum vorhandenen Code, ohne das Verhalten des Codes zu beeinflussen.
• Bei Verwendung der TDD-Programmierung wird der Code klarer und einfacher zu verstehen.