View
5
Download
0
Category
Preview:
Citation preview
1 / 21
Softwaretechnik IISommersemester 2011
Ubung JUnit-Test
Stefan Berlik
Fachgruppe Praktische InformatikFakultat IV, Department Elektrotechnik und Informatik
Universitat Siegen
15. April 2011
Softwaretechnik II . Ubung JUnit-Test
2 / 21
Gliederung
1 Testgetriebene Entwicklung
2 JUnit-Test
3 Hands on
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 3 / 21
Gliederung
1 Testgetriebene Entwicklung
2 JUnit-Test
3 Hands on
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 4 / 21
eXtreme Programming-Praktiken
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
RefactoringStandige Veranderung /Verbesserung des Codes
Continuous IntegrationNeuer Code wird sofort indie gemeinsame Codebasisintegriert
Collective OwnershipJeder hat das Recht, anjeder Stelle im CodeVeranderungenvorzunehmen
. Testgetriebene Entwicklung
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 4 / 21
eXtreme Programming-Praktiken
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
RefactoringStandige Veranderung /Verbesserung des Codes
Continuous IntegrationNeuer Code wird sofort indie gemeinsame Codebasisintegriert
Collective OwnershipJeder hat das Recht, anjeder Stelle im CodeVeranderungenvorzunehmen
. Testgetriebene Entwicklung
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 4 / 21
eXtreme Programming-Praktiken
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
RefactoringStandige Veranderung /Verbesserung des Codes
Continuous IntegrationNeuer Code wird sofort indie gemeinsame Codebasisintegriert
Collective OwnershipJeder hat das Recht, anjeder Stelle im CodeVeranderungenvorzunehmen
. Testgetriebene Entwicklung
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 4 / 21
eXtreme Programming-Praktiken
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
RefactoringStandige Veranderung /Verbesserung des Codes
Continuous IntegrationNeuer Code wird sofort indie gemeinsame Codebasisintegriert
Collective OwnershipJeder hat das Recht, anjeder Stelle im CodeVeranderungenvorzunehmen
. Testgetriebene Entwicklung
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 4 / 21
eXtreme Programming-Praktiken
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
RefactoringStandige Veranderung /Verbesserung des Codes
Continuous IntegrationNeuer Code wird sofort indie gemeinsame Codebasisintegriert
Collective OwnershipJeder hat das Recht, anjeder Stelle im CodeVeranderungenvorzunehmen
. Testgetriebene Entwicklung
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 5 / 21
Traditionelles Unit-Testen vs. Testgetriebene Entwicklung
[Quelle: Roy Osherove: The Art of Unit Testing.]
[Quelle: Roy Osherove: The Art of Unit Testing.]
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 5 / 21
Traditionelles Unit-Testen vs. Testgetriebene Entwicklung
[Quelle: Roy Osherove: The Art of Unit Testing.]
[Quelle: Roy Osherove: The Art of Unit Testing.]
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 6 / 21
Test Driven Development . Test First Design
Refactor
Red
Green
Schreiben einer Testmethode: Fail (keine Funktionvorhanden)
Schreiben einer Funktion mit minimaler, bewusstfalscher Implementierung: Fail (Testen des Tests)
Schreiben einer Funktion mit minimaler (ggf.sinnloser) Implementierung: Pass
Schreiben der benotigten Implementierung
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 6 / 21
Test Driven Development . Test First Design
Refactor
Red
Green
Schreiben einer Testmethode: Fail (keine Funktionvorhanden)
Schreiben einer Funktion mit minimaler, bewusstfalscher Implementierung: Fail (Testen des Tests)
Schreiben einer Funktion mit minimaler (ggf.sinnloser) Implementierung: Pass
Schreiben der benotigten Implementierung
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 6 / 21
Test Driven Development . Test First Design
Refactor
Red
Green
Schreiben einer Testmethode: Fail (keine Funktionvorhanden)
Schreiben einer Funktion mit minimaler, bewusstfalscher Implementierung: Fail (Testen des Tests)
Schreiben einer Funktion mit minimaler (ggf.sinnloser) Implementierung: Pass
Schreiben der benotigten Implementierung
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 7 / 21
Test Driven Development . Test First Design
Testcode wird vor dem eigentlichen Code geschriebenFrage: Wie wird die Funktionalitat genutzt? Nicht: Wie ist sieimplementiert?
Arbeiten in kleinen SchrittenEin Test + zugehoriger Code, ein Test + zugehoriger Code, . . .”You ain’t gonna need it” (Code erst schreiben, wenn er gebrauchtwird)
Code ist testbarAnders als bei ”feature first” ist Code von Anfang an testbar und mussnicht nachtraglich an Tests angepasst werden.
. TDD is specification not validation
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 7 / 21
Test Driven Development . Test First Design
Testcode wird vor dem eigentlichen Code geschriebenFrage: Wie wird die Funktionalitat genutzt? Nicht: Wie ist sieimplementiert?
Arbeiten in kleinen SchrittenEin Test + zugehoriger Code, ein Test + zugehoriger Code, . . .”You ain’t gonna need it” (Code erst schreiben, wenn er gebrauchtwird)
Code ist testbarAnders als bei ”feature first” ist Code von Anfang an testbar und mussnicht nachtraglich an Tests angepasst werden.
. TDD is specification not validation
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 7 / 21
Test Driven Development . Test First Design
Testcode wird vor dem eigentlichen Code geschriebenFrage: Wie wird die Funktionalitat genutzt? Nicht: Wie ist sieimplementiert?
Arbeiten in kleinen SchrittenEin Test + zugehoriger Code, ein Test + zugehoriger Code, . . .”You ain’t gonna need it” (Code erst schreiben, wenn er gebrauchtwird)
Code ist testbarAnders als bei ”feature first” ist Code von Anfang an testbar und mussnicht nachtraglich an Tests angepasst werden.
. TDD is specification not validation
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Testgetriebene Entwicklung 7 / 21
Test Driven Development . Test First Design
Testcode wird vor dem eigentlichen Code geschriebenFrage: Wie wird die Funktionalitat genutzt? Nicht: Wie ist sieimplementiert?
Arbeiten in kleinen SchrittenEin Test + zugehoriger Code, ein Test + zugehoriger Code, . . .”You ain’t gonna need it” (Code erst schreiben, wenn er gebrauchtwird)
Code ist testbarAnders als bei ”feature first” ist Code von Anfang an testbar und mussnicht nachtraglich an Tests angepasst werden.
. TDD is specification not validation
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 8 / 21
Gliederung
1 Testgetriebene Entwicklung
2 JUnit-Test
3 Hands on
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 9 / 21
Definition
”A unit test is a piece of a code (usually a method) that invokes anotherpiece of code and checks the correctness of some assumptions afterward.If the assumptions turn out to be wrong, the unit test has failed. A ’unit’is a method or function.” [Roy Osherove: The Art of Unit Testing.]
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 10 / 21
Das typische Vorgehen
Business Logic
Datahelper
Database
Classundertest
Helperclass
Data access
Business Logic
Datahelper
Database
Classundertest
Helperclass
Data access
Fehler?
Fehler?
Fehler?
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 10 / 21
Das typische Vorgehen
Business Logic
Datahelper
Database
Classundertest
Helperclass
Data access
Fehler?
Fehler?
Fehler?
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 10 / 21
Das typische Vorgehen
Business Logic
Datahelper
Database
Classundertest
Helperclass
Data access
Fehler?
Fehler?
Fehler?
Stefan Berlik (Universitat Siegen)
. Integrationstest
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 11 / 21
Was ist ein guter Unit TestAutomatisierbar und jederzeit wiederholbar- Anderungen im Code sind normal und erwunscht (Refactoring).Anderungen absichern.
Einfach zu implementieren- Tests schreiben bedeutet zusatzlichen Aufwand/Kosten.
Jeder sollte den Test ausfuhren konnen- Anderungen in ’fremden’ Codeteilen mussen abgesichert sein (CollectiveOwnership).
Ausfuhrung erfolgt auf Knopfdruck, keine Konfiguration- Tests sollen in verschiedenen Umgebungen laufen ohne angepasst werdenzu mussen.
Lauft schnell- Tests sollen moglichst oft ausgefuhrt werden konnen.
. Ein guter Test?
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 11 / 21
Was ist ein guter Unit TestAutomatisierbar und jederzeit wiederholbar- Anderungen im Code sind normal und erwunscht (Refactoring).Anderungen absichern.
Einfach zu implementieren- Tests schreiben bedeutet zusatzlichen Aufwand/Kosten.
Jeder sollte den Test ausfuhren konnen- Anderungen in ’fremden’ Codeteilen mussen abgesichert sein (CollectiveOwnership).
Ausfuhrung erfolgt auf Knopfdruck, keine Konfiguration- Tests sollen in verschiedenen Umgebungen laufen ohne angepasst werdenzu mussen.
Lauft schnell- Tests sollen moglichst oft ausgefuhrt werden konnen.
. Ein guter Test?Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 12 / 21
Was ist ein guter Unit-Test?
A unit test is an automated piece of code that invokes the method orclass being tested and then checks some assumptions about the logicalbehavior of that method or class. A unit test is almost always writtenusing a unit-testing framework. It can be written easily and runs quickly.It’s fully automated, trustworthy, readable and maintainable.” [Roy Osherove: The
Art of Unit Testing.]
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 13 / 21
Was muss getestet werden?
Jede offentliche Methode der Klassen des Business Layers, dieeine Logik enthalt.
- Logik: Alle Stellen, an denen etwas ’passiert’: if, for, switch,Berechnungen, exceptions, . . .
- Offentlich: Getestet werden nur die Schnittstellen, nicht dieImplementierung (Design by Contract)
- Business Layer: GUI und Data Layer sind nur mit erheblichem Aufwandautomatisiert testbar. Abhangigkeiten zum Business Layer mussen in UnitTests mittels Stubs & Mocks aufgebrochen werden
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 14 / 21
*Unit - Unit-Test Frameworks
Schreiben, Ausfuhren und Uberwachen von Unit Tests wird nur durchden Einsatz von Frameworks mit vertretbarem Aufwand realisierbar.
Unit Test Frameworks sind fur viele Sprachen verfugbar
- JUnit (Java)- NUnit (.NET)- CppUnit (C++)- SUnit (Smalltalk)- DUnit (Delphi)- MLUnit (Matlab)- . . .
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 15 / 21
Aufbau von *Unit Testprojekten
Objekt Ebene Verantwortlich
Testprojekt Anwendung Framework. Test Suite Klasse Framework. Testfall Klasse Framework
. SetUp Methode Entwickler
. Testmethode Methode Entwickler
. TearDown Methode Entwickler
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 16 / 21
Testphasen eines einzelnen Unit Tests
1 SetupInitialisierung des Testobjekts in den Testzustand(SetUp + Testmethode)
2 ExerciseAusfuhren der zu testenden Funktionalitat(Testmethode)
3 VerifyUberprufen ob der Zustand dem erwarteten entspricht(Testmethode)
4 TeardownAufraumen(TearDown Methode)
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 16 / 21
Testphasen eines einzelnen Unit Tests
1 SetupInitialisierung des Testobjekts in den Testzustand(SetUp + Testmethode)
2 ExerciseAusfuhren der zu testenden Funktionalitat(Testmethode)
3 VerifyUberprufen ob der Zustand dem erwarteten entspricht(Testmethode)
4 TeardownAufraumen(TearDown Methode)
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 16 / 21
Testphasen eines einzelnen Unit Tests
1 SetupInitialisierung des Testobjekts in den Testzustand(SetUp + Testmethode)
2 ExerciseAusfuhren der zu testenden Funktionalitat(Testmethode)
3 VerifyUberprufen ob der Zustand dem erwarteten entspricht(Testmethode)
4 TeardownAufraumen(TearDown Methode)
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. JUnit-Test 16 / 21
Testphasen eines einzelnen Unit Tests
1 SetupInitialisierung des Testobjekts in den Testzustand(SetUp + Testmethode)
2 ExerciseAusfuhren der zu testenden Funktionalitat(Testmethode)
3 VerifyUberprufen ob der Zustand dem erwarteten entspricht(Testmethode)
4 TeardownAufraumen(TearDown Methode)
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Hands on 17 / 21
Gliederung
1 Testgetriebene Entwicklung
2 JUnit-Test
3 Hands on
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Hands on 18 / 21
Neuerungen bei JUnit 4
Normale Klassendefinition ohne TestCase-Ableitung
Testmethoden brauchen kein Prafix test mehr
Testmethoden werden mit @Test Annotation gekennzeichnet (dafurnotwendig: import org.junit.Test)
Weiterhin werden, wie bei JUnit 3, Assert-Methoden furVergleichszwecke benutzt. Diese sind jetzt allerdings statischeMethoden der Klasse Assert und lassen sich so sehr einfach nutzen,wenn man eine entsprechende Import-Anweisung benutzt.
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Hands on 19 / 21
So sieht das aus...
import s t a t i c org . j u n i t . A s s e r t . a s s e r t E q u a l s ;
import org . j u n i t . A f t e r ;import org . j u n i t . A f t e r C l a s s ;import org . j u n i t . Be fo r e ;import org . j u n i t . B e f o r eC l a s s ;import org . j u n i t . I g n o r e ;import org . j u n i t . Test ;
p u b l i c c l a s s Ca l c u l a t o r U t i l T e s t {p r i v a t e s t a t i c Long n1 = n u l l ;p r i v a t e s t a t i c Long n2 = new Long (1 ) ;p r i v a t e s t a t i c Long n3 = new Long (2 ) ;
@Be fo r eC l a s sp u b l i c s t a t i c v o i d s e tUpBe f o r eC l a s s ( ) throws Excep t i on { . . . }
@Af t e rC l a s sp u b l i c s t a t i c v o i d t ea rDownAf t e rC l a s s ( ) throws Excep t i on { . . . }
@Beforep u b l i c v o i d setUp ( ) throws Excep t i on { . . . }
@Afte rp u b l i c v o i d tearDown ( ) throws Excep t i on { . . . }
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Hands on 20 / 21
So sieht das aus... (2)@Testp u b l i c v o i d t e s t S u b t r a c t Z e r o ( ) {
a s s e r t E q u a l s (new Long (0 ) , C a l c u l a t o r U t i l . s u b t r a c t ( n3 , n3 ) ) ;}
@Test ( t imeout = 1)p u b l i c v o i d t e s t Sub t r a c t T imeou t ( ) {
t r y {Thread . s l e e p (10000) ;
} catch ( I n t e r r u p t e dE x c e p t i o n e ) {// TODOe . p r i n t S t a c kT r a c e ( ) ;
}a s s e r t E q u a l s (new Long (1 ) , C a l c u l a t o r U t i l . s u b t r a c t ( n3 , n2 ) ) ;
}
@Test@Ignorep u b l i c v o i d t e s t S u b t r a c t I g n o r e ( ) {
a s s e r t E q u a l s (new Long (2 ) , C a l c u l a t o r U t i l . s u b t r a c t ( n3 , n1 ) ) ;}
@Test ( expec t ed = Nu l l P o i n t e r E x c e p t i o n . c l a s s )p u b l i c v o i d t e s t S u b t r a c t E x c e p t i o n ( ) {
a s s e r t E q u a l s (new Long (2 ) , C a l c u l a t o r U t i l . s u b t r a c t ( n1 , n1 ) ) ;}
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Ubung JUnit-Test
. Hands on 21 / 21
Praktischer Teil . ’Money-Projekt’Laden Sie das Testprojekt von folgender URL:http://pi.informatik.uni-siegen.de/berlik/swt/Currency.zip
Stefan Berlik (Universitat Siegen)
Recommended