Stufe 3: Gelber Grad von CCD - inf.fu- · PDF fileLeast Astonishment (LA) ... Andere Art: • Man testet mühsamst Code, der schwierig zu testen ist, anstatt ihn zu vereinfachen •

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

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

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

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

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)

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

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

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

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

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

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

Liskov Substitution Principle (LSP)Positivbeispiel (gelungen)

bull javautilIteratorbull remove() sagt ausdruumlcklich

dass nicht jede Implementierung das erlaubt

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 Hinderungsgrundbull Fuumlhrt zu langen Namen

oderbull verlangt kurze Klassen und

vor allem Methoden

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

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)

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

bull Hinderungsgrundbull Faulheitbull Mangel an Reflektion

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

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

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

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

Uumlbersicht

Refaktorisierungen

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 Hinderungsgrundbull Gruumlndliche Tests machen

viel Arbeitbull Isolation von anderen

Modulen macht ggf zusaumltzlich Arbeit

bull und verlangt konsequente Einhaltung von DIP

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)

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

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

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

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

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

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]

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

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

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)

TestattrappenIsolationNegativbeispiel (zu wenig)

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

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

Code-Coverage-AnalyseBeispiel Cobertura-Bericht

bull httpmojocodehausorgcobertura-maven-pluginsample-maven-shared-io-reportindexhtmlbull siehe Uumlbersichtbull orgapachemavensharediologgingbull DefaultMessageHolder

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

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 ein Tipp faumlllt immer abbull Reflexion

bull Hinderungsgrundbull Scham Schuumlchternheitbull Uumlbergroszlige Introversionbull Kostet Zeit und

uumlberregional auch Geld

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

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

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

Komplexe RefaktorisierungenPositivbeispiel (gelungen)

Uumlbersicht

Refaktorisierungen

Thank you

AG Software Engineering Institut fuumlr Informatik Freie Universitaumlt Berlin

Uumlbersicht

Information Hiding (IH Geheimnisprinzip)

Uumlbersicht

Thank you

Uumlbersicht

Refaktorisierungen

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

vor allem Methoden

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bit-app-to-64-bit

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Uumlbersicht

Refaktorisierungen

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

es auch ohne)

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

add(field amount)

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

koumlnnte

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Loumlsung

White-Box-Testen

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Testabdeckung

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

bull und viele mehr

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Uumlbersicht

Refaktorisierungen

Thank you

Uumlbersicht

Thank you

Uumlbersicht

Thank you

Documents

Stufe 3: Gelber Grad von CCD - inf.fu- · PDF fileLeast Astonishment (LA) ... Andere Art: • Man testet mühsamst Code, der schwierig zu testen ist, anstatt ihn zu vereinfachen •