Was ist Test Driven Development (TDD)? Tutorial mit Beispiel

Testgetriebene Entwicklung

Test Driven Development (TDD) ist ein Softwareentwicklungsansatz, bei dem Testfälle entwickelt werden, um zu spezifizieren und zu validieren, was der Code tun wird. In einfachen Worten, Testfälle für jede Funktionalität werden zuerst 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 gestalten.

Testgetriebene Entwicklung beginnt mit dem Entwerfen und Entwickeln von Tests für jede kleine Funktionalität einer Anwendung. TDD weist Entwickler an, nur dann neuen Code zu schreiben, wenn ein automatisierter Test fehlgeschlagen ist. Dies vermeidet die Vervielfältigung von Code. Die vollständige Form von TDD ist die 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 hilft, Doppelarbeit zu vermeiden, da wir jeweils 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 zum Entwickeln und Ausführen automatisierter Tests vor der eigentlichen Entwicklung der Anwendung. Daher wird TDD manchmal auch als Test First Development bezeichnet.

In diesem Tutorial erfahren Sie mehr über-

So führen Sie einen TDD-Test durch
TDD Vs. Traditionelles Testen
Was ist Akzeptanz TDD und Entwickler TDD
Skalierung von TDD über Agile Model Driven Development (AMDD)
Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
Beispiel für TDD
Vorteile von TDD

So führen Sie einen TDD-Test durch

Die folgenden Schritte definieren, wie der TDD-Test durchgeführt wird:

Fügen Sie einen Test hinzu.
Führen Sie alle Tests aus und prüfen Sie, ob ein neuer Test fehlschlägt.
Schreiben Sie einen Code.
Führen Sie Tests und Refactor-Code aus.
Wiederholen.

TDD-Zyklus definiert

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

Einige Erläuterungen zu TDD:

Bei TDD geht es weder um "Testen" noch um "Design".
TDD bedeutet nicht, dass Sie einige der Tests schreiben und dann ein System erstellen, das die Tests besteht.
TDD bedeutet nicht "viel testen".

TDD Vs. Traditionelles Testen

Der TDD-Ansatz ist in erster Linie eine Spezifikationstechnik. Es 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 bei TDD. Wenn ein Test fehlschlägt, haben Sie Fortschritte erzielt, weil Sie wissen, dass Sie das Problem beheben müssen.
TDD stellt sicher, dass Ihr System tatsächlich die dafür definierten Anforderungen erfüllt. Dies hilft Ihnen, Ihr Vertrauen in Ihr System zu stärken.
In TDD liegt der Schwerpunkt mehr auf dem Produktionscode, der überprüft, ob das Testen ordnungsgemäß funktioniert. Bei herkömmlichen Tests liegt der Schwerpunkt mehr auf dem Design von Testfällen. Ob der Test die ordnungsgemäße / nicht ordnungsgemäße Ausführung der Anwendung zur Erfüllung der Anforderungen zeigt.
In TDD erreichen Sie einen 100% igen Abdeckungstest. Im Gegensatz zu herkömmlichen Tests wird jede einzelne Codezeile getestet.
Die Kombination von herkömmlichem Testen und TDD führt dazu, dass das System eher getestet als perfektioniert werden muss.
In Agile Modeling (AM) sollten Sie "mit einem Zweck testen". Sie sollten wissen, warum Sie etwas testen und auf welcher Ebene es getestet werden muss.

Was ist Akzeptanz TDD und Entwickler TDD

Es gibt zwei TDD-Ebenen

Akzeptanz-TDD (ATDD): Mit ATDD schreiben Sie einen einzelnen Akzeptanztest. Dieser Test erfüllt die Anforderungen der Spezifikation oder das Verhalten des Systems. Schreiben Sie danach gerade genug Produktions- / Funktionscode, um diesen Abnahmetest zu erfüllen. Der Abnahmetest konzentriert sich auf das Gesamtverhalten des Systems. ATDD wurde auch als Behavioral Driven Development (BDD) bezeichnet.
Entwickler-TDD: Mit Entwickler-TDD schreiben Sie einen einzelnen Entwicklertest, dh einen Komponententest, 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 TDD bezeichnet.
Das Hauptziel von ATDD und TDD besteht darin, detaillierte, ausführbare Anforderungen für Ihre Lösung auf Just-in-Time-Basis (JIT) festzulegen. 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 kann keine größeren Probleme wie das Gesamtdesign, die Verwendung des Systems oder die Benutzeroberfläche durchdenken. AMDD behebt die Probleme der agilen Skalierung, die TDD nicht hat.

Somit wird AMDD für größere Probleme verwendet.

Der Lebenszyklus von AMDD.

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

In der obigen Abbildung repräsentiert jedes Feld eine Entwicklungsaktivität.

Envisioning ist einer der TDD-Prozesse zur Vorhersage / Vorstellung von Tests, die in der ersten Projektwoche durchgeführt werden. Das Hauptziel der Vorstellung ist es, den Umfang des Systems und die Architektur des Systems zu identifizieren. Für eine erfolgreiche Vorstellung werden allgemeine Anforderungen und Architekturmodelle erstellt.

Es ist der Prozess, bei dem keine detaillierte Spezifikation der Software / des Systems vorgenommen wird, sondern die Anforderungen der Software / des Systems untersucht werden, die die Gesamtstrategie des Projekts definieren.

Iteration 0: Vorstellung

Es gibt zwei Hauptunteraktivierungen.

Erste Anforderungen ins Auge fassen.
Es kann mehrere Tage dauern, bis die allgemeinen Anforderungen und der Umfang des Systems ermittelt sind. Das Hauptaugenmerk liegt auf der Untersuchung des Nutzungsmodells, des anfänglichen Domänenmodells und des Benutzeroberflächenmodells (UI).
Anfängliche architektonische Vorstellung.
Es dauert auch mehrere Tage, um die Architektur des Systems zu identifizieren. Hier können Sie technische Anweisungen für das Projekt festlegen. Das Hauptaugenmerk liegt auf der Untersuchung von Technologiediagrammen, Benutzeroberflächenabläufen, Domänenmodellen und Änderungsfällen.

Iterationsmodellierung:
Hier muss das Team die Arbeit planen, die für jede Iteration ausgeführt wird.

Für jede Iteration wird ein agiler Prozess verwendet, dh während jeder Iteration wird ein neues Arbeitselement mit Priorität hinzugefügt.
Erste Arbeiten mit höherer Priorität werden berücksichtigt. Hinzugefügte Arbeitselemente können jederzeit neu priorisiert oder vom Objektstapel entfernt werden.
Das Team bespricht, wie die einzelnen Anforderungen umgesetzt werden sollen. Zu diesem Zweck wird die Modellierung verwendet.
Die Modellanalyse und das Modellierungsdesign werden für jede Anforderung durchgeführt, die für diese Iteration implementiert werden soll.

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

An dieser Modellierungssitzung ist ein Team von 2/3 Mitgliedern beteiligt, die Probleme auf Papier oder Whiteboard diskutieren.
Ein Teammitglied wird ein anderes bitten, mit ihnen zu modellieren. Diese Modellierungssitzung dauert ungefähr 5 bis 10 Minuten. Wo sich Teammitglieder versammeln, um Whiteboard / Papier zu teilen.
Sie untersuchen Probleme, bis sie die Hauptursache des Problems nicht mehr finden. Pünktlich, wenn ein Teammitglied das Problem identifiziert, das es lösen möchte, wird es schnell Hilfe von anderen Teammitgliedern in Anspruch nehmen.
Andere Gruppenmitglieder untersuchen dann das Problem und dann machen alle weiter wie zuvor. Es wird auch als Stand-up-Modellierung oder Kunden-QS-Sitzung bezeichnet.

Test Driven Development (TDD).

Es fördert die Bestätigungstests Ihres Anwendungscodes und die detaillierte Spezifikation.
Sowohl der Abnahmetest (detaillierte Anforderungen) als auch die Entwicklertests (Komponententest) sind Eingaben für TDD.
TDD macht den Code einfacher und klarer. Dadurch kann der Entwickler weniger Dokumentation verwalten.

Bewertungen.

Dies ist optional. Es umfasst Code-Inspektionen und Modellüberprüfungen.
Dies kann für jede Iteration oder für das gesamte Projekt erfolgen.
Dies ist eine gute Option, um Feedback für das Projekt zu geben.

Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)

TDD	AMDD
TDD verkürzt die Programmierrückkopplungsschleife	AMDD verkürzt die Modellierungs-Rückkopplungsschleife.
TDD ist eine detaillierte Spezifikation	AMDD funktioniert 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äftsanalysten, Stakeholdern und Datenfachleuten.
TDD nicht visuell orientiert	AMDD visuell orientiert
TDD hat einen begrenzten Umfang für Software-Arbeiten	AMDD hat ein breites Spektrum, einschließlich der Interessengruppen. Es geht darum, auf ein gemeinsames Verständnis hinzuarbeiten
Beide unterstützen die evolutionäre Entwicklung	----------------------------------------

Beispiel für TDD

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

Voraussetzung für die Annahme des Passworts:

Das Passwort sollte zwischen 5 und 10 Zeichen lang sein.

Zuerst schreiben wir den Code, der alle oben genannten Anforderungen erfüllt.

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

Wir werden über der Klasse TestPassword () laufen;

Die Ausgabe wird wie unten gezeigt PASSIERT.

Ausgabe :

Szenario 2 : Hier sehen wir in der Methode TestPasswordLength (), dass keine Instanz der Klasse PasswordValidator erstellt werden muss. Instanz bedeutet, ein Klassenobjekt zu erstellen, 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 die isValid () -Methode direkt über PasswordValidator aufrufen . IsValid ("Abc123") . (Siehe Bild unten)

Also Refactor (Code ändern) wie folgt:

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 die nicht statische Methode isValid ().

Daher müssen wir diese Methode ändern, indem wir "statisches" Wort vor Boolean als öffentlichen statischen Booleschen Wert isValid (String password) hinzufügen. Refactoring Class PasswordValidator (), um den obigen Fehler zu entfernen und den Test zu bestehen.

Ausgabe:

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

Vorteile von TDD

Frühzeitige Fehlerbenachrichtigung.
Entwickler testen ihren Code, aber in der Datenbankwelt besteht dies häufig aus manuellen Tests oder einmaligen Skripten. Mit TDD erstellen Sie im Laufe der Zeit eine Reihe automatisierter Tests, die Sie und jeder andere Entwickler nach Belieben erneut ausführen können.
Besser gestalteter, sauberer 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 von kleinerem Code mit einer einzigen Verantwortung anstelle von monolithischen Prozeduren mit mehreren Verantwortlichkeiten. Dies erleichtert das Verständnis des Codes.
- TDD zwingt außerdem, nur Produktionscode zu schreiben, um Tests basierend auf den Benutzeranforderungen zu bestehen.
Vertrauen zum Refactor
- Wenn Sie den Code umgestalten, kann es zu Unterbrechungen des Codes kommen. Mit einer Reihe automatisierter Tests können Sie diese Unterbrechungen vor der Veröffentlichung beheben. Die richtige Warnung wird ausgegeben, wenn bei Verwendung automatisierter Tests Unterbrechungen festgestellt werden.
- Die Verwendung von TDD sollte zu schnellerem, erweiterbarem Code mit weniger Fehlern führen, die mit minimalen Risiken aktualisiert werden können.
Gut für Teamarbeit
Wenn kein Teammitglied vorhanden ist, können andere Teammitglieder den Code problemlos abrufen und bearbeiten. 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, dauert das Debuggen und Entwickeln neuer Funktionen viel weniger Zeit. Sie schreiben saubereren, weniger komplizierten Code.

Zusammenfassung:

TDD steht für testgetriebene Entwicklung. Es ist ein Prozess zum Ändern des Codes, um einen zuvor entworfenen Test zu bestehen.
Der Schwerpunkt liegt eher auf dem Produktionscode als auf dem Testfalldesign.
Testgetriebene Entwicklung ist ein Prozess zum Ändern des Codes, um einen zuvor entworfenen Test zu bestehen.
In der Softwareentwicklung wird es manchmal als "Test First Development" bezeichnet.
TDD umfasst das Refactoring eines Codes, dh das Ändern / Hinzufügen einer gewissen Menge an Code zum vorhandenen Code, ohne das Verhalten des Codes zu beeinflussen.
Bei Verwendung von TDD wird der Code klarer und einfacher zu verstehen.

Dieser Artikel wurde von Kanchan Kulkarni verfasst