1 / 43
Softwaretechnik IISommersemester 2014
Software-Qualitat
Stefan Berlik
Fachgruppe Praktische InformatikFakultat IV, Department Elektrotechnik und Informatik
Universitat Siegen
8. Mai 2014
Softwaretechnik II . Grundlagen des Softwaretestens III
2 / 43
Gliederung
1 Agile Software-EntwicklungMotivationUbersicht Softwareentwicklungs-MethodenAgile Softwareentwicklungs-Methoden
2 Testgetriebene Entwicklung
3 JUnit-Test
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung 3 / 43
Gliederung
1 Agile Software-EntwicklungMotivationUbersicht Softwareentwicklungs-MethodenAgile Softwareentwicklungs-Methoden
2 Testgetriebene Entwicklung
3 JUnit-Test
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Motivation 4 / 43
[nach: Total Quality Management, J. Oakland, 1989]
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Motivation 5 / 43
Generelle Risiken bei der Softwareentwicklung
Risiken
- Fehlerrate- Verstandnisprobleme- Personalwechsel- Anderungen von Anforderungen- Terminverzogerung- Unrentabilitat- Projektabbruche
Entwicklungsprozesse halten mit der Komplexitat der Softwarenicht Schritt
.’Softwarekrise‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Motivation 5 / 43
Generelle Risiken bei der Softwareentwicklung
Risiken
- Fehlerrate- Verstandnisprobleme- Personalwechsel- Anderungen von Anforderungen- Terminverzogerung- Unrentabilitat- Projektabbruche
Entwicklungsprozesse halten mit der Komplexitat der Softwarenicht Schritt
.’Softwarekrise‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Motivation 5 / 43
Generelle Risiken bei der Softwareentwicklung
Risiken
- Fehlerrate- Verstandnisprobleme- Personalwechsel- Anderungen von Anforderungen- Terminverzogerung- Unrentabilitat- Projektabbruche
Entwicklungsprozesse halten mit der Komplexitat der Softwarenicht Schritt.
’Softwarekrise‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 6 / 43
Klassifikation von SE-Methoden
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 6 / 43
Klassifikation von SE-Methoden
Stefan Berlik (Universitat Siegen)
’Code & fix‘,
’Hacking‘
Wenige Tests, Kommentare
Schnell unverstandlicherCode
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 6 / 43
Klassifikation von SE-Methoden
Stefan Berlik (Universitat Siegen)
’Code & fix‘,
’Hacking‘
Wenige Tests, Kommentare
Schnell unverstandlicherCode
Folge von Tatigkeiten mitphasenweisen Ergebnissen
Z.B. Wasserfallmodell, V-Modell,Spiralmodell, RUP
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 6 / 43
Klassifikation von SE-Methoden
Stefan Berlik (Universitat Siegen)
’Code & fix‘,
’Hacking‘
Wenige Tests, Kommentare
Schnell unverstandlicherCode
Folge von Tatigkeiten mitphasenweisen Ergebnissen
Z.B. Wasserfallmodell, V-Modell,Spiralmodell, RUP
Schnelle Ergebnisse fur denKunden
Intensive Zusammenarbeit mitdem Kunden
Z.B. Extreme Programming,Scrum
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 7 / 43
Ad-Hoc-Entwicklungsprozess
Nachdem die Anforderungen (mehr oder weniger) geklart sind, wirdsolange programmiert, getestet und korrigiert, bis die Software einenakzeptablen Stand erreicht hat.
Vorteile
- Kein’Overhead‘ fur Design, Dokumentation, Einhalten von Standards, . . .
- Keine Vorkenntnisse erforderlich
Nachteile
- Keine Moglichkeit, den aktuellen Projektstatus zu ermitteln- Kaum Moglichkeiten zur Projektsteuerung- Probleme bei Wartbarkeit und Erweiterbarkeit
Nur geeignet fur kleine Projekte mit kurzer Laufzeit,z.B. Wegwerfprototypen,
’Proof-of-Concept‘, Demos etc.
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 7 / 43
Ad-Hoc-Entwicklungsprozess
Nachdem die Anforderungen (mehr oder weniger) geklart sind, wirdsolange programmiert, getestet und korrigiert, bis die Software einenakzeptablen Stand erreicht hat.
Vorteile
- Kein’Overhead‘ fur Design, Dokumentation, Einhalten von Standards, . . .
- Keine Vorkenntnisse erforderlich
Nachteile
- Keine Moglichkeit, den aktuellen Projektstatus zu ermitteln- Kaum Moglichkeiten zur Projektsteuerung- Probleme bei Wartbarkeit und Erweiterbarkeit
Nur geeignet fur kleine Projekte mit kurzer Laufzeit,z.B. Wegwerfprototypen,
’Proof-of-Concept‘, Demos etc.
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 7 / 43
Ad-Hoc-Entwicklungsprozess
Nachdem die Anforderungen (mehr oder weniger) geklart sind, wirdsolange programmiert, getestet und korrigiert, bis die Software einenakzeptablen Stand erreicht hat.
Vorteile
- Kein’Overhead‘ fur Design, Dokumentation, Einhalten von Standards, . . .
- Keine Vorkenntnisse erforderlich
Nachteile
- Keine Moglichkeit, den aktuellen Projektstatus zu ermitteln- Kaum Moglichkeiten zur Projektsteuerung- Probleme bei Wartbarkeit und Erweiterbarkeit
Nur geeignet fur kleine Projekte mit kurzer Laufzeit,z.B. Wegwerfprototypen,
’Proof-of-Concept‘, Demos etc.
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 8 / 43
Wasserfallmodell [Winston Royce, 1970]
Stefan Berlik (Universitat Siegen)
”I believe in this concept, butthe implementation describedabove is risky and invitesfailure. . . ”
”Attempt to do the job twice -the first result provides an earlysimulation of the finalproduct.”
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 8 / 43
Wasserfallmodell [Winston Royce, 1970]
Stefan Berlik (Universitat Siegen)
”I believe in this concept, butthe implementation describedabove is risky and invitesfailure. . . ”
”Attempt to do the job twice -the first result provides an earlysimulation of the finalproduct.”
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 8 / 43
Wasserfallmodell [Winston Royce, 1970]
Stefan Berlik (Universitat Siegen)
”I believe in this concept, butthe implementation describedabove is risky and invitesfailure. . . ”
”Attempt to do the job twice -the first result provides an earlysimulation of the finalproduct.”
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Ubersicht Softwareentwicklungs-Methoden 9 / 43
Wasserfallmodell . Eigenschaften
Abfolge nicht uberlappender Phasen mit klar definierten Meilensteinen
Review nach Abschluss jeder einzelnen Phase zum Prufen, ob diePhasenziele erreicht wurden
Rucksprunge sind (ursprunglich) nicht vorgesehen
Geeignet fur Projekte mit stabilem Umfeld,z.B. Weiterentwicklungsprojekte oder Portierungen
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 10 / 43
Agiles Manifest als Wertesystem
[www.agilemanifesto.org]
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 11 / 43
Realisierung agiler SE-Prozesse
eXtreme Programming (XP)
- Beschreibt Techniken der agilen Softwareentwicklung
Scrum
- Beschreibt einen Entwurfsprozess der die Techniken des XP nutzt
ErgoScrum ist eher auf der Managementebene angesiedelt, XP auf derEbene der Entwicklungspraktiken
VorteilhaftKombination von Scrum und XP
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 11 / 43
Realisierung agiler SE-Prozesse
eXtreme Programming (XP)
- Beschreibt Techniken der agilen Softwareentwicklung
Scrum
- Beschreibt einen Entwurfsprozess der die Techniken des XP nutzt
ErgoScrum ist eher auf der Managementebene angesiedelt, XP auf derEbene der Entwicklungspraktiken
VorteilhaftKombination von Scrum und XP
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 12 / 43
Extreme Programming
1996 von Kent Beck vorgeschlagen als
”. . . eine leichte, effiziente, risikoarme, flexible, kalkulierbare, exakte
und vergnugliche Art und Weise der Softwareentwicklung.“
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 13 / 43
Warum’Extreme Programming‘?
”Extreme programming takes common principles and practices to
extreme levels“-
’Code reviews‘ sind gut. Standige
’code reviews‘,
’pair programming‘
- Testen ist gut. Standiges Testen
Programmierer: ModultestsKunden: Funktionstests
- Integrationstests sind wichtig. Mehrmals am Tag
’continuous integration‘
- Design ist wichtig. Standiges (re)design,
’refactoring‘
- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig
- Architektur ist wichtig. Standige Architekturweiterentwicklung
- Kurze Iterationen sind gut. Extrem kurz:
’Minuten bis Stunden‘,
’planning game‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 13 / 43
Warum’Extreme Programming‘?
”Extreme programming takes common principles and practices to
extreme levels“-
’Code reviews‘ sind gut. Standige
’code reviews‘,
’pair programming‘
- Testen ist gut. Standiges Testen
Programmierer: ModultestsKunden: Funktionstests
- Integrationstests sind wichtig. Mehrmals am Tag
’continuous integration‘
- Design ist wichtig. Standiges (re)design,
’refactoring‘
- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig
- Architektur ist wichtig. Standige Architekturweiterentwicklung
- Kurze Iterationen sind gut. Extrem kurz:
’Minuten bis Stunden‘,
’planning game‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 13 / 43
Warum’Extreme Programming‘?
”Extreme programming takes common principles and practices to
extreme levels“-
’Code reviews‘ sind gut. Standige
’code reviews‘,
’pair programming‘
- Testen ist gut. Standiges Testen
Programmierer: ModultestsKunden: Funktionstests
- Integrationstests sind wichtig. Mehrmals am Tag
’continuous integration‘
- Design ist wichtig. Standiges (re)design,
’refactoring‘
- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig
- Architektur ist wichtig. Standige Architekturweiterentwicklung
- Kurze Iterationen sind gut. Extrem kurz:
’Minuten bis Stunden‘,
’planning game‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 13 / 43
Warum’Extreme Programming‘?
”Extreme programming takes common principles and practices to
extreme levels“-
’Code reviews‘ sind gut. Standige
’code reviews‘,
’pair programming‘
- Testen ist gut. Standiges Testen
Programmierer: ModultestsKunden: Funktionstests
- Integrationstests sind wichtig. Mehrmals am Tag
’continuous integration‘
- Design ist wichtig. Standiges (re)design,
’refactoring‘
- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig
- Architektur ist wichtig. Standige Architekturweiterentwicklung
- Kurze Iterationen sind gut. Extrem kurz:
’Minuten bis Stunden‘,
’planning game‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 13 / 43
Warum’Extreme Programming‘?
”Extreme programming takes common principles and practices to
extreme levels“-
’Code reviews‘ sind gut. Standige
’code reviews‘,
’pair programming‘
- Testen ist gut. Standiges Testen
Programmierer: ModultestsKunden: Funktionstests
- Integrationstests sind wichtig. Mehrmals am Tag
’continuous integration‘
- Design ist wichtig. Standiges (re)design,
’refactoring‘
- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig
- Architektur ist wichtig. Standige Architekturweiterentwicklung
- Kurze Iterationen sind gut. Extrem kurz:
’Minuten bis Stunden‘,
’planning game‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 13 / 43
Warum’Extreme Programming‘?
”Extreme programming takes common principles and practices to
extreme levels“-
’Code reviews‘ sind gut. Standige
’code reviews‘,
’pair programming‘
- Testen ist gut. Standiges Testen
Programmierer: ModultestsKunden: Funktionstests
- Integrationstests sind wichtig. Mehrmals am Tag
’continuous integration‘
- Design ist wichtig. Standiges (re)design,
’refactoring‘
- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig
- Architektur ist wichtig. Standige Architekturweiterentwicklung
- Kurze Iterationen sind gut. Extrem kurz:
’Minuten bis Stunden‘,
’planning game‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 13 / 43
Warum’Extreme Programming‘?
”Extreme programming takes common principles and practices to
extreme levels“-
’Code reviews‘ sind gut. Standige
’code reviews‘,
’pair programming‘
- Testen ist gut. Standiges Testen
Programmierer: ModultestsKunden: Funktionstests
- Integrationstests sind wichtig. Mehrmals am Tag
’continuous integration‘
- Design ist wichtig. Standiges (re)design,
’refactoring‘
- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig
- Architektur ist wichtig. Standige Architekturweiterentwicklung
- Kurze Iterationen sind gut. Extrem kurz:
’Minuten bis Stunden‘,
’planning game‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 13 / 43
Warum’Extreme Programming‘?
”Extreme programming takes common principles and practices to
extreme levels“-
’Code reviews‘ sind gut. Standige
’code reviews‘,
’pair programming‘
- Testen ist gut. Standiges Testen
Programmierer: ModultestsKunden: Funktionstests
- Integrationstests sind wichtig. Mehrmals am Tag
’continuous integration‘
- Design ist wichtig. Standiges (re)design,
’refactoring‘
- Einfachheit ist gut. Alles so einfach wie moglich bzw. so komplex wie notig
- Architektur ist wichtig. Standige Architekturweiterentwicklung
- Kurze Iterationen sind gut. Extrem kurz:
’Minuten bis Stunden‘,
’planning game‘
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 14 / 43
Die vier Grundwerte des Extreme Programming:Kommunikation, Einfachheit, Feedback, Mut
Kommunikation
- Softwareentwicklung lebt vom effizienten Austausch von Informationen- Standige Kommunikation zwischen Kunden und Entwicklern, sowie unter
den Entwicklern selbst- Moglichst zeitnah und direkt- Von Angesicht zu Angesicht (synchron statt asynchron)
Einfachheit
- ”Do the simplest thing that could possibly work”- Einfachheit als die Kunst, Dinge nicht zu tun, die nicht unbedingt notig
sind- Fuhrt zu Losungen, die leicht verstandlich, schnell umsetzbar und leicht
adaptierbar - ergo agil - sind
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 14 / 43
Die vier Grundwerte des Extreme Programming:Kommunikation, Einfachheit, Feedback, Mut
Kommunikation
- Softwareentwicklung lebt vom effizienten Austausch von Informationen- Standige Kommunikation zwischen Kunden und Entwicklern, sowie unter
den Entwicklern selbst- Moglichst zeitnah und direkt- Von Angesicht zu Angesicht (synchron statt asynchron)
Einfachheit
- ”Do the simplest thing that could possibly work”- Einfachheit als die Kunst, Dinge nicht zu tun, die nicht unbedingt notig
sind- Fuhrt zu Losungen, die leicht verstandlich, schnell umsetzbar und leicht
adaptierbar - ergo agil - sind
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 15 / 43
Die vier Grundwerte des Extreme Programming:Kommunikation, Einfachheit, Feedback, Mut
Feedback
- Kontinuierliche Integration von Ruckmeldungen- Basierend auf
’User Stories‘ viele kleine Releases, laufende Integration,
kontinuierliches Testen
Mut
- Zu radikalen Anderungen (Refactoring)- Zu Anderungen bei Planung und Priorisierung- Zur Ehrlichkeit bei der Planung- Wird bestarkt durch automatisiertes Testen
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 15 / 43
Die vier Grundwerte des Extreme Programming:Kommunikation, Einfachheit, Feedback, Mut
Feedback
- Kontinuierliche Integration von Ruckmeldungen- Basierend auf
’User Stories‘ viele kleine Releases, laufende Integration,
kontinuierliches Testen
Mut
- Zu radikalen Anderungen (Refactoring)- Zu Anderungen bei Planung und Priorisierung- Zur Ehrlichkeit bei der Planung- Wird bestarkt durch automatisiertes Testen
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 16 / 43
Extreme Programming Praktiken
XP umfasst 12 Praktikendie sich gegenseitigunterstutzen bzw.verstarken
Gegliedert in 4 Gruppen
- Zeitnahes Feedback- Kontinuierlicher Prozess- Gemeinsames Verstandnis- Wohl der Programmierer
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 17 / 43
XP Praktiken . Zeitnahes Feedback
Planungsspiel
- Zu Beginn jeder Iteration wird vonKunden, Projektmanager und Entwicklerngemeinsam die Releaseplanung per UserStories vorgenommen.
- Priorisierung der Stories erfolgtausschließlich durch den Kunden, dieAufwandsschatzungen nur durch dieEntwickler
Programmieren in Paaren
- Immer zwei Entwickler arbeiten zusammenan einem Arbeitsplatz (KontinuierlichesCodereview)
- Erhohte Qualitat durch regenInformationsfluss
- Die Paare wechseln nach jeder Story /nach Bedarf
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 17 / 43
XP Praktiken . Zeitnahes Feedback
Planungsspiel
- Zu Beginn jeder Iteration wird vonKunden, Projektmanager und Entwicklerngemeinsam die Releaseplanung per UserStories vorgenommen.
- Priorisierung der Stories erfolgtausschließlich durch den Kunden, dieAufwandsschatzungen nur durch dieEntwickler
Programmieren in Paaren
- Immer zwei Entwickler arbeiten zusammenan einem Arbeitsplatz (KontinuierlichesCodereview)
- Erhohte Qualitat durch regenInformationsfluss
- Die Paare wechseln nach jeder Story /nach Bedarf
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 18 / 43
XP Praktiken . Zeitnahes Feedback
Testgetriebene Entwicklung
-’Test-First‘-Ansatz: Entwickler schreibenautomatisiert ausfuhrbare Unit-Testsbevor die eigentliche Funktionalitatimplementiert wird
- Kunde fuhrt Akzeptanztests durch
Kunde vor Ort
- Der Kunde ist standig anwesend (furRuckfragen, Stories, Tests)
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 18 / 43
XP Praktiken . Zeitnahes Feedback
Testgetriebene Entwicklung
-’Test-First‘-Ansatz: Entwickler schreibenautomatisiert ausfuhrbare Unit-Testsbevor die eigentliche Funktionalitatimplementiert wird
- Kunde fuhrt Akzeptanztests durch
Kunde vor Ort
- Der Kunde ist standig anwesend (furRuckfragen, Stories, Tests)
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 19 / 43
XP Praktiken . Kontinuierlicher Prozess
Permanente Integration
- Sobald ein Teil fertig implementiert ist,wird er in das Gesamtsystem integriert
- Vor und nach der Integration werden alleTests durchlaufen
Refaktorierung
- Standige Veranderung / Verbesserung desCodes
- Unit-Tests sorgen dafur, dass dergeanderte Code noch die gleicheFunktionalitat implementiert
Kurze Releasezyklen
- Kurze Iterationszeiten werden eingehalten(max. 4 Wochen)
- Releases werden dem Kunden zurKontrolle und fur Feedback ubergeben(Fruhes Feedback)
- Fruhes ROI
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 19 / 43
XP Praktiken . Kontinuierlicher Prozess
Permanente Integration
- Sobald ein Teil fertig implementiert ist,wird er in das Gesamtsystem integriert
- Vor und nach der Integration werden alleTests durchlaufen
Refaktorierung
- Standige Veranderung / Verbesserung desCodes
- Unit-Tests sorgen dafur, dass dergeanderte Code noch die gleicheFunktionalitat implementiert
Kurze Releasezyklen
- Kurze Iterationszeiten werden eingehalten(max. 4 Wochen)
- Releases werden dem Kunden zurKontrolle und fur Feedback ubergeben(Fruhes Feedback)
- Fruhes ROI
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 19 / 43
XP Praktiken . Kontinuierlicher Prozess
Permanente Integration
- Sobald ein Teil fertig implementiert ist,wird er in das Gesamtsystem integriert
- Vor und nach der Integration werden alleTests durchlaufen
Refaktorierung
- Standige Veranderung / Verbesserung desCodes
- Unit-Tests sorgen dafur, dass dergeanderte Code noch die gleicheFunktionalitat implementiert
Kurze Releasezyklen
- Kurze Iterationszeiten werden eingehalten(max. 4 Wochen)
- Releases werden dem Kunden zurKontrolle und fur Feedback ubergeben(Fruhes Feedback)
- Fruhes ROI
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 20 / 43
XP Praktiken . Gemeinsames Verstandnis
Programmierstandards
- Alle verpflichten sich, einen einheitlichenCodierungsstandard einzuhalten
Kollektives Eigentum
- Jeder hat das Recht, an jeder Stelle imCode Veranderungen vorzunehmen
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 20 / 43
XP Praktiken . Gemeinsames Verstandnis
Programmierstandards
- Alle verpflichten sich, einen einheitlichenCodierungsstandard einzuhalten
Kollektives Eigentum
- Jeder hat das Recht, an jeder Stelle imCode Veranderungen vorzunehmen
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 21 / 43
XP Praktiken . Gemeinsames Verstandnis
Einfaches Design
- Design und Code werden so einfach wiemoglich gehalten
- Code wird regelmaßig kontrolliert unduberflussiger Code sofort entfernt
- Es wird nur implementiert, was direktAuswirkung auf die Implementierung deraktuell bearbeiteten User Story hat
System Metapher
- Wenige einfache Metaphern zurBeschreibung des zu entwickelndenSystems, so dass allen sein Kern klar ist
- Metapher dient als Ersatz fur dieArchitektur
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 21 / 43
XP Praktiken . Gemeinsames Verstandnis
Einfaches Design
- Design und Code werden so einfach wiemoglich gehalten
- Code wird regelmaßig kontrolliert unduberflussiger Code sofort entfernt
- Es wird nur implementiert, was direktAuswirkung auf die Implementierung deraktuell bearbeiteten User Story hat
System Metapher
- Wenige einfache Metaphern zurBeschreibung des zu entwickelndenSystems, so dass allen sein Kern klar ist
- Metapher dient als Ersatz fur dieArchitektur
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 22 / 43
XP Praktiken . Wohl der Programmierer
Nachhaltiges Tempo
-’Marathon statt Sprint‘
- Zu hohe Arbeitsbelastung fuhrt zurVerringerung derEntwicklergeschwindigkeit
- Bei XP-Projekten kann nicht (bzw. kaum)mit Uberstunden gearbeitet werden
Planungsspiel
Programmie-ren in Paaren
TestgetriebeneEntwicklung
Kunde vor Ort
PermanenteIntegration
Refaktorisieren
KurzeReleasezyklen
NachhaltigesTempo
SystemMetapher
EinfachesDesign
KollektivesEigentum
Programmier-standards
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 23 / 43
Scrum . Uberblick
Scrum ist ein agiler Prozess, der es erlaubt auf die Auslieferung derwichtigsten Geschaftsanforderungen innerhalb kurzester Zeit zufokussieren.
Scrum gestattet es schnell und in regelmaßigen Abschnitten (Sprints)tatsachlich lauffahige Software zu inspizieren.
Das Business setzt die Prioritaten.Selbstorganisierende Entwicklungsteams legen das beste Vorgehen zurAuslieferung der hochstprioren Features fest.
Alle zwei bis vier Wochen kann jeder lauffahige Software sehen undentscheiden, diese so auszuliefern oder in einem weiteren Abschnitt zuerganzen.
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 24 / 43
Scrum . Funktionsweise
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 25 / 43
Scrum . Sprints
Scrum-Projekte schreiten in Serien von Sprints voran
Analog zu den Iterationen des Extreme Programming
Die typische Sprintdauer betragt 2-4 Wochen (nicht langer als einKalendermonat)
Eine konstante Dauer fuhrt zu einem besseren Rhythmus
Das Produkt wird wahrend des Sprints entworfen, kodiert und getestet
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 26 / 43
Sequentielle vs. uberlappende Entwicklung
Stefan Berlik (Universitat Siegen)
Anstatt alles im Ganzenhintereinander...
...tun Scrum-Teams ein bisschenvon allem die ganze Zeit uber
Softwaretechnik II . Grundlagen des Softwaretestens III
. Agile Software-Entwicklung . Agile Softwareentwicklungs-Methoden 27 / 43
Scrum . Konzepte
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 28 / 43
Gliederung
1 Agile Software-EntwicklungMotivationUbersicht Softwareentwicklungs-MethodenAgile Softwareentwicklungs-Methoden
2 Testgetriebene Entwicklung
3 JUnit-Test
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 29 / 43
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 . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 29 / 43
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 . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 30 / 43
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 . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 30 / 43
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 . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 30 / 43
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 . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 31 / 43
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 . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 31 / 43
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 . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 31 / 43
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 . Grundlagen des Softwaretestens III
. Testgetriebene Entwicklung 31 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 32 / 43
Gliederung
1 Agile Software-EntwicklungMotivationUbersicht Softwareentwicklungs-MethodenAgile Softwareentwicklungs-Methoden
2 Testgetriebene Entwicklung
3 JUnit-Test
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. JUnit-Test 33 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 34 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 34 / 43
Das typische Vorgehen
Business Logic
Datahelper
Database
Classundertest
Helperclass
Data access
Fehler?
Fehler?
Fehler?
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. JUnit-Test 34 / 43
Das typische Vorgehen
Business Logic
Datahelper
Database
Classundertest
Helperclass
Data access
Fehler?
Fehler?
Fehler?
Stefan Berlik (Universitat Siegen)
. Integrationstest
Softwaretechnik II . Grundlagen des Softwaretestens III
. JUnit-Test 35 / 43
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 (Collective
Ownership).
Ausfuhrung erfolgt auf Knopfdruck, keine Konfiguration- Tests sollen in verschiedenen Umgebungen laufen ohne angepasst werden
zu mussen.
Lauft schnell- Tests sollen moglichst oft ausgefuhrt werden konnen.
. Ein guter Test?
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. JUnit-Test 35 / 43
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 (Collective
Ownership).
Ausfuhrung erfolgt auf Knopfdruck, keine Konfiguration- Tests sollen in verschiedenen Umgebungen laufen ohne angepasst werden
zu mussen.
Lauft schnell- Tests sollen moglichst oft ausgefuhrt werden konnen.
. Ein guter Test?Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. JUnit-Test 36 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 37 / 43
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 Mocks & Stubs aufgebrochen werden
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. JUnit-Test 38 / 43
*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 . Grundlagen des Softwaretestens III
. JUnit-Test 39 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 40 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 40 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 40 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 40 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 41 / 43
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 . Grundlagen des Softwaretestens III
. JUnit-Test 42 / 43
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 . B e f o r e ;import org . j u n i t . B e f o r e C 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 C a 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 ) ;
@ B e f o r e C l a s sp u b l i c s t a t i c v o i d s e t U p B e f o r e C l a s s ( ) throws E x c e p t i o n { . . . }
@ A f t e r C l a s sp u b l i c s t a t i c v o i d t e a r D o w n A f t e r C l a s s ( ) throws E x c e p t i o n { . . . }
@Beforep u b l i c v o i d setUp ( ) throws E x c e p t i o n { . . . }
@Afte rp u b l i c v o i d tearDown ( ) throws E x c e p t i o n { . . . }
Stefan Berlik (Universitat Siegen)
Softwaretechnik II . Grundlagen des Softwaretestens III
. JUnit-Test 43 / 43
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 i m e o u t = 1)p u b l i c v o i d t e s t S u b t r a c t T i m e o u t ( ) {
t r y {Thread . s l e e p (10000) ;
} catch ( I n t e r r u p t e d E x c e p t i o n e ) {// TODOe . p r i n t S t a c k T 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@ Ig n or ep 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 ( e x p e c t e d = N u 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)