Effizientes Programmieren - Praktikumpi.informatik.uni-siegen.de/lehre/Vertiefungspraktika/2015s/downloads/tdd_slides.pdf · Agenda 1 Klassi kation von Softwareentwicklungsmethoden

Effizientes ProgrammierenPraktikum

Testgetriebene Entwicklung (08.04.2015)

Christopher Pietsch

Agenda

1 Klassifikation von Softwareentwicklungsmethoden

2 Testgetriebene Entwicklung

3 JUnit

4 Stubs und Mocks

5 Aufgabe

6 Literatur

1 / 32 Testgetriebene Entwicklung (08.04.2015)

PEP

C. Pietsch

Klassifikationvon Software-entwicklungsme-thoden

TestgetriebeneEntwicklung

JUnit

Stubs undMocks

Aufgabe

Literatur

Teil 1

Klassifikation vonSoftwareentwicklungsmethoden


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Klassifikation von Softwareentwicklungsmethoden

Softwareentwicklung

MethodenloseSoftwareentwicklung

MethodischeSoftwareentwicklung

KlassischeMethoden

AgileMethoden


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur


Softwareentwicklung



KlassischeMethoden

AgileMethoden

Ad-Hoc-Entwicklungsprozess:

- Motto: Code & fix

- Kleine Projekte mit kurzerLaufzeit, z.B.:

- (Wegwerf-)Prototyp

- Proof-of-Concept

- Demo


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur


Softwareentwicklung



KlassischeMethoden

AgileMethoden

Phasen-basierter Entwicklungs-prozess, gesteuert durch:

- Wasserfallmodell

- Spiralmodell

- V-Modell

- Projekte mit (relativ) stabilem Umfeld


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Beispiel: Wasserfallmodell nach Royce

System-anforderungen

Software-anforderungen

Analyse

Entwurf

Implemen-tierung

Testen

Betrieb

[Roy87]


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur


Softwareentwicklung



KlassischeMethoden

AgileMethoden

Agiler Entwicklungsprozess,gesteuert durch.:

- Kanban

- SCRUM

- Extreme Programming Praktiken:- ...- ...- Testgetriebene Entwicklung- ...


PEP

C. Pietsch



Testbegriff

’Test-First’Ansatz

JUnit

Stubs undMocks

Aufgabe

Literatur

Teil 2

Testgetriebene Entwicklung


PEP

C. Pietsch



Testbegriff


JUnit

Stubs undMocks

Aufgabe

Literatur

Integration Tests

zutestendeKlasse

Hilfs-Klasse

Business Logik

Daten-Hilfsdienst

Datenzugriff

Daten-bank

Ausfallstelle

Ausfallstelle

Ausfallstelle

Teste mich

TEST

Integration Testing:

“[Z]wei oder mehr voneinander abhangige

Softwaremodule [werden] als eine Gruppe

getestet [...].” [Osh10]


PEP

C. Pietsch



Testbegriff


JUnit

Stubs undMocks

Aufgabe

Literatur

(Gute) Unit Tests

Definition: Unit

“Eine Unit ist eine Methode oder Funktion [...]”, die logischenCode enthalt. [Osh10]

Logischer Code:

Bedingte Anweisungen: if, switch

Schleifen: while, for

Operationen: +, -, ...

Ausnahmen: throws

Bemerkung: Getters/Setters nur dann, wenn sie logischenCode enthalten.


PEP

C. Pietsch



Testbegriff


JUnit

Stubs undMocks

Aufgabe

Literatur

(Gute) Unit Tests

Definition: Unit Test

“Ein Unit Test ist ein automatisiertes Stuck Code, das eine zutestende Methode oder Klasse aufruft und dann einigeAnnahmen uber das logische Verhalten dieser Methode oderKlasse pruft[...].[Ein guter Unit Test] kann einfach geschrieben und schnellausgefuhrt werden. Er ist vollstandig automatisiert,vertrauenswurdig, lesbar und wartbar.” [Osh10]


PEP

C. Pietsch



Testbegriff


JUnit

Stubs undMocks

Aufgabe

Literatur

(Gute) Unit Tests

Automatisierbar und jederzeit wiederholbar → AccidentalBugging, Refactorings

Einfach zu implementieren → erhohter Abdeckungsgrad

Jeder sollte den Test ausfuhren konnen → CollectiveOwnership

Ausfuhrung erfolgt auf Knopfdruck → keine Konfiguration

Lauft schnell → erhohte Ausfuhrungsrate


PEP

C. Pietsch



Testbegriff


JUnit

Stubs undMocks

Aufgabe

Literatur

Traditionelles Unit Testen

SchreibeMethode,

Klasse oderApplikation

SchreibeUnit Tests

(wenn Zeit)

Führe UnitTests aus

(wenn Zeit)

Fehler-korrektur

optional

optional

[Osh10]


PEP

C. Pietsch



Testbegriff


JUnit

Stubs undMocks

Aufgabe

Literatur

’Test-First’ Ansatz

SchreibeTest

Lassealle Tests

laufen

Erfülle Test-anforderungen

durch dasSchreiben

von Produk-tionscode

Lassealle Tests

laufen

Fehler-korrektur

wenn Testsfehlschlagen

Refactoringdes Produk-tionscode

wenn Testserfolgreich

Wenn alleTests erfolg-

reich und keinRefactoringnotwendig,

schreibe einenneuen Test

[Osh10]


PEP

C. Pietsch



Testbegriff


JUnit

Stubs undMocks

Aufgabe

Literatur

’Test-First’ Ansatz

Red

Green

Refactor

’Red-Green-Refactor’ Mantra:

1 Schreiben einer Testmethodedie fehlschlagt: Fail (Testen des Tests)

2 Schreiben des Produktionscode: Pass

3 Uberarbeitung des Codes


PEP

C. Pietsch



Testbegriff


JUnit

Stubs undMocks

Aufgabe

Literatur

Unit Testing Framework

Framwork unterstutzt den Entwickler beim

1 Schreiben von Tests → stellt Klassenbibliothek bereit

2 Ausfuhren von Tests → ermoglicht die automatisierteAusfuhrung eines oder mehrerer Tests auf Knopfdruck

3 Auswerten von Tests → gibt diverse Informationen bzgl.der ausgefuhrten Tests zuruck

xUnit Frameworks:

CppUnit: C++

JUnit: Java

NUnit: .Net

...


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Teil 3

JUnit


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

JUnit Testframework

Annotation-basiertes Testframework fur Java

Projektseite: http://junit.org

Vollstandige Integration in Eclipse IDE


http://junit.org

PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Struktur von JUnit Testprojekten

Testfall (Test Case): Klasse bestehend aus

- Setup-Methode: Methode zum initialisieren derTestumgebung

- Testmethode: Methode zum Ausfuhren der zu testendenFunktionalitat und zum Prufen der jeweiligen Annahmen

- Teardown-Methode: Methode zum Aufraumen derTestumgebung

Test Suite: Klasse zum Ausfuhren mehrerer Testfalle


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

JUnit Konventionen

Testfall: [Klassenname]Test.java

Testmethode: test [Methodenname()]Anmerkung: u.U. gibt es mehrere Testmethoden fur eineKlassenmethode:[Methodenname] [Testbedingungen] [ErwartetesVerhalten]()


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

JUnit Annotationen

@BeforeClass: Annotierte Methode wird vor jedemTestfall aufgerufen

@AfterClass: Annotierte Methode wird nach jedemTestfall aufgerufen

@Before: Annotierte Methode wird vor jeder Testmethodeaufgerufen

@After: Annotierte Methode wird nach jeder Testmethodeaufgerufen


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

JUnit Annotationen

@Test: Annotierte Methode fuhrt den zu testenden Codeaus und uberpruft das erwartete Verhalten

@Test(expected = Exception.class): AnnotierteMethode fuhrt zu testenden Code aus und erwartet eineentsprechende Ausnahme

@Test(timeout=100): Annotierte Methode fuhrt zutestenden Code aus und uberpruft deren Ausfuhrungsdauer

@Ignore: Annotierte Methode wird ignoriert


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Testphasen von JUnit Testprojekten

@BeforeClasssetUpBeforeClass()

@BeforesetUp()

@AftertearDown()

@AfterClasstearDownAfterClass()

@Testtest()

Start

Fertig

weitereTest-

methode?

weitereTest-

klasse?

Ja

Ja

Nein

Nein

@RunWith(Suite.class)@SuiteClasses({..., ...})public class AllTests {}


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

JUnit Assertions

Klasse Assert (siehe http://junit.sourceforge.net/

javadoc/org/junit/Assert.html):

fail(String): Methode schlagt immer fehl

assertTrue([message], boolean condition): Pruftob die Bedingung wahr ist

assertFalse([message], boolean condition): Pruftob die Bedingung falsch ist

...


http://junit.sourceforge.net/javadoc/org/junit/Assert.html

http://junit.sourceforge.net/javadoc/org/junit/Assert.html

PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Beispiel: Calculator.java

1 public class Calculator {23 private Stack<Long> mem;45 public Calculator() {...}67 public long add(long n1, long n2) {8 mem.push(n1+n2);9 return mem.peek();

10 }1112 public long sub(long n1, long n2) {...}1314 public long mult(long n1, long n2) {...}1516 public long div(long n1, long n2) throws ArithmeticException {...}1718 public void clear() {...}1920 public Stack<Long> getMem() {...}21 }


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Beispiel: CalculatorTest.java

1 public class CalculatorTest {23 Calculator calculator;45 @BeforeClass

6 public static void setUpBeforeClass() throws Exception {...}78 @AfterClass

9 public static void tearDownAfterClass() throws Exception {...}1011 @Before

12 public void setUp() throws Exception {13 calculator = new Calculator();14 }1516 @After

17 public void tearDown() throws Exception {18 calculator = null;19 }


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur


1 @Test

2 public void testAdd() {3 calculator.add(5, 5);4 assertTrue(calculator.getMem().peek() == 10);5 }67 @Test

8 public void testSub() {...}9

10 @Test

11 public void testMult() {...}1213 @Test

14 public void testDiv() {...}


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur


1 @Test(expected = ArithmeticException.class)2 public void testDiv_ArithmeticException() {3 calculator.div(5, 0);4 }56 @Test

7 public void testClear() {...}8 }


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Teil 4

Stubs und Mocks


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Problem: Externe Abhangigkeiten

Definition: Externe Abhangigkeit

“Eine externe Abhangigkeit ist ein Objekt [...], mit dem der zutestende Code interagiert und” welches außerhalb derKontrolle des Entwickler liegt. [Osh10]

Beispiele:

Dateisystem

Threads

Zeit

...


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Losung: Stubs

Definition: Stub

“Ein Stub ist ein kontrollierbarer Ersatz fur eine vorhandeneAbhangigkeit [...] im System. Durch die Verwendung vonStubs kann der Code getestet werden, ohne die Abhangigkeitdirekt handhaben zu mussen.” [Osh10]


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Losung: Mocks

Definition: Mock

“Ein Mock-Objekt ist ein nachgeahmtes Objekt im System,das entscheidet, ob ein Unit Test funktioniert hat oderfehlgeschlagen ist. Es macht dies, indem es verifiziert, ob daszu testende Objekt mit dem nachgeahmten Objekt wieerwartet interagiert.” [Osh10]


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Stub vs. Mock

Stub:

Ersetzt Abhangigkeit beim zustandsbasierten Testen

Kann nicht fehlschlagen

Mock:

Ersetzt Abhangigkeit beim interaktionsbasierten Testen

kann fehlschlagen

⇒ Integration durch Indirektionsschicht


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Stub vs. Mock

zutestendeKlasse

Stub

Mock

Test

Test

Kommunikation

Assert

Assert

vgl. [Osh10]


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Teil 5

Aufgabe


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Aufgabenstellung

Implementierung einer digitalen Geldborse (Money Bag) nachdem ’Test-First’ Ansatz

Money-amount: Double

+add(in money:Money): Money+sub(in money:Money): Money+times(in d:Double): Money+divide(in d:Double): Money+saldo(in c:String): String+getAmount(): Double

Currency-name: String-rates: Map<String,Double>

+getName(): String+getRates(): Map<String,Double>+equals(in obj:Object): boolean

+currency1

MoneyBag-monies: Money[]

+add(in money:Ioney): Money+sub(in money:Money): Money+times(in d:Double): MoneyBag+divide(in d:Double): MoneyBag+saldo(in c:String): String+getMonies(): Money[]

-monies*

IExchangeRatesDataBaseAdapter

+connect(in dataBase:String)+disconnect()+select(in s:String): Map<String,Double>

ExchangeRatesDataBaseAdapterStub-name: String-currencies: Map<String,Map<String,Double>>

ExchangeRatesDataBaseAdapterFactory-adapter: IExchangeRatesDataBaseAdapter

+create(): IExchangeRatesDataBaseAdapter+setExchangeRatesDataBaseAdapter(adapter:IExchangeRatesDataBaseAdapter)

adapter1

1

1

Abbildung: Projekt: 2015s pep junit money


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Teil 6

Literatur


PEP

C. Pietsch



JUnit

Stubs undMocks

Aufgabe

Literatur

Literatur

Quellen:

[Osh10] R. Osherove.The Art of Unit Testing - Deutsche Ausgabe.mitp, 2010.

[Roy87] W. W. Royce.Managing the Development of Large SoftwareSystems: Concepts and Techniques.In Proceedings of the 9th International Conference onSoftware Engineering, ICSE ’87, pages 328–338, LosAlamitos, CA, USA, 1987. IEEE Computer SocietyPress.

Weiterfuhrende Literatur:

http://junit.org/

http:

//www.vogella.com/tutorials/JUnit/article.html32 / 32 Testgetriebene Entwicklung (08.04.2015)

http://junit.org/

http://www.vogella.com/tutorials/JUnit/article.html

http://www.vogella.com/tutorials/JUnit/article.html

Documents

Effizientes Programmieren - Praktikumpi.informatik.uni-siegen.de/lehre/Vertiefungspraktika/2015s/downloads/tdd_slides.pdf · Agenda 1 Klassi kation von Softwareentwicklungsmethoden