TDD with Contracts. XP Days Germany 2013 Dr. Lars Alvincz, Hagen Buchwald. c4j.vksi.de

Transkript

1 TDD with Contracts XP Days Germany 2013 Dr. Lars Alvincz, Hagen Buchwald VKSI SIG C4J - Special Interest Group Contracts for Java des Vereins Karlsruher Software Ingenieure VKSI Verein Karlsruher Software Ingenieure

2 Prolog Es war einmal... eine düstere Zeit, in der die Software-Entwicklung noch in folgende Phasen unterteilt war: Analyse Design Implementierung Test Jede dieser Phasen dauerte Wochen, Monate oder gar Jahre. Für eine fundierte Analyse und Design wurden schreckenerregende Dinge wie Softwareverträge und Design by Contract erfunden. Diese wirklich äußerst düstere Zeit haben wir endlich überwunden. Statt wochenlanger Phasen gibt es nur noch minutenlange Aktivitäten: Test Code Refactor Wer braucht heute noch Analyse und Design? Oder gar Softwareverträge?

3 Inhaltsübersicht TDD with Contracts 1. Motivation 2. Was ist TDD? (Demo) 3. Was sind Contracts? (Demo) 4. Was ist TDD with Contracts? (Demo) 5. Zusammenfassung und Bewertung 6. Fragen & Antworten

5 Motivation Softwarebugs sind teuer Je später ein Fehler gefunden wird, um so teurer die Behebung Qualität nachträglich reinzutesten ist sehr aufwändig Bei hoher Bugrate sinkt die Produktivität drastisch Code ohne Tests erschwert Weiterentwicklung deutlich führt in der Regel dazu, dass die Codequalität weiter degradiert Automatisierte Tests sind essentiell für professionelle SW-Entwicklung Kernidee dieses Vortrags: TDD ist ein Ansatz, um automatisierte Tests zu erreichen Contracts geben Sicherheit für den produktiven Einsatz

7 TDD Cycle make it red: schreibe einen Test, der fehlschlägt make it green: schreibe gerade so viel Code, dass alle Tests laufen make it right: beseitige duplizierten Code und andere code smells

8 TDD-Demo Der Auftrag Die Motivation: Die MC 2 -Bank möchte die Kundengruppe der Akademiker ausbauen. Die Strategie: Das kostenlose Studentenkonto. Der Auftrag: Es muss sichergestellt sein, dass die Studenten ihr Konto auf keinen Fall überziehen können. Die Lösung: Die Klasse Account Bild-Quelle:

9 Vorteile von TDD Design: Schnittstellen aus Client-Sicht entwickelt Code ist testbar Modularität, lose Kopplung Effizienz: Fokussierung, kein unnötiger Code Weniger Debugging Dokumentation: Ausführbare Spezifikation Tests als Sicherheitsnetz, Code bleibt flexibel Voraussetzung für agile Entwicklung Sicherheitsnetz bestehend aus 7 assert-statements

11 Prinzip eines Vertrags: Rechte und Pflichten. Die Rechte des Kunden sind die Pflichten des Anbieters und umgekehrt! Kunde Rechte Anbieter Rechte Pflichten Pflichten

12 Beispiel für einen Vertrag: Ein Kunde kauft ein Brötchen in einer Bäkerei. Kunde Rechte Ich erhalte ein Brötchen. Anbieter Rechte Ich erhalte 50 Cent. Pflichten Ich muss 50 Cent zahlen. Pflichten Ich muss ein Brötchen liefern

13 Es reicht aus, den Vertrag auf einer der beiden beteiligten Seiten zu definieren und seine Einhaltung zu überprüfen. Kunde Rechte Anbieter Rechte Pflichten Pflichten

14 In unserem Beispiel: Es reicht aus, den Vertrag auf Seiten des Bäckers zu definieren und seine Einhaltung zu überprüfen. Kunde Rechte Ich erhalte ein Brötchen. Anbieter Rechte Ich erhalte 50 Cent. Pflichten Ich muss 50 Cent zahlen. Pflichten Ich muss ein Brötchen liefern

15

16 Wie formuliert man einen vollständigen Vertrag? Die 6 Prinzipien der Vertragserstellung (Clean Contract) Prinzip 6 Prinzip 5 Formuliere Invarianten um die unveränderlichen Eigenschaften des Objekts zu beschreiben. Wähle diejenigen Attribute, die den Anwender unterstützen, das konzeptionelle Modell der Klasse zu verstehen. Prüfe für jede Abfrage und jedes Kommando, ob eine Vorbedingung erforderlich ist. Prinzip 4 Prinzip 3 Prinzip 2 Erstelle für jedes Kommando eine Nachbedingung, die den Wert jeder elementaren Abfrage auflistet. Der vollständige sichtbare Effekt eines jeden Kommandos ist nun bekannt. Erstelle für jede abgeleitete Abfrage eine Nachbedingung, die beschreibt, welches Ergebnis zurückgegeben wird, ausgedrückt durch eine oder mehrere elementare Abfragen. Trenne elementare Abfragen von abgeleiteten Abfragen. Abgeleitete Abfragen können durch elementare Abfragen ausgedrückt werden. Trenne Abfragen von Kommandos. Prinzip 1 Abfragen geben ein Ergebnis zurück, ändern jedoch nicht die sichtbaren Eigenschaften des Objekts. Kommandos können das Objekt verändern, geben jedoch kein Ergebnis zurück In enger Anlehnung an: R. Mitchell / J. McKim: Design by Contract, by Example

17 Contracts-Demo Der Auftrag Die Motivation: Die MC 2 -Bank möchte die Kundengruppe der Akademiker ausbauen. Die Strategie: Das kostenlose Studentenkonto. Der Auftrag: Es muss sichergestellt sein, dass die Studenten ihr Konto auf keinen Fall überziehen können. Die Lösung: Die Klasse Account Bild-Quelle:

18 Die Verträge werden sowohl im Eclipse Java Editor als auch im JavaDoc sichtbar Sicherheitsnetz bestehend aus 8 assert-statements

19

20 Vorteile von Contracts Design: Schnittstellen vollständig spezifiziert über Vor- und Nachbedingungen Anzeige der Annahmen, die bei der Implementierung dieser Schnittstelle in Form einer Klasse bzw. Nutzung dieser Klasse beachtet werden müssen Effizienz: Fokussierung auf Typ-Ebene, d.h. keine Vorwegnahme von Implementierungsdetails Vereinfachte Implementierung, da die Vorbedingungen als erfüllt angenommen werden können und damit Durchführungssicherheit herrscht Dokumentation: Zur Laufzeit überprüfbare Spezifikation Automatische Dokumentation der Vor- und Nachbedingungen (und Klassen- Invarianten) in der JavaDoc-Dokumentation Contracts als Sicherheitsnetz bei der Code-Ausführung Fehlerhafte Zustände werden bereits im Probebetrieb entdeckt

22 TDD with Contracts Unit Test TDD Class Interface Unit Contract package bank; public class AccountTest { private AccountSpec account = new public static void report() { System.out.println("AssertCounter: " + public void newaccount_shouldhavebalancezero() { checkbalance(0); public void deposit_shouldupdatebalance() { account.deposit(10); checkbalance(10); public void repeateddeposit_shouldupdatebalance() { account.deposit(10); account.deposit(30); public void depositandwithdraw_shouldupdatebalance() { account.deposit(15); account.withdraw(5); checkbalance(10); package bank; public class Account implements AccountSpec { private int public int getbalance() { return public void deposit(int amount) { balance += public void withdraw(int amount) { balance -= amount; package bank; import de.vksi.c4j.contractreference; import public interface AccountSpec { void deposit(int amount); void withdraw(int int getbalance(); package bank; Pre-Condition public class AccountSpecContract implements AccountSpec public void classinvariant() { assert target.getbalance() >= 0 : "balance >= Post-Condition public void deposit(int amount) { if (precondition()) { assert amount > 0 : "amount > 0"; if (postcondition()) Pre-Condition { assert target.getbalance() == old(target.getbalance()) + Post-Condition public void withdraw(int amount) { if (precondition()) { assert amount > 0 : "amount > 0"; assert target.getbalance() >= amount : "balance >= amount"; Pre-Condition if (postcondition()) { assert target.getbalance() == old(target.getbalance()) - amount; public int getbalance() { return = AssertionError.class) public void depositnegativeamount_shouldfail() { = AssertionError.class) public void withdrawnegativeamount_shouldfail() { account.withdraw(-5); = AssertionError.class) public void withdrawamountgreaterthanbalance_shouldfail() { account.deposit(10); Tests account.withdraw(20); private void checkbalance(int expectedamount) { AssertCounter.increment(); assertequals(expectedamount, account.getbalance());

23 TDD with Contracts - Demo Der Auftrag Die Motivation: Die MC 2 -Bank möchte die Kundengruppe der Akademiker ausbauen. Die Strategie: Das kostenlose Studentenkonto. Der Auftrag: Es muss sichergestellt sein, dass die Studenten ihr Konto auf keinen Fall überziehen können. Die Lösung: Die Klasse Account Bild-Quelle:

25 TDD with Contracts Unit Test TDD Class Interface Unit Contract Pre-Condition Post-Condition positive Tests Pre-Condition Post-Condition Pre-Condition Post-Condition negative Tests Klassen-Ebene (Implementierung) Typen-Ebene (Abstrakter Datentyp)

26 TDD with Contracts Beschreibung des Vorgehens TDD-Zyklus (Arbeiten auf der Klassen-Ebene) 1. Erstelle einen positiven Test für die Zielklasse. 2. Der Test scheitert. 3. Überarbeite die Zielklasse so, dass der neue Test grün wird. 4. Führe ein Refactoring (Clean Code) auf der Zielklasse und der Testklasse aus. 5. Wenn es weitere, redundanzfreie postive Tests gibt: Gehe zurück zu Schritt 1. Vorbereiten des DbC-Zyklus 6. Extrahiere das Interface aus der Zielklasse und passe die Zielklasse so an, dass sie dieses Interface implementiert. 7. Erstelle eine Vertragsklasse für das Ziel-Interface. DbC-Zyklus (Arbeiten auf der Typen-Ebene) 8. Erstelle einen negativen Test für die Zielklasse. 9. Der Test scheitert. 10. Überarbeite die Pre-Conditions der Vertragsklasse des Ziel-Interfaces so, dass der neue Test grün wird. 11. Führe ein Refactoring (Clean Code) auf der Vertragsklasse und der Testklasse aus. 12. Wenn es weitere, redundanzfreie negative Tests gibt: Gehe zurück zu Schritt 8. Abschließen des DbC-Zyklus 13. Führe ein abschließendes Refactoring (Clean Contract) auf der Vertragsklasse aus, insbesondere: Clean Contract Prinzip 4: Erstelle als Verallgemeinerung der Aussagen der positiven Tests die Beschreibung der Veränderung des sichtbaren Zustands jeder Methode des Ziel-Interfaces in Form von Post-Conditions, in der über jede elementare Abfrage des Ziel- Interfaces via assert-statement eine Aussage getroffen wird. Clean Contract Prinzip 6: Vermeide Redundanz durch Klassen-Invarianten

27 Vorteile von TDD with Contracts Design: Schnittstellen aus Client-Sicht entwickelt und vollständig spezifziert Code ist mit einem feinmaschigen Sicherheitsnetz aus Unit Tests und Unit Contracts testbar Modularität, lose Kopplung Effizienz: Fokussierung durch Abstraktion und explizite Annahmen, kein unnötiger Code Effizientes Debugging, da Fehler an der Quelle erkannt werden Dokumentation: Zur Laufzeit überprüfbare Spezifikation (Verträge als Teil des Produktivcodes) Automatische Dokumentation der Vor- und Nachbedingungen (und Klassen- Invarianten) in der JavaDoc-Dokumentation Unit Tests und Unit Contracts als äußerst feinmaschiges Sicherheitsnetz Fehlerhafte Zustände werden bereits beim automatisierten Testen entdeckt

28 Vergleich von TDD, DbC und TDD with Contracts am Beispiel der Klasse Account TDD DbC TDD with Contracts Sicherheitsnetz bestehend aus 7 assert-statements Sicherheitsnetz bestehend aus 8 assert-statements Sicherheitsnetz bestehend aus 34 assert-statements Unit Tests und Unit Contracts als äußerst feinmaschiges Sicherheitsnetz Fehlerhafte Zustände werden bereits beim automatisierten Testen entdeckt

29 What is the effect of contracts in software development? Example: Implementing the equals()method in Java

30 Applying the equals-contract to Eclipse Source Code and launching Eclipse reveals Problems with equals: 13:17:04,093 ERROR [main] de.vksi.c4j.internal.runtime.contracterrorhandler: Contract Violation in post-condition. java.lang.assertionerror: is consistent with hashcode (post-condition) at de.andrena.c4j.object.objectspeccontract.assertthat(objectspeccontract.java:65) at de.andrena.c4j.object.objectspeccontract.equalspostconditionnonnull(objectspeccontract.java:59) at de.andrena.c4j.object.objectspeccontract.equals(objectspeccontract.java:46) at org.eclipse.jface.viewers.structuredselection.equals(structuredselection.java:149) Root cause: equals has been overridden without overriding hashcode 13:17:31,747 ERROR [org.eclipse.jdt.internal.ui.text.javareconciler] de.vksi.c4j.internal.runtime.contracterrorhandler: Contract Violation in post-condition. java.lang.assertionerror: is symmetric (post-condition) at de.andrena.c4j.object.objectspeccontract.assertthat(objectspeccontract.java:65) at de.andrena.c4j.object.objectspeccontract.equalspostconditionnonnull(objectspeccontract.java:54) at de.andrena.c4j.object.objectspeccontract.equals(objectspeccontract.java:46) at org.eclipse.jdt.internal.launching.jrecontainer$ruleentry.equals(jrecontainer.java:176) Root cause: A container object may be equal to an array (by comparing its content entry per entry), but an array is not equal to a container object (only to an array)

32 Epilog Es war einmal... eine düstere Zeit, in der die Software-Entwicklung noch in folgende Phasen unterteilt war: Analyse Design Implementierung Test Jede dieser Phasen dauerte Wochen, Monate oder gar Jahre. TDD ermöglicht es, bislang Für eine fundierte Analyse und Design wurden schreckenerregende Dinge implizite Annahmen über wie Softwareverträge und Design by Contract erfunden. Vorab einen Test aus die Nutzung einer Klasse Diese wirklich äußerst düstere Zeit haben wir endlich überwunden. Kundenperspektive zu aus Kundensicht zu Statt wochenlanger schreiben Phasen ist ein gibt eleganter es nur noch minutenlange erkennen und Aktivitäten: mit Hilfe von Test Code und hoch-effektiver Weg für Analyse und Design. Contracts explizit zu formulieren. Refactor Wer braucht heute noch Analyse und Design? Oder gar Softwareverträge?

33 TDD with Contracts Fragen & Antworten Unit Test TDD Class Interface Unit Contract Pre-Condition Post-Condition positive Tests Pre-Condition Post-Condition Pre-Condition Post-Condition negative Tests Klassen-Ebene (Implementierung) Typen-Ebene (Abstrakter Datentyp)

34 TDD with Contracts XP Days Germany 2013 Dr. Lars Alvincz, Hagen Buchwald VKSI SIG C4J - Special Interest Group Contracts for Java des Vereins Karlsruher Software Ingenieure VKSI Verein Karlsruher Software Ingenieure

35 Einsatz von Softwareverträgen seit 2006 bei bwin in Stockholm. Lessons Learned 1. Pareto-Prinzip: 20% der Klassen stellen 80% der genutzten Funktionalität zur Verfügung. Es reicht aus, diese Kernklassen mit Softwareverträgen zu schützen. 2. Falsche Annahmen als Hauptfehlerquelle: 80% der bei bwin gefundenen Fehler waren auf Verletzungen von Vorbedingungen (und Klasseninvarianten) zurückzuführen. Der Grund waren falsche bzw. fehlende Annahmen darüber, wie eine Klasse genutzt werden sollte. 3. Autorenschaft schützt nicht vor falschen Annahmen: Falsche Annahmen unterliefen auch den Autoren der Klassen. Nach nur wenigen Wochen Arbeit an anderen Modulen hatten sie die Annahmen vergessen, unter denen sie die Klassen erstellt hatten. 4. Testing by Contract: Die Kombination von Softwareverträgen mit PokerBots virtuellen Spielern, die über Nacht die aktuelle Version der PokerEngine nutzten erwies sich als äußerst wirkungsvolles Instrument, um subtile Fehler aufzuspüren (Boundary Conditions, Edge Conditions, Corner Conditions). 5. Macht der Gewohnheit: Trotz dieser Erfolge blieb die Nutzung von Software-verträgen auf das PokerEngine-Team beschränkt. Andere Teams zogen nicht nach Quelle: Interview mit Jonas Bergström, Sept. 2012, Stockholm