Upload
nguyencong
View
216
Download
0
Embed Size (px)
Citation preview
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
2 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Klassifikation von Softwareentwicklungsmethoden
Softwareentwicklung
MethodenloseSoftwareentwicklung
MethodischeSoftwareentwicklung
KlassischeMethoden
AgileMethoden
2 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Klassifikation von Softwareentwicklungsmethoden
Softwareentwicklung
MethodenloseSoftwareentwicklung
MethodischeSoftwareentwicklung
KlassischeMethoden
AgileMethoden
Ad-Hoc-Entwicklungsprozess:
- Motto: Code & fix
- Kleine Projekte mit kurzerLaufzeit, z.B.:
- (Wegwerf-)Prototyp
- Proof-of-Concept
- Demo
3 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Klassifikation von Softwareentwicklungsmethoden
Softwareentwicklung
MethodenloseSoftwareentwicklung
MethodischeSoftwareentwicklung
KlassischeMethoden
AgileMethoden
Phasen-basierter Entwicklungs-prozess, gesteuert durch:
- Wasserfallmodell
- Spiralmodell
- V-Modell
- Projekte mit (relativ) stabilem Umfeld
4 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Beispiel: Wasserfallmodell nach Royce
System-anforderungen
Software-anforderungen
Analyse
Entwurf
Implemen-tierung
Testen
Betrieb
[Roy87]
5 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Klassifikation von Softwareentwicklungsmethoden
Softwareentwicklung
MethodenloseSoftwareentwicklung
MethodischeSoftwareentwicklung
KlassischeMethoden
AgileMethoden
Agiler Entwicklungsprozess,gesteuert durch.:
- Kanban
- SCRUM
- Extreme Programming Praktiken:- ...- ...- Testgetriebene Entwicklung- ...
6 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
JUnit
Stubs undMocks
Aufgabe
Literatur
Teil 2
Testgetriebene Entwicklung
7 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
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]
7 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
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.
8 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
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]
9 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
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
10 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
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]
11 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
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]
12 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
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
13 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
Testbegriff
’Test-First’Ansatz
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
...
14 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Teil 3
JUnit
15 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
JUnit Testframework
Annotation-basiertes Testframework fur Java
Projektseite: http://junit.org
Vollstandige Integration in Eclipse IDE
15 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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
16 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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]()
17 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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
18 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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
19 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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 {}
20 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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
...
21 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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 }
22 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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 }
23 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Beispiel: CalculatorTest.java
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() {...}
24 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Beispiel: CalculatorTest.java
1 @Test(expected = ArithmeticException.class)2 public void testDiv_ArithmeticException() {3 calculator.div(5, 0);4 }56 @Test
7 public void testClear() {...}8 }
25 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Teil 4
Stubs und Mocks
26 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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
...
26 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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]
27 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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]
28 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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
29 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Stub vs. Mock
zutestendeKlasse
Stub
Mock
Test
Test
Kommunikation
Assert
Assert
vgl. [Osh10]
30 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Teil 5
Aufgabe
31 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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
31 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
JUnit
Stubs undMocks
Aufgabe
Literatur
Teil 6
Literatur
32 / 32 Testgetriebene Entwicklung (08.04.2015)
PEP
C. Pietsch
Klassifikationvon Software-entwicklungsme-thoden
TestgetriebeneEntwicklung
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)