Behaviour-Driven Development

2. Juni 2008

Johannes Link

Heidelberg

Mein eigener Chef

Mein eigener Chef (Extremer) Softwareentwickler

Mein eigener Chef (Extremer) Softwareentwickler (Agiler) Coach

Mein eigener Chef (Extremer) Softwareentwickler (Agiler) Coach Testgetrieben

johanneslink.net

Behaviour Driven Development

Behaviour Driven Development Was. Warum. Wie.

Testgetriebene Entwicklung

Test / Code / Refactor Tests Fail Tests OK

Test / Code / Refactor 1) Test hinzufügen Tests Fail Tests OK

Test / Code / Refactor 1) Test hinzufügen Tests Fail Tests OK 2) Test erfüllen

Test / Code / Refactor 1) Test hinzufügen 3) Code Tests Fail Tests OK vereinfachen 2) Test erfüllen

Warum TDD?

Regressionstests Warum TDD?

Regressionstests Weniger Bugs Warum TDD?

Regressionstests Inkrementelles Vorgehen Weniger Bugs Warum TDD?

Regressionstests Inkrementelles Vorgehen Designfokus Weniger Bugs Warum TDD?

Regressionstests Inkrementelles Vorgehen Entkopplung Designfokus Weniger Bugs Warum TDD?

Regressionstests Inkrementelles Vorgehen Entkopplung Designfokus Schnittstellen Weniger Bugs Warum TDD?

Regressionstests Inkrementelles Vorgehen Entkopplung Designfokus Schnittstellen Weniger Bugs Warum TDD? Ausführbare Speziﬁkation?

Regressionstests Inkrementelles Vorgehen Entkopplung Designfokus Schnittstellen Weniger Bugs Warum TDD? Ausführbare Speziﬁkation? Technische Dokumentation?

Typische TDD-Fragen

Wo fange ich an? Typische TDD-Fragen

Wo fange ich an? Typische TDD-Fragen Wo höre ich auf?

Wo fange ich an? Wie nenne ich die Testklasse? Typische TDD-Fragen Wo höre ich auf?

Wo fange ich an? Wie nenne ich die Testklasse? Typische TDD-Fragen Wie nenne ich die Testmethode? Wo höre ich auf?

Wo fange ich an? Wie nenne ich die Testklasse? Wie viele Assertions pro Testfall? Typische TDD-Fragen Wie nenne ich die Testmethode? Wo höre ich auf?

Wo fange ich an? Welche Objekte erzeuge ich im Setup? Wie nenne ich die Testklasse? Wie viele Assertions pro Testfall? Typische TDD-Fragen Wie nenne ich die Testmethode? Wo höre ich auf?

Wo fange ich an? Welche Objekte erzeuge ich im Setup? Wie nenne ich die Testklasse? Wie viele Assertions pro Testfall? Typische TDD-Fragen Wie nenne ich die Benötigt jede Klasse/ Testmethode? Methode eine eigene Test-Klasse/-Methode? Wo höre ich auf?

Wo fange ich an? Welche Objekte erzeuge ich im Setup? Wie nenne ich die Testklasse? Wie viele Assertions pro Testfall? Typische TDD-Fragen Wie nenne ich die Benötigt jede Klasse/ Testmethode? Methode eine eigene Test-Klasse/-Methode? Wie gruppiere und organisiere ich meine Wo höre ich auf? Testfälle?

Schwammige Regeln

Heuristiken

Beispiel...

public class KontoTest { @Test public void neuesKonto() { Konto konto = new Konto(quot;Johannesquot;); assertEquals(quot;Johannesquot;, konto.getInhaber()); assertEquals(0, konto.getSaldo()); } }

public class KontoTest... private Konto konto; @Before public void init() { konto = new Konto(quot;Johannesquot;); } @Test public void neuesKonto() { ... } @Test public void einzahlung() { konto.zahleEin(100); assertEquals(100, konto.getSaldo()); konto.zahleEin(99); assertEquals(199, konto.getSaldo()); }

public class KontoTest... @Test public void einzahlung() { konto.zahleEin(100); assertEquals(100, konto.getSaldo()); konto.zahleEin(99); assertEquals(199, konto.getSaldo()); } @Test(expected = IllegalArgumentException.class) public void negativeEinzahlungNichtErlaubt() { konto.zahleEin(-1); }

public class KontoTest... @Test public void einzahlung() { konto.zahleEin(100); assertEquals(100, konto.getSaldo()); konto.zahleEin(99); assertEquals(199, konto.getSaldo()); } @Test(expected = IllegalArgumentException.class) public void negativeEinzahlungNichtErlaubt() { konto.zahleEin(100); konto.zahleEin(-1); }

public class NeuesKontoTest... @Test public void inhaber()... @Test public void anfangssaldo()... @Test public void ersteEinzahlung()... public class KontoMitPositivemSaldoTest... private static final int ANFANGSSALDO = 100; @Test public void einzahlung() { konto.zahleEin(99); assertEquals(99 + ANFANGSSALDO, konto.getSaldo()); } @Test(expected = IllegalArgumentException.class) public void negativeEinzahlungNichtErlaubt() { konto.zahleEin(-1); }

Gewünschtes Kontoverhalten • Ein neues Konto • soll den Namen seines Inhabers mitteilen können • soll einen Saldo von 0 EUR haben • soll einen positiven Anfangssaldo eingezahlt bekommen können • Ein Konto mit positivem Saldo • soll den Saldo bei Einzahlungen entsprechenden vergrößern • soll bei negativen Einzahlungen eine IllegalArgumentException auslösen

public class EinNeuesKonto... @Test public void sollInhaberLiefern()... @Test public void sollAnfangssaldoNullHaben()... @Test public void sollErsteEinzahlungErlauben()... public class EinKontoMitPositivemSaldo... @Test public void sollBeiPositiverEinzahlungSaldoErhöhen() { konto.zahleEin(99); assertThat(konto.getSaldo(), is(ANFANGSSALDO + 99)); //assertEquals(99 + ANFANGSSALDO, konto.getSaldo()); } @Test public void sollBeiNegativerEinzahlung- IllegalArgument-ExceptionWerfen()...

Dan North

http://dannorth.net/introducing-bdd

BDD: Vom Test zum Verhalten

Die Sprache beeinﬂusst unser Verhalten

Die Sprache des Testen

Die Sprache des Testen Testfälle, Testen, Beweisen, Sicherstellen, Programmeinheit, Korrektheit, Vorbedingungen

Die Sprache des Testen Testfälle, Testen, Beweisen, Sicherstellen, Programmeinheit, Korrektheit, Vorbedingungen Wir versuchen mit Testfällen zu beweisen, dass eine Programmeinheit unter bestimmten Vorbedingungen korrekt arbeitet

Die Sprache des Testen Testfälle, Testen, Beweisen, Sicherstellen, Programmeinheit, Korrektheit, Vorbedingungen Wir versuchen mit Testfällen zu beweisen, dass eine Programmeinheit unter bestimmten Vorbedingungen korrekt arbeitet Set Up - Stimulate - Assert

Die Sprache des BDD

Die Sprache des BDD User Stories, Szenario, Speziﬁkation,Verhalten, Kontext

Die Sprache des BDD User Stories, Szenario, Speziﬁkation,Verhalten, Kontext Wir speziﬁzieren in Szenarien, wie sich Dinge in einem bestimmten Kontext verhalten sollen, um eine User Story zu erfüllen

Die Sprache des BDD User Stories, Szenario, Speziﬁkation,Verhalten, Kontext Wir speziﬁzieren in Szenarien, wie sich Dinge in einem bestimmten Kontext verhalten sollen, um eine User Story zu erfüllen Given - When - Then

Wie funktioniert meine Klasse?

Wie funktioniert meine Klasse? Was soll mein Programm tun?

JBehave Instinct JDave Werkzeuge GSpec easyb RSpec NSpec

Instinct http://code.google.com/p/instinct/

@RunWith(InstinctRunner.class) public class EinKontoMitPositivemSaldo { private static final int ANFANGSSALDO = 42; @Subject Konto konto; @BeforeSpecification void initialisiere() { konto = new Konto(quot;Irgendwerquot;); konto.zahleEin(ANFANGSSALDO); } @Specification(expectedException = IllegalArgumentException.class) void sollBeiNegativerEinzahlungIllegalArgumentExceptionWerfen() { konto.zahleEin(-1); } @Specification void sollBeiPositiverEinzahlungenSaldoErhöhen() { konto.zahleEin(1); expect.that(konto.getSaldo()).isEqualTo(ANFANGSSALDO + 1); konto.zahleEin(100); expect.that(konto.getSaldo()).isEqualTo(ANFANGSSALDO + 101); } }

GSpec http://groovy.codehaus.org/ Using+GSpec+with+Groovy

def ein = new GSpecBuilderRunner() ein.context('Ein neues Konto') { def INHABER = quot;Johannesquot; initially { ein.neuesKonto = new Konto(INHABER) } specify('soll den Inhaber als Property liefern') { ein.neuesKonto.inhaber.should_equal INHABER } specify('soll 0 EUR Anfangssaldo haben') {..} specify('soll positive Einzahlungen bekommen können') {..} } ein.context('Ein Konto mit positivem Saldo') { specify('soll bei positiver Einzahlungen den Saldo erhöhen') {..} specify('''soll bei negativer Einzahlungen IllegalArgumentException werfen''') {..} }

def ein = new GSpecBuilderRunner() ein.context('Ein neues Konto') { def INHABER = quot;Johannesquot; initially { ein.neuesKonto = new Konto(INHABER) } specify('soll den Inhaber als Property liefern') { ein.neuesKonto.inhaber.should_equal INHABER } specify('soll 0 EUR Anfangssaldo haben') {..} Ein neues Konto soll den Inhaber als Property liefern specify('soll positive Einzahlungen bekommen können') {..} } Ein neues Konto soll 0 EUR Anfangssaldo haben ein.context('Ein Konto mit positivem Saldo') { Ein neues Konto specify('soll bei positiver Einzahlungen den Saldo erhöhen') {..} soll positive Einzahlungen bekommen können Ein Konto mit positivem Saldo specify('''soll bei negativer Einzahlungen soll bei positiver Einzahlungen den Saldo erhöhen IllegalArgumentException werfen''') {..} Ein Konto mit positivem Saldo } soll bei negativer Einzahlungen IllegalArgumentException werfen

easyb http://www.easyb.org/

scenario quot;Konto mit ANFANGSSALDOquot;, { def ANFANGSSALDO = 42 def BETRAG = 101 given quot;ein Konto mit SALDOquot;, { konto = new Konto(quot;irgendwerquot;) konto.zahleEin(ANFANGSSALDO) } when quot;ein BETRAG eingezahlt wirdquot;, { konto.zahleEin(BETRAG) } then quot;der Saldo entspricht ANFANGSSALDO + BETRAGquot;, { konto.getSaldo().shouldBe ANFANGSSALDO + BETRAG } } scenario quot;Negative Einzahlungquot;, { given quot;ein Kontoquot;, {...} when quot;ein negativer Betrag eingezahlt wirdquot;, { negativeEinzahlung = { konto.zahleEin(-1) } } then quot;eine IllegalArgumentException soll geworfen werdenquot;, { ensureThrows(IllegalArgumentException) { negativeEinzahlung() } } }

scenario quot;Konto mit ANFANGSSALDOquot;, { def ANFANGSSALDO = 42 def BETRAG = 101 given quot;ein Konto mit SALDOquot;, {einzelnes konto Story: konto = new Konto(quot;irgendwerquot;) scenario Neues Konto konto.zahleEin(ANFANGSSALDO) given ein neues Konto } then der Inhaber ist als Property verfŸgbar when quot;ein BETRAG eingezahltthen der { wirdquot;, Anfangssaldo ist 0 konto.zahleEin(BETRAG) } scenario Einfache Einzahlung then quot;der Saldo entspricht given ein leeres BETRAGquot;, { ANFANGSSALDO + Konto konto.getSaldo().shouldBe ANFANGSSALDOeingezahlt wird when ein BETRAG + BETRAG } then der Saldo entspricht dem BETRAG } scenario Konto mit ANFANGSSALDO scenario quot;Negative Einzahlungquot;, { ein Konto mit SALDO given given quot;ein Kontoquot;, {...} when ein BETRAG eingezahlt wird when quot;ein negativer Betrag then der Saldo entspricht ANFANGSSALDO + BETRAG eingezahlt wirdquot;, { negativeEinzahlung = { konto.zahleEin(-1) } } scenario Negative Einzahlung given ein Konto then quot;eine IllegalArgumentException soll geworfen werdenquot;, { ensureThrows(IllegalArgumentException) { Betrag eingezahlt wird } when ein negativer negativeEinzahlung() then eine IllegalArgumentException } soll geworfen werden }

Veränderter Fokus

Veränderter Fokus • Weg vom Wie - hin zum Was • User Stories -> Szenarios • Anfangszustand pro Szenario • Einzelne Zusicherungen

Veränderter Fokus • Weg vom Wie - hin zum Was • User Stories -> Szenarios • Anfangszustand pro Szenario • Einzelne Zusicherungen • Weg von der Unit - hin zum Verhalten • Geringere Kopplung zwischen Code und Speziﬁkation • Refactoring vereinfacht

Veränderter Fokus • Weg vom Wie - hin zum Was • User Stories -> Szenarios • Anfangszustand pro Szenario • Einzelne Zusicherungen • Weg von der Unit - hin zum Verhalten • Geringere Kopplung zwischen Code und Speziﬁkation • Refactoring vereinfacht • Aber: Aussagekräftiges Reporting erfordert Investition in gute Texte

„Prozess“

Naives TDD

Technik JDK

Domänenmodell Technik JDK

Applikationsmodell Domänenmodell Technik JDK

Benutzerschnittstelle Applikationsmodell Domänenmodell Technik JDK

Anforderungen Benutzerschnittstelle Applikationsmodell Domänenmodell Technik JDK

Von Außen nach Innen

Von Außen nach Innen Vom Bekannten zum Unbekannten

Anforderungen JDK

Anforderungen Benutzerschnittstelle JDK

Anforderungen Benutzerschnittstelle Applikationsmodell JDK

Anforderungen Benutzerschnittstelle Applikationsmodell Domänenmodell JDK

Anforderungen JDK

Anforderungen Domänenmodell JDK

Anforderungen Benutzerschnittstelle Domänenmodell JDK

Anforderungen Benutzerschnittstelle Applikationsmodell Domänenmodell JDK

Domänenmodell

Anforderungen Domänenmodell

Anforderungen Domänenmodell Domänen- analyse

Domain Driven Design Eric Evans

Beispiel: Konten-GUI

Story: konten gui

Story: konten gui scenario Leere Kontenliste anzeigen given eine Bank ohne Konten when die Konten-Applikation gestartet wird then dann ist das Konten-Fenster offen then ist die Liste der angezeigten Konten leer

Story: konten gui scenario Leere Kontenliste anzeigen given eine Bank ohne Konten when die Konten-Applikation gestartet wird then dann ist das Konten-Fenster offen then ist die Liste der angezeigten Konten leer scenario Gefüllte Kontenliste anzeigen given eine Bank mit drei Konten when die Konten-Applikation gestartet wird then werden im Konten-Fenster drei Konten mit Inhaber und Saldo angezeigt

Story: konten gui scenario Leere Kontenliste anzeigen given eine Bank ohne Konten when die Konten-Applikation gestartet wird then dann ist das Konten-Fenster offen then ist die Liste der angezeigten Konten leer scenario Gefüllte Kontenliste anzeigen given eine Bank mit drei Konten when die Konten-Applikation gestartet wird then werden im Konten-Fenster drei Konten mit Inhaber und Saldo angezeigt scenario Löschen eines Kontos aus Kontenliste given ein offenes Konten-Fenster mit drei Konten when das erste Konto angewählt wird when der Löschen-Button gedrückt wird then verschwindet das Konto aus der Liste then wird an der Bank das Konto gelöscht

scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot; when quot;die Konten-Applikation gestartet wirdquot; then quot;dann ist das Konten-Fenster offen quot; and quot;ist die Liste der angezeigten Konten leerquot; }

scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = new Bank() } when quot;die Konten-Applikation gestartet wirdquot; then quot;dann ist das Konten-Fenster offen quot; and quot;ist die Liste der angezeigten Konten leerquot; }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = new Bank() mock(IBank) } when quot;die Konten-Applikation gestartet wirdquot; then quot;dann ist das Konten-Fenster offen quot; and quot;ist die Liste der angezeigten Konten leerquot; }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = new Bank() mock(IBank) } when quot;die Konten-Applikation gestartet wirdquot; then quot;dann ist das Konten-Fenster offen quot; and quot;ist die Liste der angezeigten Konten leerquot; } public interface IBank { }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = mock(IBank) stub(bank.getKonten()).toReturn([]) } when quot;die Konten-Applikation gestartet wirdquot; then quot;dann ist das Konten-Fenster offen quot; and quot;ist die Liste der angezeigten Konten leerquot; }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = mock(IBank) stub(bank.getKonten()).toReturn([]) } when quot;die Konten-Applikation gestartet wirdquot; then quot;dann ist das Konten-Fenster offen quot; and quot;ist die Liste der angezeigten Konten leerquot; } public interface IBank { List<Konto> getKonten(); }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = mock(IBank) stub(bank.getKonten()).toReturn([]) } when quot;die Konten-Applikation gestartet wirdquot;, { gui = new KontenApp(bank) gui.setVisible(true) } then quot;dann ist das Konten-Fenster offen quot; and quot;ist die Liste der angezeigten Konten leerquot; }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = mock(IBank) stub(bank.getKonten()).toReturn([]) } when quot;die Konten-Applikation gestartet wirdquot;, { gui = new KontenApp(bank) gui.setVisible(true) } then quot;dann ist das Konten-Fenster offen quot; public class KontenApp extends JFrame { and quot;ist die Liste der angezeigten Konten leerquot; public KontenApp(IBank bank) { } } }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = mock(IBank) stub(bank.getKonten()).toReturn([]) } when quot;die Konten-Applikation gestartet wirdquot;, { gui = new KontenApp(bank) gui.setVisible(true) } then quot;dann ist das Konten-Fenster offen quot;, { frame = new JFrameOperator(quot;Meine Kontenquot;) } and quot;ist die Liste der angezeigten Konten leerquot; }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = mock(IBank) stub(bank.getKonten()).toReturn([]) } when quot;die Konten-Applikation gestartet wirdquot;, { gui = new KontenApp(bank) gui.setVisible(true) } then quot;dann ist das Konten-Fenster offen quot;, { frame = new JFrameOperator(quot;Meine Kontenquot;) } public quot;ist die Liste der angezeigten Konten leerquot; and class KontenApp extends JFrame { } public KontenApp(IBank bank) { super(quot;Meine Kontenquot;); } }

import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = mock(IBank) stub(bank.getKonten()).toReturn([]) } when quot;die Konten-Applikation gestartet wirdquot;, { gui = new KontenApp(bank) gui.setVisible(true) } then quot;dann ist das Konten-Fenster offen quot;, { frame = new JFrameOperator(quot;Meine Kontenquot;) } and quot;ist die Liste der angezeigten Konten leerquot;, { table = new JTableOperator(frame); table.model.rowCount.shouldBe 0 } }

public class KontenApp extends JFrame { private JTable kontenTable; private final IBank bank; import static org.mockito.Mockito.* public KontenApp(IBank bank) { super(quot;Meine Kontenquot;); scenario quot;Leere Kontenliste anzeigenquot;, { this.bank = bank; given quot;eine Bank ohne Kontenquot;, { createLayout(); bank = mock(IBank)} stub(bank.getKonten()).toReturn([]) private void createLayout() { } ... createKontenTable(); when quot;die Konten-Applikation gestartet wirdquot;, { fillKontenTable(); gui = new KontenApp(bank) pack(); gui.setVisible(true) } } private void fillKontenTable() { then quot;dann ist das Konten-Fenster offen quot;, { ((KontenTableModel) kontenTable.getModel()). setKonten(bank.getKonten()); frame = new JFrameOperator(quot;Meine Kontenquot;) } } } and quot;ist die Liste der angezeigten Konten leerquot;, { table = new JTableOperator(frame); table.model.rowCount.shouldBe 0 } }

public class KontenApp extends JFrame { private JTable kontenTable; private final IBank bank; import static org.mockito.Mockito.* public KontenApp(IBank bank) { super(quot;Meine Kontenquot;); scenario quot;Leere Kontenliste anzeigenquot;, { this.bank = bank; given quot;eine Bank ohne Kontenquot;, { createLayout(); bank = mock(IBank)} stub(bank.getKonten()).toReturn([]) private void createLayout() { } ... createKontenTable(); when quot;die Konten-Applikation gestartet wirdquot;, { fillKontenTable(); gui = new KontenApp(bank) pack(); gui.setVisible(true) } } private void fillKontenTable() { then quot;dann ist das Konten-Fenster offen quot;, { ((KontenTableModel) kontenTable.getModel()). setKonten(bank.getKonten()); frame = new JFrameOperator(quot;Meine Kontenquot;) } } } and quot;ist die Liste der angezeigten Konten leerquot;, { table = new JTableOperator(frame); table.model.rowCount.shouldBe 0 } gui.dispose() }

Dummies und Mocks werden wichtiger

Dummies und Mocks werden wichtiger import static org.mockito.Mockito.* scenario quot;Leere Kontenliste anzeigenquot;, { given quot;eine Bank ohne Kontenquot;, { bank = mock(IBank) stub(bank.getKonten()).toReturn([]) } ... }

scenario quot;Löschen eines Kontos aus Kontenlistequot;, { given quot;ein offenes Konten-Fenster mit drei Kontenquot;, {...} when quot;das erste Konto angewählt wirdquot;, {...} and quot;der Löschen-Button gedrückt wirdquot;, { deleteButton = new JButtonOperator(frame, quot;Lösche Kontoquot;) deleteButton.push() } then quot;verschwindet das Konto aus der Listequot;, { checkKontenliste(table.model, [[quot;in1quot;, 10], [quot;in2quot;, 20]]) } and quot;wird an der Bank das Konto gelöschtquot;, { ??? } }

import static org.easymock.EasyMock.* scenario quot;Löschen eines Kontos aus Kontenlistequot;, { given quot;ein offenes Konten-Fenster mit drei Kontenquot;, {...} when quot;das erste Konto angewählt wirdquot;, {...} and quot;der Löschen-Button gedrückt wirdquot;, { expect(bank.loescheKonto(dreiKonten[0])) deleteButton = new JButtonOperator(frame, quot;Lösche Kontoquot;) deleteButton.push() } then quot;verschwindet das Konto aus der Listequot;, { checkKontenliste(table.model, [[quot;in1quot;, 10], [quot;in2quot;, 20]]) } and quot;wird an der Bank das Konto gelöschtquot;, { verify(bank) } }

import static org.mockito.Mockito.* scenario quot;Löschen eines Kontos aus Kontenlistequot;, { given quot;ein offenes Konten-Fenster mit drei Kontenquot;, {...} when quot;das erste Konto angewählt wirdquot;, {...} and quot;der Löschen-Button gedrückt wirdquot;, { deleteButton = new JButtonOperator(frame, quot;Lösche Kontoquot;) deleteButton.push() } then quot;verschwindet das Konto aus der Listequot;, { checkKontenliste(table.model, [[quot;in1quot;, 10], [quot;in2quot;, 20]]) } and quot;wird an der Bank das Konto gelöschtquot;, { verify(bank).loescheKonto(dreiKonten[0]) } }

Macht BDD Akzeptanztests überﬂüssig?

Ziele von Akzeptanztests

Ziele von Akzeptanztests • Funktionale Tests aus Kundensicht

Ziele von Akzeptanztests • Funktionale Tests aus Kundensicht • Sprechen die Sprache des Kunden

Ziele von Akzeptanztests • Funktionale Tests aus Kundensicht • Sprechen die Sprache des Kunden • Konkrete Beispiele der Verwendung

Ziele von Akzeptanztests • Funktionale Tests aus Kundensicht • Sprechen die Sprache des Kunden • Konkrete Beispiele der Verwendung • Können vom Kunden geschrieben und geändert werden

Ziele von Akzeptanztests • Funktionale Tests aus Kundensicht • Sprechen die Sprache des Kunden • Konkrete Beispiele der Verwendung • Können vom Kunden geschrieben und geändert werden • Testen (überwiegend) das System als Ganzes

Sind diese Ziele auch mit BDD erreichbar?

scenario Gefüllte Kontenliste anzeigen given eine Bank mit drei Konten when die Konten-Applikation gestartet wird then werden im Konten-Fenster drei Konten mit Inhaber und Saldo angezeigt scenario Löschen eines Kontos aus Kontenliste given ein offenes Konten-Fenster mit drei Konten when das erste Konto angewählt wird when der Löschen-Button gedrückt wird then verschwindet das Konto aus der Liste then wird an der Bank das Konto gelöscht

Funktionale Tests aus Kundensicht Sprechen die Sprache des Kunden Konkrete Beispiele der Verwendung Können vom Kunden geschrieben und geändert werden Testen (überwiegend) das System als Ganzes

 Funktionale Tests aus Kundensicht Sprechen die Sprache des Kunden Konkrete Beispiele der Verwendung Können vom Kunden geschrieben und geändert werden Testen (überwiegend) das System als Ganzes

 Funktionale Tests aus Kundensicht  Sprechen die Sprache des Kunden Konkrete Beispiele der Verwendung Können vom Kunden geschrieben und geändert werden Testen (überwiegend) das System als Ganzes

 Funktionale Tests aus Kundensicht  Sprechen die Sprache des Kunden  Konkrete Beispiele der Verwendung Können vom Kunden geschrieben und geändert werden Testen (überwiegend) das System als Ganzes

 Funktionale Tests aus Kundensicht  Sprechen die Sprache des Kunden  Konkrete Beispiele der Verwendung Können vom Kunden geschrieben und   geändert werden Testen (überwiegend) das System als Ganzes

 Funktionale Tests aus Kundensicht  Sprechen die Sprache des Kunden  Konkrete Beispiele der Verwendung Können vom Kunden geschrieben und   geändert werden  Testen (überwiegend) das System als Ganzes

BDD ist...

BDD ist... • „Richtiges TDD“ leicht(er) gemacht • Veränderung der Sprache • Anpassung der Tools

BDD ist... • „Richtiges TDD“ leicht(er) gemacht • Veränderung der Sprache • Anpassung der Tools • Fokus auf Speziﬁkation und Verhalten

BDD ist... • „Richtiges TDD“ leicht(er) gemacht • Veränderung der Sprache • Anpassung der Tools • Fokus auf Speziﬁkation und Verhalten • Vom Bekannten zum Unbekannten • Dummies und Mocks werden wichtiger

BDD ist... • „Richtiges TDD“ leicht(er) gemacht • Veränderung der Sprache • Anpassung der Tools • Fokus auf Speziﬁkation und Verhalten • Vom Bekannten zum Unbekannten • Dummies und Mocks werden wichtiger • Das Domänenmodell im Mittelpunkt

Web-Ressourcen • http://jbehave.org/ • http://www.jdave.org/ • http://rspec.info/ • http://nspec.tigris.org/ • http://www.domaindrivendesign.org/ • http://mockito.org/ • http://jemmy.netbeans.org/

Fragen und Anmerkungen?

Behaviour-Driven Development

by jlink on Jun 02, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 4

Statistics

Behaviour-Driven Development — Presentation Transcript