Effizientes Programmieren

Transkript

1 Effizientes Programmieren Praktikum ( ) Christopher Pietsch

2 Agenda / 32 ( )

3 Teil 1 von Softwareentwicklungsmethoden 2 / 32 ( )

4 Methodenlose Softwareentwicklung Softwareentwicklung Methodische Softwareentwicklung Klassische Methoden Agile Methoden 2 / 32 ( )

5 Methodenlose Softwareentwicklung Ad-Hoc-sprozess: - Motto: Code & fix - Kleine Projekte mit kurzer Laufzeit, z.b.: - (Wegwerf-)Prototyp - Proof-of-Concept - Demo Softwareentwicklung Methodische Softwareentwicklung Klassische Methoden Agile Methoden 3 / 32 ( )

6 Methodenlose Softwareentwicklung Softwareentwicklung Phasen-basierter sprozess, gesteuert durch: - Wasserfallmodell Klassische - Spiralmodell Methoden - V-Modell - Projekte mit (relativ) stabilem Umfeld Methodische Softwareentwicklung Agile Methoden 4 / 32 ( )

7 Beispiel: Wasserfallmodell nach Royce Analyse Entwurf Systemanforderungen Softwareanforderungen Implementierung Testen Betrieb [Roy87] 5 / 32 ( )

8 Methodenlose Softwareentwicklung Softwareentwicklung Agiler sprozess, gesteuert durch.: - Kanban Klassische - SCRUM Methoden - Extreme Programming Praktiken: Methodische Softwareentwicklung Agile Methoden 6 / 32 ( )

9 Testbegriff Test-First Ansatz Teil 2 7 / 32 ( )

10 Integration Tests Teste mich TEST Business Logik zu testende Klasse Hilfs- Klasse Ausfallstelle Testbegriff Test-First Ansatz Datenzugriff Integration Testing: [Z]wei oder mehr voneinander abhängige Softwaremodule [werden] als eine Gruppe getestet [...]. [Osh10] Daten- Hilfsdienst Datenbank Ausfallstelle Ausfallstelle 7 / 32 ( )

11 (Gute) Unit Tests Testbegriff Test-First Ansatz Definition: Unit Eine Unit ist eine Methode oder Funktion [...], die logischen Code enthält. [Osh10] Logischer Code: Bedingte Anweisungen: if, switch Schleifen: while, for Operationen: +, -,... Ausnahmen: throws Bemerkung: Getters/Setters nur dann, wenn sie logischen Code enthalten. 8 / 32 ( )

12 (Gute) Unit Tests Testbegriff Test-First Ansatz Definition: Unit Test Ein Unit Test ist ein automatisiertes Stück Code, das eine zu testende Methode oder Klasse aufruft und dann einige Annahmen über das logische Verhalten dieser Methode oder Klasse prüft[...]. [Ein guter Unit Test] kann einfach geschrieben und schnell ausgeführt werden. Er ist vollständig automatisiert, vertrauenswürdig, lesbar und wartbar. [Osh10] 9 / 32 ( )

13 (Gute) Unit Tests Testbegriff Test-First Ansatz Automatisierbar und jederzeit wiederholbar Accidental Bugging, Refactorings Einfach zu implementieren erhöhter Abdeckungsgrad Jeder sollte den Test ausführen können Collective Ownership Ausführung erfolgt auf Knopfdruck keine Konfiguration Läuft schnell erhöhte Ausführungsrate 10 / 32 ( )

14 Traditionelles Unit Testen Testbegriff Test-First Ansatz Schreibe Methode, Klasse oder Applikation optional Schreibe Unit Tests (wenn Zeit) optional Führe Unit Tests aus (wenn Zeit) Fehlerkorrektur [Osh10] 11 / 32 ( )

15 Test-First Ansatz Schreibe Test Lasse alle Tests laufen Testbegriff Test-First Ansatz Erfülle Testanforderungen durch das Schreiben von Produktionscode Lasse alle Tests laufen Wenn alle Tests erfolgreich und kein Refactoring notwendig, schreibe einen neuen Test Refactoring des Produktionscode wenn Tests erfolgreich Fehlerkorrektur wenn Tests fehlschlagen [Osh10] 12 / 32 ( )

16 Test-First Ansatz Testbegriff Test-First Ansatz Red-Green-Refactor Mantra: 1 Schreiben einer Testmethode die fehlschlägt: Fail (Testen des Tests) 2 Schreiben des Produktionscode: Pass 3 Überarbeitung des Codes Red Green Refactor 13 / 32 ( )

17 Unit Testing Framework Testbegriff Test-First Ansatz Framwork unterstützt den Entwickler beim 1 Schreiben von Tests stellt Klassenbibliothek bereit 2 Ausführen von Tests ermöglicht die automatisierte Ausführung eines oder mehrerer Tests auf Knopfdruck 3 Auswerten von Tests gibt diverse Informationen bzgl. der ausgeführten Tests zurück xunit Frameworks: CppUnit: C++ : Java NUnit:.Net / 32 ( )

18 Teil 3 15 / 32 ( )

19 Testframework Annotation-basiertes Testframework für Java Projektseite: Vollständige Integration in Eclipse IDE 15 / 32 ( )

20 Struktur von Testprojekten Testfall (Test Case): Klasse bestehend aus - Setup-Methode: Methode zum initialisieren der Testumgebung - Testmethode: Methode zum Ausführen der zu testenden Funktionalität und zum Prüfen der jeweiligen Annahmen - Teardown-Methode: Methode zum Aufräumen der Testumgebung Test Suite: Klasse zum Ausführen mehrerer Testfälle 16 / 32 ( )

21 Konventionen Testfall: [Klassenname]Test.java Testmethode: test [Methodenname()] Anmerkung: u.u. gibt es mehrere Testmethoden für eine Klassenmethode: [Methodenname] [Testbedingungen] [ErwartetesVerhalten]() 17 / 32 ( )

22 Annotierte Methode wird vor jedem Testfall Annotierte Methode wird nach jedem Testfall Annotierte Methode wird vor jeder Testmethode Annotierte Methode wird nach jeder Testmethode aufgerufen 18 / 32 ( )

23 Annotierte Methode führt den zu testenden Code aus und überprüft das erwartete = Exception.class): Annotierte Methode führt zu testenden Code aus und erwartet eine entsprechende Annotierte Methode führt zu testenden Code aus und überprüft deren Annotierte Methode wird ignoriert 19 / 32 ( )

24 Testphasen public class AllTests {} teardown() weitere Testmethode? Ja Ja Nein Fertig Nein weitere teardownafterclass() 20 / 32 ( )

25 Assertions Klasse Assert (siehe javadoc/org/junit/assert.html): fail(string): Methode schlägt immer fehl asserttrue([message], boolean condition): Prüft ob die Bedingung wahr ist assertfalse([message], boolean condition): Prüft ob die Bedingung falsch ist / 32 ( )

26 Beispiel: Calculator.java 1 public class Calculator { 2 3 private Stack<Long> mem; 4 5 public Calculator() {...} 6 7 public long add(long n1, long n2) { 8 mem.push(n1+n2); 9 return mem.peek(); 10 } public long sub(long n1, long n2) {...} public long mult(long n1, long n2) {...} public long div(long n1, long n2) throws ArithmeticException {...} public void clear() {...} public Stack<Long> getmem() {...} 21 } 22 / 32 ( )

27 Beispiel: CalculatorTest.java 1 public class CalculatorTest { 2 3 Calculator calculator; 4 6 public static void setupbeforeclass() throws Exception {...} 7 9 public static void teardownafterclass() throws Exception {...} public void setup() throws Exception { 13 calculator = new Calculator(); 14 } public void teardown() throws Exception { 18 calculator = null; 19 } 23 / 32 ( )

28 Beispiel: CalculatorTest.java 2 public void testadd() { 3 calculator.add(5, 5); 4 asserttrue(calculator.getmem().peek() == 10); 5 } 6 8 public void testsub() {...} 9 11 public void testmult() {...} public void testdiv() {...} 24 / 32 ( )

29 Beispiel: CalculatorTest.java = ArithmeticException.class) 2 public void testdiv_arithmeticexception() { 3 calculator.div(5, 0); 4 } 5 7 public void testclear() {...} 8 } 25 / 32 ( )

30 Teil 4 26 / 32 ( )

31 Problem: Externe Abhängigkeiten Definition: Externe Abhängigkeit Eine externe Abhängigkeit ist ein Objekt [...], mit dem der zu testende Code interagiert und welches außerhalb der Kontrolle des Entwickler liegt. [Osh10] Beispiele: Dateisystem Threads Zeit / 32 ( )

32 Lösung: Stubs Definition: Stub Ein Stub ist ein kontrollierbarer Ersatz für eine vorhandene Abhängigkeit [...] im System. Durch die Verwendung von Stubs kann der Code getestet werden, ohne die Abhängigkeit direkt handhaben zu müssen. [Osh10] 27 / 32 ( )

33 Lösung: Definition: Mock Ein Mock-Objekt ist ein nachgeahmtes Objekt im System, das entscheidet, ob ein Unit Test funktioniert hat oder fehlgeschlagen ist. Es macht dies, indem es verifiziert, ob das zu testende Objekt mit dem nachgeahmten Objekt wie erwartet interagiert. [Osh10] 28 / 32 ( )

34 Stub vs. Mock Stub: Ersetzt Abhängigkeit beim zustandsbasierten Testen Kann nicht fehlschlagen Mock: Ersetzt Abhängigkeit beim interaktionsbasierten Testen kann fehlschlagen Integration durch Indirektionsschicht 29 / 32 ( )

35 Stub vs. Mock Test zu testende Klasse Test Assert Kommunikation Assert Stub Mock vgl. [Osh10] 30 / 32 ( )

36 Teil 5 31 / 32 ( )

37 nstellung Implementierung einer digitalen Geldbörse (Money Bag) nach dem Test-First Ansatz ExchangeRatesDataBaseAdapterFactory -adapter: IExchangeRatesDataBaseAdapter +create(): IExchangeRatesDataBaseAdapter +setexchangeratesdatabaseadapter(adapter:iexchangeratesdatabaseadapter) 1 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[] adapter 1 IExchangeRatesDataBaseAdapter +connect(in database:string) +disconnect() +select(in s:string): Map<String,Double> 1 Currency -name: String -rates: Map<String,Double> +getname(): String +getrates(): Map<String,Double> +equals(in obj:object): boolean +currency 1 -monies * 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 ExchangeRatesDataBaseAdapterStub -name: String -currencies: Map<String,Map<String,Double>> Abbildung: Projekt: 2015s pep junit money 31 / 32 ( )

38 Teil 6 32 / 32 ( )

39 Quellen: [Osh10] R. Osherove. The Art of Unit Testing - Deutsche Ausgabe. mitp, [Roy87] W. W. Royce. Managing the Development of Large Software Systems: Concepts and Techniques. In Proceedings of the 9th International Conference on Software Engineering, ICSE 87, pages , Los Alamitos, CA, USA, IEEE Computer Society Press. Weiterführende : http: // 32 / 32 ( )