Post on 06-Feb-2018
Stufe 3 Gelber Grad von CCD
Lutz PrecheltInstitut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
2AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)
bull Wasbull Gestalte Interfaces so
schmal wie sinnvoll moumlglichbull so dass Klienten einer
Implementierungsklasse nur selten Abhaumlngigkeiten aufbauen die sie gar nicht benoumltigen
bull Implementierungsklassen realisieren oft mehrere Interfaces zugleich
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Verlangt sich die
Beduumlrfnisse fast aller sinnvollen Klienten einer Gruppe von Klassen vorzustellen
bull Zu schmale Zerlegung macht den Klienten das Leben schwer
3AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)
bull Folgen von Verletzungenbull Implementierende Klassen
muumlssen manchmal Methoden implementieren die sie gar nicht benoumltigen
bull Klienten dieser Klassen Programmierer muumlssen nach Interfaceauswahl noch irrelevante Methoden als solche erkennen
bull Hilfreiche Technikenbull Rollen-Denkweise
bull Fowler Role Interfacesbull -able Benennungsweise
bull Java SE Adjustable Appendable AutoClosable Callable Cloneable Closable Compilableusw usf
bull Bilde gedanklich Tupel von besonders eng zusammen-haumlngenden Methoden
bull Reichen die oumlfter mal aus bilden eigenes Interface
4AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)Beispiele
Positivbeispielebull Die Mini-Interfaces in
javalang javautilbull ComparableltTgt
bull compareTo(T)bull IterableltTgt
bull iterator()bull IteratorltTgt
bull hasNext() next() remove()
bull Readablebull read(CharBuffer)
bull Runnablebull run()
Negativbeispielbull javasqlStatement
bull 42 Methodenbull Funktionsbereiche wie
- Konfigurieren- Inhalt vorbereiten- Ausfuumlhren- Ergebnisse holen- Status abfragen- Schlieszligen Abbrechen
bull Da haumltte man einiges Abspalten koumlnnen
5AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)
bull Wasbull High-Level Klassen sollen
nicht von Low-Level Klassen abhaumlngig sein sondern beide von Interfaces
bull Vermeide statische Abhaumlngigkeit einer Klasse von Kollaborationspartnern
bull lege diese zur Laufzeit festbull zB per Dependency
Injection (DI) Move Implementation Choices Up the Call Stack
bull Wofuumlrbull Evolvierbarkeitbull Korrektheitbull (Produktionseffizienz)
bull Hinderungsgrundbull Ist erstmal umstaumlndlich
bull hellipzu denken (jedenfalls fuumlr Top-Down-Denker die an Zerlegung gewoumlhnt sind)
bull daher kommt die Bezeichnung Inversion
bull hellipzu bauen (weil man mehr Einzelteile bekommt)
bull jedenfalls in statisch getypten Sprachen(high ceremony)
6AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Haumlh
bull Ohne Inversionbull Eine High-level-Klasse H
kennt die zugehoumlrige Low-Level-Klasse L namentlich und benutzt sie statisch
bull Folge Kopplungbull Folge Geringe Flexibilitaumlt
bull zB kein Austauschen von L fuumlr Testzwecke moumlglich(fixer Datensatz statt DB-Abfrage uauml)
bull Mit Inversionbull Hohe Flexibilitaumltbull Code wird weniger mit
unbefugtem Wissen verschmutzt
bull Implementierungsklasse ist ja unbekannt
bull High-Ceremony-Technikenbull Abstraktionen meist durch
Interfaces beschreibenbull und bei Verwendung uumlber
Abstraktionen nachdenken nicht uumlber Klassen
bull siehe [DIP]bull Implementierungsklassen
injizieren (DI)bull per Konstruktor oder Setterbull evtl beim Methodenaufrufbull von Hand oder
per IoC-Behaumllter bull (siehe Gruumlner Grad)
bull Low-Ceremony-Technikenbull Injizieren aber per
Duck Typingbull Erklaumlrung
7AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)Negativbeispiel (zu wenig)
bull Groumlszligere Projekte tun sich schwer Logging konsistent zu benutzen wenn sie direkt eine Standard-API verwendenbull Auszligerdem kommen durch verwendete Open-Source-Produkte
gern gleich mehrere solche APIs vorbull httpmartinfowlercomarticlesdipInTheWildhtml
8AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
2AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)
bull Wasbull Gestalte Interfaces so
schmal wie sinnvoll moumlglichbull so dass Klienten einer
Implementierungsklasse nur selten Abhaumlngigkeiten aufbauen die sie gar nicht benoumltigen
bull Implementierungsklassen realisieren oft mehrere Interfaces zugleich
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Verlangt sich die
Beduumlrfnisse fast aller sinnvollen Klienten einer Gruppe von Klassen vorzustellen
bull Zu schmale Zerlegung macht den Klienten das Leben schwer
3AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)
bull Folgen von Verletzungenbull Implementierende Klassen
muumlssen manchmal Methoden implementieren die sie gar nicht benoumltigen
bull Klienten dieser Klassen Programmierer muumlssen nach Interfaceauswahl noch irrelevante Methoden als solche erkennen
bull Hilfreiche Technikenbull Rollen-Denkweise
bull Fowler Role Interfacesbull -able Benennungsweise
bull Java SE Adjustable Appendable AutoClosable Callable Cloneable Closable Compilableusw usf
bull Bilde gedanklich Tupel von besonders eng zusammen-haumlngenden Methoden
bull Reichen die oumlfter mal aus bilden eigenes Interface
4AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)Beispiele
Positivbeispielebull Die Mini-Interfaces in
javalang javautilbull ComparableltTgt
bull compareTo(T)bull IterableltTgt
bull iterator()bull IteratorltTgt
bull hasNext() next() remove()
bull Readablebull read(CharBuffer)
bull Runnablebull run()
Negativbeispielbull javasqlStatement
bull 42 Methodenbull Funktionsbereiche wie
- Konfigurieren- Inhalt vorbereiten- Ausfuumlhren- Ergebnisse holen- Status abfragen- Schlieszligen Abbrechen
bull Da haumltte man einiges Abspalten koumlnnen
5AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)
bull Wasbull High-Level Klassen sollen
nicht von Low-Level Klassen abhaumlngig sein sondern beide von Interfaces
bull Vermeide statische Abhaumlngigkeit einer Klasse von Kollaborationspartnern
bull lege diese zur Laufzeit festbull zB per Dependency
Injection (DI) Move Implementation Choices Up the Call Stack
bull Wofuumlrbull Evolvierbarkeitbull Korrektheitbull (Produktionseffizienz)
bull Hinderungsgrundbull Ist erstmal umstaumlndlich
bull hellipzu denken (jedenfalls fuumlr Top-Down-Denker die an Zerlegung gewoumlhnt sind)
bull daher kommt die Bezeichnung Inversion
bull hellipzu bauen (weil man mehr Einzelteile bekommt)
bull jedenfalls in statisch getypten Sprachen(high ceremony)
6AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Haumlh
bull Ohne Inversionbull Eine High-level-Klasse H
kennt die zugehoumlrige Low-Level-Klasse L namentlich und benutzt sie statisch
bull Folge Kopplungbull Folge Geringe Flexibilitaumlt
bull zB kein Austauschen von L fuumlr Testzwecke moumlglich(fixer Datensatz statt DB-Abfrage uauml)
bull Mit Inversionbull Hohe Flexibilitaumltbull Code wird weniger mit
unbefugtem Wissen verschmutzt
bull Implementierungsklasse ist ja unbekannt
bull High-Ceremony-Technikenbull Abstraktionen meist durch
Interfaces beschreibenbull und bei Verwendung uumlber
Abstraktionen nachdenken nicht uumlber Klassen
bull siehe [DIP]bull Implementierungsklassen
injizieren (DI)bull per Konstruktor oder Setterbull evtl beim Methodenaufrufbull von Hand oder
per IoC-Behaumllter bull (siehe Gruumlner Grad)
bull Low-Ceremony-Technikenbull Injizieren aber per
Duck Typingbull Erklaumlrung
7AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)Negativbeispiel (zu wenig)
bull Groumlszligere Projekte tun sich schwer Logging konsistent zu benutzen wenn sie direkt eine Standard-API verwendenbull Auszligerdem kommen durch verwendete Open-Source-Produkte
gern gleich mehrere solche APIs vorbull httpmartinfowlercomarticlesdipInTheWildhtml
8AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)
bull Wasbull Gestalte Interfaces so
schmal wie sinnvoll moumlglichbull so dass Klienten einer
Implementierungsklasse nur selten Abhaumlngigkeiten aufbauen die sie gar nicht benoumltigen
bull Implementierungsklassen realisieren oft mehrere Interfaces zugleich
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Verlangt sich die
Beduumlrfnisse fast aller sinnvollen Klienten einer Gruppe von Klassen vorzustellen
bull Zu schmale Zerlegung macht den Klienten das Leben schwer
3AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)
bull Folgen von Verletzungenbull Implementierende Klassen
muumlssen manchmal Methoden implementieren die sie gar nicht benoumltigen
bull Klienten dieser Klassen Programmierer muumlssen nach Interfaceauswahl noch irrelevante Methoden als solche erkennen
bull Hilfreiche Technikenbull Rollen-Denkweise
bull Fowler Role Interfacesbull -able Benennungsweise
bull Java SE Adjustable Appendable AutoClosable Callable Cloneable Closable Compilableusw usf
bull Bilde gedanklich Tupel von besonders eng zusammen-haumlngenden Methoden
bull Reichen die oumlfter mal aus bilden eigenes Interface
4AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)Beispiele
Positivbeispielebull Die Mini-Interfaces in
javalang javautilbull ComparableltTgt
bull compareTo(T)bull IterableltTgt
bull iterator()bull IteratorltTgt
bull hasNext() next() remove()
bull Readablebull read(CharBuffer)
bull Runnablebull run()
Negativbeispielbull javasqlStatement
bull 42 Methodenbull Funktionsbereiche wie
- Konfigurieren- Inhalt vorbereiten- Ausfuumlhren- Ergebnisse holen- Status abfragen- Schlieszligen Abbrechen
bull Da haumltte man einiges Abspalten koumlnnen
5AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)
bull Wasbull High-Level Klassen sollen
nicht von Low-Level Klassen abhaumlngig sein sondern beide von Interfaces
bull Vermeide statische Abhaumlngigkeit einer Klasse von Kollaborationspartnern
bull lege diese zur Laufzeit festbull zB per Dependency
Injection (DI) Move Implementation Choices Up the Call Stack
bull Wofuumlrbull Evolvierbarkeitbull Korrektheitbull (Produktionseffizienz)
bull Hinderungsgrundbull Ist erstmal umstaumlndlich
bull hellipzu denken (jedenfalls fuumlr Top-Down-Denker die an Zerlegung gewoumlhnt sind)
bull daher kommt die Bezeichnung Inversion
bull hellipzu bauen (weil man mehr Einzelteile bekommt)
bull jedenfalls in statisch getypten Sprachen(high ceremony)
6AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Haumlh
bull Ohne Inversionbull Eine High-level-Klasse H
kennt die zugehoumlrige Low-Level-Klasse L namentlich und benutzt sie statisch
bull Folge Kopplungbull Folge Geringe Flexibilitaumlt
bull zB kein Austauschen von L fuumlr Testzwecke moumlglich(fixer Datensatz statt DB-Abfrage uauml)
bull Mit Inversionbull Hohe Flexibilitaumltbull Code wird weniger mit
unbefugtem Wissen verschmutzt
bull Implementierungsklasse ist ja unbekannt
bull High-Ceremony-Technikenbull Abstraktionen meist durch
Interfaces beschreibenbull und bei Verwendung uumlber
Abstraktionen nachdenken nicht uumlber Klassen
bull siehe [DIP]bull Implementierungsklassen
injizieren (DI)bull per Konstruktor oder Setterbull evtl beim Methodenaufrufbull von Hand oder
per IoC-Behaumllter bull (siehe Gruumlner Grad)
bull Low-Ceremony-Technikenbull Injizieren aber per
Duck Typingbull Erklaumlrung
7AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)Negativbeispiel (zu wenig)
bull Groumlszligere Projekte tun sich schwer Logging konsistent zu benutzen wenn sie direkt eine Standard-API verwendenbull Auszligerdem kommen durch verwendete Open-Source-Produkte
gern gleich mehrere solche APIs vorbull httpmartinfowlercomarticlesdipInTheWildhtml
8AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)
bull Folgen von Verletzungenbull Implementierende Klassen
muumlssen manchmal Methoden implementieren die sie gar nicht benoumltigen
bull Klienten dieser Klassen Programmierer muumlssen nach Interfaceauswahl noch irrelevante Methoden als solche erkennen
bull Hilfreiche Technikenbull Rollen-Denkweise
bull Fowler Role Interfacesbull -able Benennungsweise
bull Java SE Adjustable Appendable AutoClosable Callable Cloneable Closable Compilableusw usf
bull Bilde gedanklich Tupel von besonders eng zusammen-haumlngenden Methoden
bull Reichen die oumlfter mal aus bilden eigenes Interface
4AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)Beispiele
Positivbeispielebull Die Mini-Interfaces in
javalang javautilbull ComparableltTgt
bull compareTo(T)bull IterableltTgt
bull iterator()bull IteratorltTgt
bull hasNext() next() remove()
bull Readablebull read(CharBuffer)
bull Runnablebull run()
Negativbeispielbull javasqlStatement
bull 42 Methodenbull Funktionsbereiche wie
- Konfigurieren- Inhalt vorbereiten- Ausfuumlhren- Ergebnisse holen- Status abfragen- Schlieszligen Abbrechen
bull Da haumltte man einiges Abspalten koumlnnen
5AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)
bull Wasbull High-Level Klassen sollen
nicht von Low-Level Klassen abhaumlngig sein sondern beide von Interfaces
bull Vermeide statische Abhaumlngigkeit einer Klasse von Kollaborationspartnern
bull lege diese zur Laufzeit festbull zB per Dependency
Injection (DI) Move Implementation Choices Up the Call Stack
bull Wofuumlrbull Evolvierbarkeitbull Korrektheitbull (Produktionseffizienz)
bull Hinderungsgrundbull Ist erstmal umstaumlndlich
bull hellipzu denken (jedenfalls fuumlr Top-Down-Denker die an Zerlegung gewoumlhnt sind)
bull daher kommt die Bezeichnung Inversion
bull hellipzu bauen (weil man mehr Einzelteile bekommt)
bull jedenfalls in statisch getypten Sprachen(high ceremony)
6AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Haumlh
bull Ohne Inversionbull Eine High-level-Klasse H
kennt die zugehoumlrige Low-Level-Klasse L namentlich und benutzt sie statisch
bull Folge Kopplungbull Folge Geringe Flexibilitaumlt
bull zB kein Austauschen von L fuumlr Testzwecke moumlglich(fixer Datensatz statt DB-Abfrage uauml)
bull Mit Inversionbull Hohe Flexibilitaumltbull Code wird weniger mit
unbefugtem Wissen verschmutzt
bull Implementierungsklasse ist ja unbekannt
bull High-Ceremony-Technikenbull Abstraktionen meist durch
Interfaces beschreibenbull und bei Verwendung uumlber
Abstraktionen nachdenken nicht uumlber Klassen
bull siehe [DIP]bull Implementierungsklassen
injizieren (DI)bull per Konstruktor oder Setterbull evtl beim Methodenaufrufbull von Hand oder
per IoC-Behaumllter bull (siehe Gruumlner Grad)
bull Low-Ceremony-Technikenbull Injizieren aber per
Duck Typingbull Erklaumlrung
7AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)Negativbeispiel (zu wenig)
bull Groumlszligere Projekte tun sich schwer Logging konsistent zu benutzen wenn sie direkt eine Standard-API verwendenbull Auszligerdem kommen durch verwendete Open-Source-Produkte
gern gleich mehrere solche APIs vorbull httpmartinfowlercomarticlesdipInTheWildhtml
8AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Interface Segregation Principle (ISP)Beispiele
Positivbeispielebull Die Mini-Interfaces in
javalang javautilbull ComparableltTgt
bull compareTo(T)bull IterableltTgt
bull iterator()bull IteratorltTgt
bull hasNext() next() remove()
bull Readablebull read(CharBuffer)
bull Runnablebull run()
Negativbeispielbull javasqlStatement
bull 42 Methodenbull Funktionsbereiche wie
- Konfigurieren- Inhalt vorbereiten- Ausfuumlhren- Ergebnisse holen- Status abfragen- Schlieszligen Abbrechen
bull Da haumltte man einiges Abspalten koumlnnen
5AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)
bull Wasbull High-Level Klassen sollen
nicht von Low-Level Klassen abhaumlngig sein sondern beide von Interfaces
bull Vermeide statische Abhaumlngigkeit einer Klasse von Kollaborationspartnern
bull lege diese zur Laufzeit festbull zB per Dependency
Injection (DI) Move Implementation Choices Up the Call Stack
bull Wofuumlrbull Evolvierbarkeitbull Korrektheitbull (Produktionseffizienz)
bull Hinderungsgrundbull Ist erstmal umstaumlndlich
bull hellipzu denken (jedenfalls fuumlr Top-Down-Denker die an Zerlegung gewoumlhnt sind)
bull daher kommt die Bezeichnung Inversion
bull hellipzu bauen (weil man mehr Einzelteile bekommt)
bull jedenfalls in statisch getypten Sprachen(high ceremony)
6AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Haumlh
bull Ohne Inversionbull Eine High-level-Klasse H
kennt die zugehoumlrige Low-Level-Klasse L namentlich und benutzt sie statisch
bull Folge Kopplungbull Folge Geringe Flexibilitaumlt
bull zB kein Austauschen von L fuumlr Testzwecke moumlglich(fixer Datensatz statt DB-Abfrage uauml)
bull Mit Inversionbull Hohe Flexibilitaumltbull Code wird weniger mit
unbefugtem Wissen verschmutzt
bull Implementierungsklasse ist ja unbekannt
bull High-Ceremony-Technikenbull Abstraktionen meist durch
Interfaces beschreibenbull und bei Verwendung uumlber
Abstraktionen nachdenken nicht uumlber Klassen
bull siehe [DIP]bull Implementierungsklassen
injizieren (DI)bull per Konstruktor oder Setterbull evtl beim Methodenaufrufbull von Hand oder
per IoC-Behaumllter bull (siehe Gruumlner Grad)
bull Low-Ceremony-Technikenbull Injizieren aber per
Duck Typingbull Erklaumlrung
7AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)Negativbeispiel (zu wenig)
bull Groumlszligere Projekte tun sich schwer Logging konsistent zu benutzen wenn sie direkt eine Standard-API verwendenbull Auszligerdem kommen durch verwendete Open-Source-Produkte
gern gleich mehrere solche APIs vorbull httpmartinfowlercomarticlesdipInTheWildhtml
8AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)
bull Wasbull High-Level Klassen sollen
nicht von Low-Level Klassen abhaumlngig sein sondern beide von Interfaces
bull Vermeide statische Abhaumlngigkeit einer Klasse von Kollaborationspartnern
bull lege diese zur Laufzeit festbull zB per Dependency
Injection (DI) Move Implementation Choices Up the Call Stack
bull Wofuumlrbull Evolvierbarkeitbull Korrektheitbull (Produktionseffizienz)
bull Hinderungsgrundbull Ist erstmal umstaumlndlich
bull hellipzu denken (jedenfalls fuumlr Top-Down-Denker die an Zerlegung gewoumlhnt sind)
bull daher kommt die Bezeichnung Inversion
bull hellipzu bauen (weil man mehr Einzelteile bekommt)
bull jedenfalls in statisch getypten Sprachen(high ceremony)
6AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Haumlh
bull Ohne Inversionbull Eine High-level-Klasse H
kennt die zugehoumlrige Low-Level-Klasse L namentlich und benutzt sie statisch
bull Folge Kopplungbull Folge Geringe Flexibilitaumlt
bull zB kein Austauschen von L fuumlr Testzwecke moumlglich(fixer Datensatz statt DB-Abfrage uauml)
bull Mit Inversionbull Hohe Flexibilitaumltbull Code wird weniger mit
unbefugtem Wissen verschmutzt
bull Implementierungsklasse ist ja unbekannt
bull High-Ceremony-Technikenbull Abstraktionen meist durch
Interfaces beschreibenbull und bei Verwendung uumlber
Abstraktionen nachdenken nicht uumlber Klassen
bull siehe [DIP]bull Implementierungsklassen
injizieren (DI)bull per Konstruktor oder Setterbull evtl beim Methodenaufrufbull von Hand oder
per IoC-Behaumllter bull (siehe Gruumlner Grad)
bull Low-Ceremony-Technikenbull Injizieren aber per
Duck Typingbull Erklaumlrung
7AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)Negativbeispiel (zu wenig)
bull Groumlszligere Projekte tun sich schwer Logging konsistent zu benutzen wenn sie direkt eine Standard-API verwendenbull Auszligerdem kommen durch verwendete Open-Source-Produkte
gern gleich mehrere solche APIs vorbull httpmartinfowlercomarticlesdipInTheWildhtml
8AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Haumlh
bull Ohne Inversionbull Eine High-level-Klasse H
kennt die zugehoumlrige Low-Level-Klasse L namentlich und benutzt sie statisch
bull Folge Kopplungbull Folge Geringe Flexibilitaumlt
bull zB kein Austauschen von L fuumlr Testzwecke moumlglich(fixer Datensatz statt DB-Abfrage uauml)
bull Mit Inversionbull Hohe Flexibilitaumltbull Code wird weniger mit
unbefugtem Wissen verschmutzt
bull Implementierungsklasse ist ja unbekannt
bull High-Ceremony-Technikenbull Abstraktionen meist durch
Interfaces beschreibenbull und bei Verwendung uumlber
Abstraktionen nachdenken nicht uumlber Klassen
bull siehe [DIP]bull Implementierungsklassen
injizieren (DI)bull per Konstruktor oder Setterbull evtl beim Methodenaufrufbull von Hand oder
per IoC-Behaumllter bull (siehe Gruumlner Grad)
bull Low-Ceremony-Technikenbull Injizieren aber per
Duck Typingbull Erklaumlrung
7AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Dependency Inversion Principle (DIP)Negativbeispiel (zu wenig)
bull Groumlszligere Projekte tun sich schwer Logging konsistent zu benutzen wenn sie direkt eine Standard-API verwendenbull Auszligerdem kommen durch verwendete Open-Source-Produkte
gern gleich mehrere solche APIs vorbull httpmartinfowlercomarticlesdipInTheWildhtml
8AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Negativbeispiel (zu wenig)
bull Groumlszligere Projekte tun sich schwer Logging konsistent zu benutzen wenn sie direkt eine Standard-API verwendenbull Auszligerdem kommen durch verwendete Open-Source-Produkte
gern gleich mehrere solche APIs vorbull httpmartinfowlercomarticlesdipInTheWildhtml
8AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)Positivbeispiel (gelungen)
bull Es ist deshalb sinnvoll sich lieber eine eigene schlanke API zu definieren ndash und zwar abstraktbull Und flugs sieht man auch die mehreren fremden APIs nicht mehr
selbst falls man sie anspricht
9AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Dependency Inversion Principle (DIP)2 Beispiel
bull Fuumlr ein System wie diesesbull (berechne Zeitplaumlne fuumlr Arbeitsposten die Ressourcen brauchen
und dadurch in Konflikt stehen koumlnnen)bull muss Zeit eine frei manipulierbare Implementierung haben
bull Beschleunigen beliebige Zeitreisenbull Denn wer hier fest Standardklassen benutzt bekommt
riesige Testprobleme
10AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
httpmartinfowlercomarticlesdipInTheWildhtml
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)
bull Wasbull Untertypen muumlssen die
Vertraumlge ihrer Obertypen einhalten
bull egal ob Klassen oder Interfaces
bull Vererbung ist deshalb nicht is a sondern behaves like
bull Ein Quadrat ist ein Rechteck aber ein Quadrat-Objekt ist keinRechteck-Objekt
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Bequemlichkeit
11AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Bar
bara
Lis
kov
Wik
imed
ia C
omm
ons
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)
bull Wirkung von Verletzungenbull Nach Einfuumlhren eines neuen
Untertyps treten ploumltzlich Versagen in ausgereiftem anderen Code auf
bull Entwickler verzweifeln beim Versuch die Benutzung einer groumlszligeren Klassenhierarchie zu verstehen
bull Hilfreiche Technikenbull Design by Contract (DbC)
Vertraumlge in Obertypen explizit formulieren
bull Voraussetzungenbull inkl Aufrufreihenfolgen
bull Wirkungenbull Ruumlckgabewertebull Zustandsaumlnderungenbull Nebenwirkungen
bull ggf nichtfunktionale Eigenschaften
bull Moumlglichst viel davon zur Laufzeit uumlberpruumlfen
12AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)
bull javautilIteratorbull remove() sagt ausdruumlcklich
dass nicht jede Implementierung das erlaubt
13AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wasbull Klassen Methoden
Variablen sollten das tun und enthalten was ihr Name suggeriert
bull nicht etwas anderesbull nicht noch mehr
bull und auszligerdem die Konventionen der Sprache und Plattform einhalten
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Fuumlhrt zu langen Namen
oderbull verlangt kurze Klassen und
vor allem Methoden
14AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)
bull Wirkung von Verletzungenbull Mehr Programmierfehlerbull Schnelleres Verfallen der
Entwurfsstrukturbull weil die Aumlnderer sich
weniger zum Ordnung-Halten veranlasst sehen
bull Hilfreiche Technikenbull Funktionen oder Prozeduren
bull (nicht Resultate und Nebenwirkungen mischen)
bull Namenskonventionen habenbull Namenskonventionen
streng einhaltenbull Domaumlnenbegriffe benutzenbull SRP
bull inbes Software-Blutgruppen trennen
bull DbC Vertraumlge angeben
15AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Principle of Least Astonishment (LA)Negativbeispiel
bull Wenn eine Methode so deklariert istFileListDiff computeDiff(hellip)
bull Was erwarten Sie dann fuumlr eine Art von Funktionalitaumltbull Welche nicht
bull So sieht die Methode tatsaumlchlich ausbull IncomingProjectNegotiationjava (ab Z511 Z542)
16AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding(IH Geheimnisprinzip)
bull Wasbull Jede Schnittstelle sollte eine
Entwurfsentscheidung verbergen
bull D Parnas Geheimnisprinzip
bull Ein Aspekt von SoCbull Deren Thema sollte benannt
sein
bull Wofuumlrbull Evolvierbarkeitbull Produktionseffizienz
bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion
17AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)
bull Arten und Wirkung von Verletzungenbull Durch Modulbenutzer
Wissen das nicht explizit Teil der Schnittstelle ist ist dennoch im System verteilt
bull Abhilfe Dependency Injection
bull Durch Modulprogrammierer Aumlnderungen betreffen haumlufig viele verstreute Codestellen anstatt nur ein Modul
bull Hilfreiche Technikenbull Module durch die
Identifikation von Geheimnissen bilden
bull anstatt durch die Identifikation von Zustaumlndigkeiten
bull Oft faumlllt beides ohnehin zusammen
bull Dokumentation angewoumlhnen Diese KlasseMethodehellip verbirgt [hellip] hellipknows how tohellip
18AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu viel)
bull Dieses Python-Programm hierbull print(chr(7))
bull koumlnnte man in folgende Module zerlegen (mit Blutgruppe)bull AsciiControlCodes (T)bull CharacterCreation (R)bull ChannelOutput (A)bull ChannelDirectory (T)bull ChannelCapabilityChecker
(T)bull Das genuumlgt stark dem
Geheimnisprinzip ist aber unsinnig
19AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Positivbeispiel (gelungen)
bull Python-Standardmodul emailbull verbirgt unzaumlhlige
Einzelheiten von fuumlnf verschiedenen MIME- und Email-Standards
bull Java-Standardmodul JapaneseChronologybull in javatimechronobull verbirgt die Regeln des
kaiserlichen japanischen Kalendersystems
bull jedenfalls die juumlngeren
20AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Information Hiding (IH)Negativbeispiel (zu wenig)
bull Wenn die Portierung einer SW auf eine andere Plattform schwierig ist wurde meist Wissen zu weit verstreut
bull Ein Paradebeispiel Portieren von 32 nach 64 bitbull Hauptproblem ist oft verstreutes Wissen (das jetzt unguumlltig wird)
uumlber die Groumlszlige der diversen int-Typenbull httpstackoverflowcomquestions3557877porting-linux-32-
bit-app-to-64-bit
21AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
22AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wasbull Automatisiere Tests die
jedes Modul separat gruumlndlich pruumlfen
bull Tests sollen schnell ablaufen
bull Tests sollen keine evtl unverfuumlgbaren Dienste benoumltigen
bull Debugging geht sehr schnell und Zutrauen zum Code ist hoch
bull Wofuumlrbull Evolvierbarkeitbull Korrektheit
bull Hinderungsgrundbull Gruumlndliche Tests machen
viel Arbeitbull Isolation von anderen
Modulen macht ggf zusaumltzlich Arbeit
bull und verlangt konsequente Einhaltung von DIP
23AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-Tests
bull Wirkungen von Verletzungenbull Angst vor Codeaumlnderungen
bull deshalb insbes zu wenig Aufraumlumen per Refactoring
bull Bei Versagen ist das Debugging oft aufwaumlndig
bull Hilfreiche Technikenbull Test-First-Entwicklung
bull insbes Test-Driven-Design (TDD)
bull Refactoringbull mit Ziel Testbarkeitbull [Legacy]
bull Einsatz von Testframeworksbull (bei kleinen Vorhaben geht
es auch ohne)
24AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-TestsNegativbeispiel (zu viel)
bull Unit-Testing uumlbertreiben heiszligtbull Es gibt viele
redundante Testsbull Niemand hat einen
guten Uumlberblickbull Es entsteht Scheu
vor semantischem Umbaubull weil man dafuumlr zu viele
Tests mit aumlndern muumlsste
bull Zweite Art Triviale Testsbull zB gettersetter in Java
bull Andere Artbull Man testet muumlhsamst Code
der schwierig zu testen ist anstatt ihn zu vereinfachen
bull Uumlberlegungen hierzuSanderson Selective Unit Testing ndash Costs andBenefits
25AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-TestsPositivbeispiel (gelungen)
Python-Standardbibliothekcalendar-Modulbull Libcalendarpy (700 LOC)bull Libtesttest_calendarpy
bull 700 LOCbull Hartkodiertes Testresultat
result_2004_days fuumlr test_yeardayscalendar
bull Einmal manuell pruumlfen dann einfrieren
bull Heuristische Pruumlfung fuumlr test_days
bull 7 Stuumlck Keine doppeltbull Namen kommen vom
Betriebssystembull diverse Python-Logik die
das kaputt machen koumlnnte
Python-Standardbibliothek datetime-Modulbull Libdatetimepy (2100 LOC)bull Libtesttest_datetimepy
bull Rahmen wg 2 Variantenbull technisch kompliziertbull dann alle Testfaumllle gleich
bull hellipdatetimetesterpybull 3800 LOCbull test_computations pruumlft
Zeitintervallarithmetikbull 48 asserts
bull tapfer bleibenbull Und nicht auf Leute houmlren
die verlangen Nur 1 assert pro Test
26AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Automatisierte Unit-TestsNegativbeispiel (zu wenig)
bull Java StandardbibliothekjavautilGregorianCalendarimplements Calendarbull GregorianCalendarjava
(3200 LOC)bull Calendarjava (2800 LOC)
bull (beide inkl viel Doku)bull 480 LOC netto allein fuumlr
add(field amount)
bull Tests zu beidem sind nurbull WeekDateTestjava
(190 LOC)bull 21+3+7 tabellengesteuerte
Testfaumllle 303 Plausib-Prfg zu 4 Themennur uumlber Wochenlogik
bull Bug6645263java (47 LOC)bull 1 Testfall (Exception)
bull Uumlbrigens alles ohne Testframework
bull Einziger Trostbull Eine Standardbibliothek
wird selten geaumlndert
27AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wasbull Benutze im Unittest von U
eine Attrappe K anstelle einer abhaumlngigen Klasse K wenn
bull K schwierig zu konfigurieren oder nicht immer verfuumlgbar ist
bull K zu langsam abliefebull Du Aufrufe pruumlfen moumlchtest
anstatt deren Resultatebull Verhaltenspruumlfung
(behavior verification) statt Ergebnispruumlfung (state-based verif)
bull K noch nicht existiertbull K selbst Defekte haben
koumlnnte
bull Wofuumlrbull Produktionseffizienz
bull Hinderungsgrundbull umstaumlndlichbull Verhaltenspruumlfung macht
den Test von U abhaumlngig von Us Implementierung
bull der Test teilt also Geheimnisse von UWhite-Box-Testen
28AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen
bull Dummybull Funktionsloses Objekt das
nur durchgereicht aber gar nicht aufgerufen wird
bull Stubbull Fixes Verhaltenbull meist hartkodiert
bull Fakebull Kann nicht alle Faumllle
behandelnbull stark vereinfachte echte
Loumlsung
bull Spybull Ein Testobjekt das Ablaumlufe
geeignet protokolliertbull Achtung Das fuumlhrt zu
White-Box-Testen
bull Mockbull Ein Spy oder Stub+Spy der
die Korrektheitspruumlfung gleich mit eingebaut hat
bull Im Jargon heiszligen Stubs Fakes Spies oft alle Mock
bull httpmartinfowlercomblikiTestDoublehtmlbull Relevanz f Prozess [MockStub]
bull httpblog8thlightcomuncle-bob20140514TheLittleMockerhtml
29AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
2
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Arten von Attrappen Namen
bull Wie uumlblich sind diese Namen aber nicht einheitlichbull Meszaros Mocks Fakes Stubs and Dummies bull Website zum Buch xUnit Test Patterns Refactoring Test Code
von Gerard Meszaros [xUTP]
30AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Testattrappen (test doubles)Isolation
bull Wirkungen von Verletzungenbull Debugging nach Versagen
ist aufwaumlndigbull wg Defekten in anderem
Codebull wg Crash in anderem
Code den der aber gar nicht verschuldet hat
bull Tests laufen langsambull Tests sind nicht robust
bull zB wg Abhaumlngigkeiten von externen Servern
bull Manche Dinge koumlnnen nicht oder kaum getestet werden
bull zB Zeitabhaumlngigesbull zB Ausnahmebehandlung
bull Hilfreiche Technikenbull Fuumlr Stubs
bull Duck typing(in dyn Sprachen)
bull Monkeypatching (dito)(siehe zB DHH blog)
bull Fuumlr SpiesMocksMocking-Frameworks
bull Java JMock EasyMock Mockito und andere
bull Python unittestmock und andere
31AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu viel)
bull Wenn ein Mockobjekt K ein anderes Mockobjekt L benutzt werden oft sogar Geheimnisse fremder Klassen L aufgebrochenbull Dann ist der Entwurf oder der Testentwurf unguumlnstigbull Wahrscheinlich sollte L ein Stub sein und in K eingebaut
komplexes Datenobjekt wird benoumltigt
32AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationPositivbeispiel (gelungen)
Python-Standardbibliothekbull Libtesttest_asynchatpy (asynchrones Socket-IO)
bull Testziel handle_read must ignore BlockingIOErrorbull Attrappe sock induziert Fehler (Zeile 282)bull Attrappe handle_error (Zeile 288) stellt seine Behandlung fest
bull (naumlmlich darf nicht aufgerufen werden Zeile 290)
33AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
TestattrappenIsolationNegativbeispiel (zu wenig)
bull
34AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wasbull Messe wie viel Anteil des
Codes durch Tests exerziert wird
bull Statements (C0)bull Verzweigungsziele (C1)
bull Wofuumlrbull Korrektheitbull Produktionseffizienz
bull Hinderungsgrundbull Messung ist evtl
kompliziert bei Code der verteilt oder in Containern ablaumluft
35AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-Analyse
bull Wirkungen von Verletzungenbull Viele redundante Testsundoderbull Viele Luumlcken in der
Testabdeckung
bull Nicht uumlbertreibenbull 90 C0 -Abdeckung sollte
man meist hinbekommen koumlnnen
bull und sind auch sinnvollbull aber 100 sind manchmal
unmoumlglich (bei C1 sogar oft) und oft uumlbertrieben teuer
bull Hilfreiche Werkzeugebull Java
Cobertura Emma uabull Python
coveragepybull auch als Plugin fuumlr nose
und pytest verfuumlgbar
36AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseBeispiel Cobertura-Bericht
bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder
37AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Code-Coverage-AnalyseNegativbeispiel (zu viel)
bull Coverage-Analyse darf sich nicht verselbstaumlndigenbull weder lohnt meistens der Aufwand
fuumlr die letzten paar Prozent Abdeckungbull noch besagt eine hohe Abdeckung
dass die Tests auch gut sindbull nur Assertions ergeben Tests
38AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wasbull Austausch mit immer
wieder anderen Entwicklern vermeidet nur im eigenen Saft zu schmoren
bull Team woumlchentlichbull Regional monatlichbull Uumlberregional jaumlhrlich
bull Wofuumlrbull Produktionseffizienz
bull ein Tipp faumlllt immer abbull Reflexion
bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und
uumlberregional auch Geld
39AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Teilnahme an Fachveranstaltungen
bull Wirkungen von Verletzungenbull Lesen ist gut aber manches
wird erst durch Diskussion klar
bull Und auch zum Lesen braucht man erst mal Anregungen und Motivation
bull Hilfreiche Anlaufpunktebull meetupcombull c-basebull Berlin Web Weekbull GOTO conferencebull und diverse andere
40AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wasbull Umstrukturierungen wie
bull Parameter zufuumlgenentfernen
bull KonstantenVariablen extrahieren
bull Klassen verschmelzenauftrennen
bull Verschieben zwischen Ober-Unterklassen
bull und viele mehr
bull Wofuumlrbull Evolvierbarkeit
bull Hinderungsgrundbull braucht gute
Werkzeugunterstuumltzungbull Hier sind dynamische
Sprachen schwaumlcher
41AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe Refaktorisierungen
bull Wirkung von Verletzungenbull Trotz emsiger Benutzung
von Methodenextraktion und Umbenennen wird der Entwurf allmaumlhlich immer schlechter
bull Architekturaumlnderungen (selbst kleinere) sind schmerzhaft
bull selbst wenn man automatisierte Tests hat
bull weil man auch die mit umstrukturieren muss
bull Hilfreiche Technikenbull Martin Fowlers
Katalog von Refactoringsbull Werkzeuge wie
Eclipse die JetBrains-IDEs MS Visual Studio
42AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Komplexe RefaktorisierungenPositivbeispiel (gelungen)
bull
43AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
Uumlbersicht
Prinzipienbull Interface Segregation Prin
(ISP)bull Dependency Inversion Prin
(DIP)bull Liskov Substitution Prin
(LSP)bull Principle of
Least Astonishment (LA)bull Information Hiding Prin
(IH)
Praktikenbull Automatisierte Unit Testsbull Testattrappen (Mock-ups)bull Code Coverage Analysebull Teilnahme an
Fachveranstaltungenbull Komplexe
Refaktorisierungen
44AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin
45
Thank you
AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin