Softwaretechnik II, Sommersemester 2011pi.informatik.uni-siegen.de/berlik/swt/JUnit-Test.pdf ·...

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)

. Testgetriebene Entwicklung 3 / 21

Gliederung

2 JUnit-Test

3 Hands on

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

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Planungsspiel

Kunde vor Ort

Refaktorisieren

KurzeReleasezyklen

NachhaltigesTempo

SystemMetapher

EinfachesDesign

KollektivesEigentum

Traditionelles Unit-Testen vs. Testgetriebene Entwicklung

[Quelle: Roy Osherove: The Art of Unit Testing.]

Traditionelles Unit-Testen vs. Testgetriebene Entwicklung

[Quelle: Roy Osherove: The Art of Unit Testing.]

Test Driven Development . Test First Design

Refactor

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

Refactor

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

. JUnit-Test 8 / 21

Gliederung

2 JUnit-Test

3 Hands on

. 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.]

. JUnit-Test 10 / 21

Das typische Vorgehen

Business Logic

Datahelper

Database

Classundertest

Helperclass

Data access

Business Logic

Datahelper

Database

Classundertest

Helperclass

Data access

Fehler?

Business Logic

Datahelper

Database

Classundertest

Helperclass

Data access

Fehler?

Business Logic

Datahelper

Database

Classundertest

Helperclass

Data access

Fehler?

. Integrationstest

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?

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)

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.]

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

*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)- . . .

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

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)

. Hands on 17 / 21

Gliederung

2 JUnit-Test

3 Hands on

. 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.

. 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 { . . . }

. 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 ( ) {

@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 ( ) {

. 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

Softwaretechnik II, Sommersemester 2011pi.informatik.uni-siegen.de/berlik/swt/JUnit-Test.pdf ·...

Documents

Transcript of Softwaretechnik II, Sommersemester 2011pi.informatik.uni-siegen.de/berlik/swt/JUnit-Test.pdf ·...