Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
knowhow:unittesting [2011/08/31 03:16] admin angelegt |
knowhow:unittesting [2012/02/20 19:21] (aktuell) Florian Sesser tags konsolidiert |
||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | * Unit testing | ||
+ | * Was ist ein Unit? | ||
+ | * Einheit: Übereinkunft im Team | ||
+ | * Unit Testing deutsch: Modultest, Komponententest -> keine Aussage über die Größe eines Units | ||
+ | * Wikipeda unit testing: A unit is the smallest testable part of an application | ||
+ | * Nützlich? | ||
+ | * Abgrenzungen | ||
+ | * Akzeptanztests - Erfüllt das Programm die Anforderungen | ||
+ | * Funktionale Anforderungen | ||
+ | * Nichtfunktionale Anforderungen | ||
+ | * => Concordion | ||
+ | * Integrationstest - Zusammenspiel von Komponenten | ||
+ | * Teile des Systems | ||
+ | * Ganzes System | ||
+ | * Unit Test | ||
+ | * Testbare Teile in isolation | ||
+ | * Typisch in OO: Klassentest | ||
+ | * Auch Integrationstests und Akzeptanztests können mit xUnit geschrieben sein! | ||
+ | * Was finden wir oft in existierender Software vor? | ||
+ | * Ein paar mit xUnit geschriebene Tests | ||
+ | * Tests prüfen eine Hand voll Probleme, oftmals mehrere Komponenten im Zusammenspiel. | ||
+ | * Manchmal unter Einbeziehung der Umwelt | ||
+ | * --> Das sind keine Unit-Tests | ||
+ | * Was leistet eigentlich Unit-Testing? | ||
+ | * Einfaches Beispiel: Code Kata Anagramm: [[http:// | ||
+ | * Wir machen das als TDD (Checksum) | ||
+ | * Regeln für einen Unit-Test live erarbeiten (Protokoll) | ||
+ | * What is the object under Test? | ||
+ | * Naming | ||
+ | * Keine Reihenfolge | ||
+ | * Common Setup - nur um die Lesbarkeit zu erhöhen | ||
+ | * Mocking (Don't use 3rd party) | ||
+ | * Mocks / Stubs [[http:// | ||
+ | * --> Hauptgrund für IoC, Programming against Interfaces, etc. ... | ||
+ | * [[http:// | ||
+ | * State vs. Behaviour | ||
+ | * lawnsprinkler.enable() | ||
+ | * expect valve.open() | ||
+ | * verify(grass.isWet()) | ||
+ | * Beobachtungen: | ||
+ | * Programm und Test ist fertig, können wir Bugs finden? | ||
+ | * Was soll das ganze dann? | ||
+ | * Aufgaben von Unit-Tests | ||
+ | * Test von Entwicklerannahmen | ||
+ | * Die Tests stellen sicher, dass die Klassen das Interface erfüllen, das wir als Entwickler festegelegt haben. | ||
+ | * Umfangeiche Interfaces machen mehr Mühe beim Testen: Interfaces werden kleiner | ||
+ | * Hauptnutzen: | ||
+ | * Aber: Unit-Tests sind kein Ersatz für weiteres Testing (siehe Abgrenzung) | ||
+ | * Aber: Unit-Tests finden keine neuen Bugs | ||
+ | * Nach der Entwicklung ist der Test OK | ||
+ | * Non-Functional: | ||
+ | * Tests müssen ohne Aufwand durchzuführen sein | ||
+ | * Test müssen schnell sein | ||
+ | * Ergebnis: Höheres Vertrauen des Entwicklers in den Code | ||
+ | * Ergebnis: Verhindert "ich traue mich nicht das zu ändern" | ||
- | # Unit testing # | + | {{tag> |
- | ## Was ist ein Unit? ## | + | |
- | ### Einheit: Übereinkunft im Team ### | + | |
- | ### Unit Testing | + | |
- | ### Wikipeda unit testing: A unit is the smallest testable part of an application ### | + | |
- | #### Nützlich? #### | + | |
- | ## Abgrenzungen ## | + | |
- | ### Akzeptanztests - Erfüllt das Programm die Anforderungen ### | + | |
- | #### Funktionale Anforderungen #### | + | |
- | #### Nichtfunktionale Anforderungen #### | + | |
- | ##### => Concordion ##### | + | |
- | ### Integrationstest | + | |
- | #### Teile des Systems #### | + | |
- | #### Ganzes System #### | + | |
- | ### Unit Test ### | + | |
- | #### Testbare Teile in isolation #### | + | |
- | #### Typisch in OO: Klassentest #### | + | |
- | ### Auch Integrationstests und Akzeptanztests können mit xUnit geschrieben sein! ### | + | |
- | ## Was finden wir oft in existierender Software vor? ## | + | |
- | ### Ein paar mit xUnit geschriebene Tests ### | + | |
- | ### Tests prüfen eine Hand voll Probleme, oftmals mehrere Komponenten im Zusammenspiel. ### | + | |
- | ### Manchmal unter Einbeziehung der Umwelt ### | + | |
- | ### --> Das sind keine Unit-Tests ### | + | |
- | ## Was leistet eigentlich Unit-Testing? | + | |
- | ### Einfaches Beispiel: Code Kata Anagramm: ![www.codingdojo.org—wiki.plhttp:// | + | |
- | ### | + | |
- | ### Wir machen das als TDD (Checksum) ### | + | |
- | ### Regeln für einen Unit-Test live erarbeiten (Protokoll) ### | + | |
- | #### What is the object under Test? #### | + | |
- | #### Naming | + | |
- | #### Keine Reihenfolge #### | + | |
- | #### Common Setup - nur um die Lesbarkeit zu erhöhen #### | + | |
- | #### Mocking | + | |
- | ##### Mocks / Stubs ![martinfowler.com—mocksArentStubs.htmlhttp:// | + | |
- | ##### | + | |
- | ##### --> Hauptgrund für IoC, Programming against Interfaces, etc. ... ##### | + | |
- | ##### ![mockito.googlecode.com—Mockito.htmlhttp:// | + | |
- | ##### | + | |
- | #### State vs. Behaviour #### | + | |
- | ##### lawnsprinkler.enable() ##### | + | |
- | ###### expect valve.open() ###### | + | |
- | ###### verify(grass.isWet()) ###### | + | |
- | ## Beobachtungen: | + | |
- | ### Programm und Test ist fertig, können wir Bugs finden? ### | + | |
- | ### Was soll das ganze dann? ### | + | |
- | ## Aufgaben von Unit-Tests ## | + | |
- | ### Test von Entwicklerannahmen ### | + | |
- | #### Die Tests stellen sicher, dass die Klassen das Interface erfüllen, das wir als Entwickler festegelegt haben. #### | + | |
- | ### Umfangeiche Interfaces machen mehr Mühe beim Testen: Interfaces werden kleiner ### | + | |
- | ### Hauptnutzen: | + | |
- | ### Aber: Unit-Tests sind kein Ersatz für weiteres Testing (siehe Abgrenzung) ### | + | |
- | ### Aber: Unit-Tests finden keine neuen Bugs ### | + | |
- | #### Nach der Entwicklung ist der Test OK #### | + | |
- | ## Non-Functional: | + | |
- | ### Tests müssen ohne Aufwand durchzuführen sein ### | + | |
- | ### Test müssen schnell sein ### | + | |
- | ## Ergebnis: Höheres Vertrauen des Entwicklers in den Code ## | + | |
- | ## Ergebnis: Verhindert "ich traue mich nicht das zu ändern" | + | |