In „Was sind TDD, BDD und ATDD und was sind die Unterschiede?“ (Teil 1)“ diskutiert die Konzepte von TDD, BDD und ATDD. Obwohl TDD, BDD und ATDD allesamt Testmethoden sind, die in der Softwareentwicklung verwendet werden, unterscheiden sie sich in Ansatz und Schwerpunkt.
Die Hauptunterschiede zwischen TDD, BDD und ATDD sind Fokus, Abstraktionsebene und Zusammenarbeit.
1. Konzentrieren Sie sich
TDD konzentriert sich darauf, Code zu testen und sicherzustellen, dass er den Anforderungen entspricht. BDD konzentriert sich auf das Verhalten von Software und stellt sicher, dass sie den Geschäftsanforderungen entspricht. ATDD konzentriert sich auf Akzeptanzkriterien und stellt sicher, dass die Software den Geschäftsanforderungen entspricht.
2. Abstraktionsebene
TDD konzentriert sich auf die Codeebene und verwendet Unit-Tests, um die Funktionalität des Codes zu überprüfen. BDD konzentriert sich auf die funktionale Ebene und nutzt Szenarien, um das gewünschte Verhalten zu beschreiben. ATDD konzentriert sich auf Akzeptanzkriterien und verwendet Akzeptanztests, um zu überprüfen, ob die Software die Anforderungen erfüllt.
3. Zusammenarbeit
TDD ist in erster Linie ein entwicklerzentrierter Prozess, der das Schreiben von Tests und Code umfasst. BDD und ATDD erfordern die Zusammenarbeit zwischen Entwicklern, Testern und Stakeholdern, um sicherzustellen, dass die Software den Geschäftsanforderungen entspricht.
Obwohl diese drei Ansätze einige Gemeinsamkeiten aufweisen, unterscheiden sie sich in Ansatz, Umfang und Zweck .
1 Geltungsbereich
TDD konzentriert sich auf die Entwicklung von Code und Tests zur Überprüfung seines Verhaltens. Der Prozess beginnt mit dem Schreiben eines fehlgeschlagenen Testfalls, dem anschließenden Schreiben der zum Bestehen des Tests erforderlichen Mindestmenge an Code und dem anschließenden Refactoring des Codes. TDD stellt sicher, dass der Code gründlich getestet wird und die Anforderungen erfüllt, bevor er veröffentlicht wird.
BDD erweitert den Umfang von TDD um das Verhalten des gesamten Systems. BDD konzentriert sich auf das Verhalten des Systems, nicht auf seine Implementierungsdetails. BDD-Szenarien werden in einem speziellen Format namens Gherkin geschrieben, das die Syntax „Given When Then“ verwendet, um die Voraussetzungen, Aktionen und erwarteten Konsequenzen des Systemverhaltens zu beschreiben. Diese Szenarien dienen als Akzeptanzkriterien für das System und stellen sicher, dass das Team die richtigen Dinge baut und dass das System die Bedürfnisse seiner Benutzer erfüllt.
ATDD konzentriert sich auf die Akzeptanzkriterien des Systems. Das Team arbeitet zusammen, um Akzeptanzkriterien für das System in Form automatisierter Tests zu definieren. Tests werden in einem bestimmten Format geschrieben, das allen Beteiligten zugänglich ist, und verwenden die Syntax „Given When Then“, um das erwartete Verhalten des Systems zu beschreiben. ATDD-Tests sind das Akzeptanzkriterium für das System und stellen sicher, dass das Team das Richtige baut und dass das System den Benutzeranforderungen entspricht.
2. Terminologie
TDD verwendet ein Vokabular an Begriffen und konzentriert sich auf das Verhalten des Codes. TDD-Tests werden von Entwicklern geschrieben, um sicherzustellen, dass sich der Code wie erwartet verhält. TDD-Tests werden normalerweise in derselben Programmiersprache geschrieben wie der Testcode.
BDD verwendet ein unternehmensfreundliches Vokabular und konzentriert sich auf das Verhalten des Systems. BDD-Szenarien werden in einem speziellen Format namens Gherkin geschrieben, das die Syntax „Given When Then“ verwendet, um die Voraussetzungen, Aktionen und erwarteten Konsequenzen des Systemverhaltens zu beschreiben. BDD-Szenarien werden in der Regel von Geschäftsanalysten oder Produktbesitzern geschrieben, die über ein tiefes Verständnis der Benutzerbedürfnisse und -anforderungen verfügen.
ATDD verwendet ein unternehmensfreundliches Vokabular und konzentriert sich auf die Akzeptanzkriterien des Systems. ATDD-Tests werden in einem spezifischen Format geschrieben, das allen Beteiligten zugänglich ist, und verwenden die Syntax „Given When Then“, um das erwartete Verhalten des Systems zu beschreiben. ATDD-Tests werden in der Regel von Geschäftsanalysten oder Produktbesitzern geschrieben, die über ein tiefes Verständnis der Benutzerbedürfnisse und -anforderungen verfügen.
3. Zweck
Der Zweck von TDD besteht darin, sicherzustellen, dass Code gründlich getestet wird und die Anforderungen erfüllt, bevor er veröffentlicht wird. TDD-Tests dienen als Spezifikation für den Code und helfen Entwicklern, Fehler und Mängel frühzeitig im Entwicklungszyklus zu finden.
Der Zweck von BDD besteht darin, sicherzustellen, dass das Team das Richtige baut und dass das System die Bedürfnisse seiner Benutzer erfüllt. BDD-Szenarien dienen als Akzeptanzkriterien für das System und stellen sicher, dass das Team die richtigen Dinge baut und dass das System den Benutzeranforderungen entspricht.
Der Zweck von ATDD besteht darin, sicherzustellen, dass das Team das Richtige baut und dass das System den Bedürfnissen der Benutzer entspricht. ATDD-Tests sind das Akzeptanzkriterium für das System und stellen sicher, dass das Team das Richtige baut und dass das System den Benutzeranforderungen entspricht. ATDD-Tests steuern auch den Entwicklungsprozess und stellen sicher, dass der Code vor der Veröffentlichung getestet wird und die Akzeptanzkriterien erfüllt.
4. Methode
TDD verfolgt bei der Softwareentwicklung einen Top-Down-Ansatz. Es beginnt mit dem Schreiben eines Testfalls und schreibt dann Code, der diesen Test besteht. Wiederholen Sie diesen Zyklus, bis alle Anforderungen erfüllt sind. TDD ermutigt Entwickler, testbaren und wartbaren Code zu schreiben, was zu qualitativ hochwertigeren Produkten führt.
BDD verfolgt einen verhaltensgesteuerten Ansatz bei der Softwareentwicklung. Zunächst wird das gewünschte Verhalten des Systems in Form von Szenarien definiert, die beschreiben, wie sich das System unter verschiedenen Umständen verhält. Diese Szenarien sind in einem speziellen Format namens Gherkin geschrieben, das die Syntax „Given When Then“ verwendet, um die Voraussetzungen, Aktionen und erwarteten Konsequenzen des Systemverhaltens zu beschreiben. BDD-Szenarien werden in der Regel von Geschäftsanalysten oder Produktbesitzern geschrieben, die über ein tiefes Verständnis der Benutzerbedürfnisse und -anforderungen verfügen.
ATDD verfolgt einen ähnlichen Ansatz wie BDD, konzentriert sich jedoch auf die Akzeptanzkriterien des Systems. Das Team arbeitet zusammen, um Akzeptanzkriterien für das System in Form automatisierter Tests zu definieren. Tests werden in einem bestimmten Format geschrieben, das allen Beteiligten zugänglich ist, und verwenden die Syntax „Given When Then“, um das erwartete Verhalten des Systems zu beschreiben. ATDD-Tests werden in der Regel von Geschäftsanalysten oder Produktbesitzern geschrieben, die über ein tiefes Verständnis der Benutzerbedürfnisse und -anforderungen verfügen.
Zusammenfassen
Testgetriebene Entwicklung (TDD), Verhaltensgetriebene Entwicklung (BDD) und Akzeptanztestgetriebene Entwicklung sind in den letzten Jahren allesamt beliebte Softwareentwicklungsmethoden. Obwohl alle drei Ansätze darauf abzielen, die Softwarequalität zu verbessern und Fehler zu reduzieren, unterscheiden sie sich in Ansatz, Umfang und Zweck.