Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 5. Test-First Prinzip...

transcript

5. Test-First Prinzip

Gliederung:

1. Einführung

2. Objektdiagramme zur Analyse von Beispielen

3. Klassendiagramme in Java implementieren

4. Methodenentwurf

6. Story Driven Modeling

7. Zusammenfassung

Motivation: rettet Prinz(essin) Ada

Aufgabe: Dinge einsammeln

Methodenentwurf:

1. Beispiel auf Anwendungsebene anschauen

2. Beispiel in Objektdiagrammen / Story Boards modellieren

3. "Dreisprung":

1. generellen Kontrollfluss auf Anwendungsebene skizzieren

2. generelles Verhalten auf Objektebene skizzieren

3. allgemeines Verhalten programmieren

4. programmiertes Verhalten am Ausgangsbeispiel testen

5. programmiertes Verhalten an alternativen Beispielen testen

Top Down / Bottom Up/ Jojo / Iterativ

Top Down: erst komplexe Methoden entwerfen dabei Hilfsmethoden erfinden dann Hilfsmethoden mit Hilfshilfsmethoden bauen usw.

Bottom Up Erst Hilfshilfsmethoden bauen dann damit Hilfsmethoden bauen dann damit die komplexen

Top Down / Bottom Up/ Jojo / Iterativ

Jojo ein bischen von oben ein bischen von unten

Iterativ irgendwo anfangen möglichst früh ausführbare Teile bauen möglichst früh einzelne komplexe Methoden bauen möglichst früh testen und praktisch einsetzen

Test First aus dem eXtreme Programming:

1. als erstes Test bauen

2. Methode realisieren bis Test läuft

3. noch ein Test zu der Methode

4. Methode verfeinern bis Test läuft

5. wenn noch ein Szenario vorstellbar gehe zu 3.

6. sonst fertig

Warum Test-First:

effizienteres Debuggen reproduzierbare Programmläufe schnelle Testwiederholung ohne manuelle Eingaben

Design for Test: bei nachträgliches Testen fehlen oft wichtige Zugriffe auf Interna dadurch schwerer und am Ende fehlt immer die Zeit zum Testen

Stabilität für iteratives Vorgehen fertige Funktionalität geht nicht wieder verloren Sicherheit bei Änderungen / Erweiterungen Wartungsfehler werden sofort entdeckt

Warum Test-First:

iteratives Vorgehen führt meist zu robuster Kernfunktionalität

frühe Kundendemo / -nutzung von Teilfunktionalität

neue Funktionalität erfordert oft Änderung an alten Methoden

dadurch oft Fehler in Teilen die schon mal funktioniert haben

Gegenmaßnahme

umfangreiche, gezielte, vollautomatische Tests für die einzelnen Funktionalitäten

Effekt

hohe Sicherheit bei Änderungen

JUnit Tests

JUnit Rahmenwerk für flexible automatische Tests

Stand-alone GUI oder in IDE integriert

alle Tests, Testgruppen oder einzelne Tests ausführbar

Testprotokolle

Kombination mit Coverage Tool interessant (später)

Aufbau eines JUnit Tests für OO Programm:

1. Objektstruktur bauen

2. Zielfunktionalität / -methode aufrufen

3. Ergebnis prüfen

4. nächste Methode aufrufen

5. Ergebnis prüfen

6. usw.

Beispielabläufe mit Objektdiagrammen

Grafische Tests mit Fujaba Story Boards

Story Board Notation:

Folge von Activities

Start Activity erzeugt Objekte

Methodenaufrufe

«system step» Kommentare

«actor step» vergleicht Ist/Soll stößt neue Schritte an

Code Generierung:

JUnit Test

Startobjekte erzeugen

Startobjekte merken

Aufrufe

Situation vergleichen

Grafische Tests mit Fujaba Story Boards

class Scencario1Test {

public Person prinz;public Raum r;public Tuer t1; …

@Testpublic void scenario1 () {prinz = new Person ();r = new Raum ();prinz.setIn (r);t1 = new Tuer ();r.tueren.add (t1);…

prinz.sammle…();

assertEquals (prinz.getIn (), r);assertTrue(r.tueren.contains(t1));

invent = prinz.hat;

assertTrue(invent.enthaelt.contains(g1));…

Programmiermethodik SS2007 © 2007 Albert Zündorf, University of Kassel 1 5. Test-First Prinzip...

Documents