© Excellent backgrounds/Shutterstock.com
Java Magazin
TDD und BDD im Praxischeck

Testfalle

Testgetriebene Softwareentwicklung ist weitbekannt, aber noch immer nicht weit verbreitet. Und das, obwohl mit den heutigen Werkzeugen das Entwickeln mit automatisierten Tests kaum einen Mehraufwand bedeutet. Dieser Workshop zeigt, wie leicht sich Test-driven Development (TDD) und Behavior-driven Development (BDD) in den Entwicklungsalltag integrieren.

Marco Schulz


Reflektiert man einmal das persönliche Vorgehen bei Implementierungsarbeiten, muss man allzu oft eingestehen, dass man Funktionen gegen das Graphical User Interface (GUI) entwickelt. Diese Strategie führt auch zu einem Ziel. Mit fortschreitendem Entwicklungsgrad werden die Funktionstests allerdings sehr schnell mühselig, die stets zu knappe Zeit wird noch knapper. Das Risiko möglicher Fehler wächst unter dem entstandenen Zeitdruck überproportional, und im Allgemeinen verlangsamt sich die Produktivität. Die Idee, gegen Testfälle zu entwickeln, wurde von verschiedenen Autoren unter dem Stichwort „testgetriebene Entwicklung“ in diversen Büchern ausführlich besprochen. Aber was hindert uns daran, diesen Ideen zu folgen und sie zu einem Teil unseres Arbeitsflusses zu machen? Eine naheliegende Antwort ist sicherlich Projektstress, der nicht genügend Freiräume schafft, neue Ideen weiter zu verfolgen. Oftmals sehen sich Entwickler durch die strengen Vorgaben innerhalb der Firmen demotiviert, in ihrem Verantwortungsbereich eigenständig an Verbesserungen zu arbeiten. Vermutlich trägt zur Nichtumsetzung dieser Paradigmen auch bei, dass sie zu großen Teilen an umfangreiche Planungskonzepte gebunden sind. Das widerspricht der Natur eines Entwicklers – der eher eine Frau oder ein Mann der Tat ist – fundamental. Daher wollen wir uns dem Thema Softwaretests ein wenig pragmatischer nähern und dem agilen Gedanken folgen.

Zunächst werfen wir die Idee über Bord, dass erst Testfälle entwickelt werden und dann gegen diese Testfälle implementiert werden soll. Wir betrachten stattdessen die Welt von ihrer unverblümt realen Seite. Eine Anforderung wurde so weit spezifiziert, dass sie von der Projektleitung genehmigt wurde und nun umzusetzen ist. Um nicht allzu abstrakt zu bleiben, bedienen wir uns eines einfachen, aber hinreichend komplexen Beispiels, nämlich eines simplen E-Mail-Clients. Dieser soll der Gesamtanwendung ermöglichen, E-Mails zu verschicken. Es wurde festgelegt, dass zur Realisierung die externe Bibliothek Java Mail API verwendet werden soll. Grundlage der Codebeispiele ist das Open-Source-Projekt TP-CORE, das von GitHub [1] heruntergeladen werden kann.

Planspiele

Mit den bereits vorhandenen Informationen können wir auch schon beginnen, agil und testgetrieben zu entwickeln. Auf einem Blatt Papier lässt sich rasch notieren, wie die Grundfunktionen eines einfachen E-Mail-Clients aussehen könnten:

Verbinden mit einem SMPT-Server, um Mails zu verschickenErstellen (Kompon...

Java Magazin
TDD und BDD im Praxischeck

Testfalle

Testgetriebene Softwareentwicklung ist weitbekannt, aber noch immer nicht weit verbreitet. Und das, obwohl mit den heutigen Werkzeugen das Entwickeln mit automatisierten Tests kaum einen Mehraufwand bedeutet. Dieser Workshop zeigt, wie leicht sich Test-driven Development (TDD) und Behavior-driven Development (BDD) in den Entwicklungsalltag integrieren.

Marco Schulz


Reflektiert man einmal das persönliche Vorgehen bei Implementierungsarbeiten, muss man allzu oft eingestehen, dass man Funktionen gegen das Graphical User Interface (GUI) entwickelt. Diese Strategie führt auch zu einem Ziel. Mit fortschreitendem Entwicklungsgrad werden die Funktionstests allerdings sehr schnell mühselig, die stets zu knappe Zeit wird noch knapper. Das Risiko möglicher Fehler wächst unter dem entstandenen Zeitdruck überproportional, und im Allgemeinen verlangsamt sich die Produktivität. Die Idee, gegen Testfälle zu entwickeln, wurde von verschiedenen Autoren unter dem Stichwort „testgetriebene Entwicklung“ in diversen Büchern ausführlich besprochen. Aber was hindert uns daran, diesen Ideen zu folgen und sie zu einem Teil unseres Arbeitsflusses zu machen? Eine naheliegende Antwort ist sicherlich Projektstress, der nicht genügend Freiräume schafft, neue Ideen weiter zu verfolgen. Oftmals sehen sich Entwickler durch die strengen Vorgaben innerhalb der Firmen demotiviert, in ihrem Verantwortungsbereich eigenständig an Verbesserungen zu arbeiten. Vermutlich trägt zur Nichtumsetzung dieser Paradigmen auch bei, dass sie zu großen Teilen an umfangreiche Planungskonzepte gebunden sind. Das widerspricht der Natur eines Entwicklers – der eher eine Frau oder ein Mann der Tat ist – fundamental. Daher wollen wir uns dem Thema Softwaretests ein wenig pragmatischer nähern und dem agilen Gedanken folgen.

Zunächst werfen wir die Idee über Bord, dass erst Testfälle entwickelt werden und dann gegen diese Testfälle implementiert werden soll. Wir betrachten stattdessen die Welt von ihrer unverblümt realen Seite. Eine Anforderung wurde so weit spezifiziert, dass sie von der Projektleitung genehmigt wurde und nun umzusetzen ist. Um nicht allzu abstrakt zu bleiben, bedienen wir uns eines einfachen, aber hinreichend komplexen Beispiels, nämlich eines simplen E-Mail-Clients. Dieser soll der Gesamtanwendung ermöglichen, E-Mails zu verschicken. Es wurde festgelegt, dass zur Realisierung die externe Bibliothek Java Mail API verwendet werden soll. Grundlage der Codebeispiele ist das Open-Source-Projekt TP-CORE, das von GitHub [1] heruntergeladen werden kann.

Planspiele

Mit den bereits vorhandenen Informationen können wir auch schon beginnen, agil und testgetrieben zu entwickeln. Auf einem Blatt Papier lässt sich rasch notieren, wie die Grundfunktionen eines einfachen E-Mail-Clients aussehen könnten:

Verbinden mit einem SMPT-Server, um Mails zu verschickenErstellen (Kompon...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang