Test-Driven Development (TDD) eignet sich insbesondere für Komponententests. Die Entwicklung von Features beginnt dabei mit den Tests und ergänzt dann die notwendigen Implementierungen.
Wer Chaos automatisiert, erhält automatisiertes Chaos. Damit es nicht so weit kommt, gilt es, den Einsatz der Tools und Pipelines im Kontext der Projekte zu betrachten. Wie entstehen aus Anforderungen gute und automatisierte Testfälle?
Test-Driven Development (TDD) eignet sich insbesondere für Komponententests. Die Entwicklung von Features beginnt dabei mit den Tests und ergänzt dann die notwendigen Implementierungen.
Behaviour-Driven Development (BDD) ist ein agiler Softwareentwicklungsansatz, in dem es sich um die Kollaboration im Team durch ausführbare Spezifikationen dreht.
Test-Driven Development (TDD) ist eine Methode, die sich insbesondere für die Komponententests eignet. Anstatt mit der Implementierung einer Lösung zu beginnen und diese anschließend zu testen, wird dieser Ansatz umgedreht:
Dieser Ansatz kann in der Realität sehr gut funktionieren, wenn die Entwickler bei der Implementierung der Tests Unterstützung durch testerfahrene Mitarbeiter bekommen. Andernfalls besteht das Risiko, dass nur „gute“ Testfälle erstellt werden und Randfälle nicht betrachtet wurden.
Sie benötigen Test-Know-How in Ihrem Projekt, um TDD einzuführen oder umzusetzen? Dann zögern Sie nicht und kontaktieren uns!
Im Kern ist Behaviour-Driven Development (BDD) ein agiler Softwareentwicklungsansatz, der aus dem Test-Driven-Development-Ansatz heraus entstanden ist, diesen jedoch um einen wichtigen Aspekt erweitert. Dabei dreht sich alles um die Kollaboration im Team und um die Anleitung der Entwicklungsarbeit durch ausführbare und leicht verständliche Spezifikationen.
Einfacher ausgedrückt, steht bei BDD am Anfang eines Entwicklungszyklus immer erst einmal die gemeinsame Analyse von Anforderungen im gesamten Team. Um ein kollektives Verständnis dafür aufzubauen, welches Feature als nächstes genau entwickelt werden soll, wird sich der Sammlung und Formulierung kurzer, fokussierter Szenarien aus Anwendersicht gewidmet. So werden nach und nach alle Kriterien einer Feature-Anforderung anhand verständlicher Anwendungsbeispiele beschrieben und dies in einem sogenannten "Feature File" in formalisierter Syntax festgehalten.
Das kann dann in einem vereinfachten Beispiel so aussehen:
Feature: Delete User Account
As a customer of the onlineshop
I want to be able to delete my user account
in order to have full control over my data
Background:
Given "Larissa" is a registered customer
And "Larissa" is logged in
Scenario: Account deletion successful
When "Larissa" requests an account deletion
And "Larissa" confirms the deletion
Then "Larissa" should be logged out automatically
And account data for "Larissa" should be deleted
Scenario: Account deletion canceled
When "Larissa" requests an account deletion
But "Larissa" does not confirm the deletion
Then "Larissa" should still be logged in
And account data for "Larissa" should still exist
Der Vorteil liegt hier darin, dass die Feature-Spezifikationen in einer nicht-technischen, natürlichen Sprache beschrieben sind, um nicht nur für Entwickler:innen verständlich zu sein, sondern für das gesamte Team und Stakeholder.
Schließlich wird Testcode für jeden Schritt geschrieben, um das Feature-File für die Ausführung vorzubereiten. Entwickler haben dann ein klar beschriebenes Dokument an der Hand, das sie während der Entwicklungsphase beliebig oft ausführen können, um zu prüfen, ob der entwickelte Applikationscode die Anforderungen erfüllt.
Neben der reinen Ausführung der Tests über Tools sind zwei Themenbereiche zu beachten:
So wäre es ärgerlich, wenn im Rahmen der Tests eines Webshops eine reale Bestellung in den Versand ausgelöst würde.
Gern stehen wir Ihnen mit Know-how, konkreten Unterstützungsleistungen und zugehörigen Lizenz- und Supportangeboten zur Verfügung.