Automatische Tests -- die Hausratversicherung des kleinen Entwicklers

Eine Motivation, warum Testen wichtig ist.

Transcript

1. Dr. Holger Schauer
   April 2009
   Automatische Tests – die
   Hausratversicherung des kleinen
   Entwicklers
   

   View Slide

2. Mama, ich hab' Angst!
    Leben heißt Veränderung.
    Veränderungen sind riskant.
    Wer kein Risiko eingeht, kommt nicht vorwärts.
    Geänderte Rahmenbedingungen
   ▪ Kundenerwartungen, Konkurrenz
    ... erfordern Reaktionen und Anpassungen.
   ▪ Also Veränderungen ...
   ▪ ... die Risiken mit sich bringen.
    Keine Panik! Aber nimm' ein Handtuch mit.
   

   View Slide

3. Hurrah, die Schule brennt!
    Angenommen, es brennt in einer Schule. Was tun?
    mit dem Feuerlöscher löschen
    die Feuerwehr rufen
    Kinder und Lehrer evakuieren
    nach dem Brand Schaden reparieren
    Vorleistungen:
    Feuerlöscher kaufen, aufhängen und kontrollieren
    Nummer der Feuerwehr verfügbar machen
    Evakuierung üben
    Versicherung abschließen
    Noch besser: möglichst wenig brennbare Materialien
    Risikominimierung plus Risikoplanung!
   

   View Slide

4. Versicherungen für jedermann
    Eine Versicherung abzuschließen kostet Geld.
    Wenn man die Versicherung nie braucht, erscheinen die Kosten
   unnütz.
    Eine Versicherung schafft Sicherheit, dass man im Schadensfall
   nicht aufgeschmissen ist.
    Jeder weiß, dass man ein paar Versicherungen braucht.
    Warum eigentlich?
    Weil es eine triviale Erkenntnis ist,
   dass nicht immer alles gut geht.
    (Teil eines) Risikomanagement
   

   View Slide

5. Änderungen im Entwickleralltag
    Risiken im Entwickleralltag: Änderungen (Software und mehr)‏
    Aber: Nichts ist so sicher wie der Wandel.
    Ursachen für Änderungen:
    neue Anforderungen, neue Features.
    Bugs, Refactoring.
    Veränderungen/Migration externer Einflüsse (Systeme).
    personelle Änderungen, neue Kollegen.
    negative Auswirkungen von Änderungen:
    Technik: Einführung von Fehlfunktionen
    Organisation: Veränderungen
    soziale Ebene:
   ▪ eigene Ängste (desjenigen, der die Änderungen macht)‏
   ▪ Verunsicherung von Kollegen
   ▪ Auswirkungen auf Dritte/Externe/Kunden
   

   View Slide

6. Risikominderung in der Entwicklung
    Ausschluss von Risiko: Never touch a running system
    ... and grind the world to a halt.
    Verifikation:
    ... wait 'till hell freezes over.
    Tests:
    Kein Beweis der Fehlerfreiheit
    Unterschiedliche Arten:
   ▪ Externes Testen (QS)‏
   ▪ Internes Testen (Entwickler)‏
   ▪ Manuelles Testen
   ▪ Automatisiertes Testen
   

   View Slide

7. Selbst ist der Mann/die Frau!
    Warum externes, funktionales Testen nicht reicht:
    Ziel ist Verminderung von negativen Auswirkungen auf Dritte.
    Anwendersicht, ist keine HILFE bei Entwicklungsarbeit.
    (technische, interne) Edgecases werden oft nicht abgedeckt.
    Ergebnisse kommen im Entwicklungsprozess (zu) spät.
    Warum internes Testen jeder Entwickler machen sollte:
    um eigenes Vertrauen in Änderungen zu erhöhen,
    zur Unterstützung von Kollegen,
    zur Qualitätssicherung,
    können zu besser strukturiertem Code führen,
    sind Vorwegnahme von Wartungsarbeiten (Risikominderung)‏
   .
    Nutzen wiegt Kosten bei weitem auf (-> Hausratversicherung)‏
   

   View Slide

8. Ein bisschen Terminologie
    Unittests: Testen von Code ohne Abhängigkeiten
    Integrationstests: Testen von Code mit anderem
   Code
    Funktionale Tests: Integrationstests, die testen, ob
   der Code funktionale und nicht funktionale
   Anforderungen erfüllt.
    TDD: Test driven development (auch Design)‏
    POUT: Plain old unit tests
    DDT: Defect driven tests
    GUT: Good unit tests
    SUT/CUT: Source/Code under test
   

   View Slide

9. Good (unit) tests
    Tests are code: alle Anforderungen, die man an guten Code
   stellen würde, kann man auch an Tests stellen.
    Gute Benennung
    Dokumentation
    Isolierung
    Modularisierung
    F.I.R.S.T. (Robert C. Martin, „Code clean“):
    Fast: Tests should be fast.
    Independent: Tests shouldn't depend on each other.
    Repeatable: Tests should be repeatable in any environment.
    Self-Validating: Tests either pass or fail.
    Timely: Tests should be written timely.
    Entscheidener Punkt: schnelle
   Ausführbarkeit/Überprüfbarkeit!
   

   View Slide

10. xUnit Test Patterns: Goals and
    Principles
     Fully automated
     Self-checking
     Repeatable test
     Robust test
     Simple test
     Expressive test
     Separation of concerns
     Do no harm
    Gerard Meszaros, xUnit Test
    Patterns, Addison-Wesley.
     Write tests first
     Isolate source under test
     Don't modify source under test
     Minimize test overlap
     Communicate intent
     Use the front-door first
     Verify one condition per test
     Test concerns separately
     Keep tests independently
     Minimize untestable code
     Keep test logic out of
    production
     Ensure commensurate effort
    and responsibility
    

    View Slide

11. Qualitätsverbesserung
     Nachdenken darüber, wie man ein Stück SUT überhaupt
    testen kann, hilft oft, Probleme im Code festzustellen.
     Vorgaben wie „Minimize test overlap“, „verify one condition
    per test“, „test concerns separately“ passen zu Code, der
    „wenig“ macht (u.a. single responsibility principle).
     Wenn SUT mit mehreren Objekten/Funktionen interagiert, die
    nicht getestet werden sollen (unit tests!), werden Mocks/Stubs
    gebraucht ~ Dependency Injection/Abstract Factory
    verwenden.
     Mehr, aber kleinere Klassen/Funktionen, mehr Abstraktionen,
    lose Kopplung und fokussierte (Unit-)Tests bedingen einander!
     TDD: Vorher Nachdenken darüber, wie mit dem Code
    interagiert werden soll. Vermeidet große Codeblöcke, die zu
    viel machen und daher schwer zu testen sind.
    

    View Slide

12. Projektbetrachtung
     Maßnahmen für Risikomanagement müssen eingeplant
    werden
     Kosten sichtbar machen
     Erfahrungen machen diese Kosten kalkulierbar
     Wartung:
     Defect driven tests verwenden
     Managementaufgabe: Umgang mit Tests im Projekt
     Entscheidung: TDD vs. POUT
     Checkin-Policy festlegen
     erforderliche Coverage festlegen
     soziale Komponente/Teamauswirkung dieser Entscheidungen
    unbedingt berücksichtigen!
    

    View Slide

13. Langfristige Benefits
     Änderungen vor gesichertem Hintergrund (known good state)‏
     Verändertes Klima: weniger Unsicherheit („Was könnte ich
    alles kaputtmachen“), denn Auswirkungen von Änderungen
    sind sofort absehbar.
     Verringerung von Projektrisiken
     Führt zu größerer Beweglichkeit
     Aggressiveres Deployment
     Flickr deployed alle 30 Minuten, live!
     Das erfordert eine MENGE an Tests.
     Unit-, Integrations- und Funktionstests, alles automatisiert.
     Stichwort: Continuous Integration (M.Fowler)
    

    View Slide

14. Famous last words
     Fakt: Ignaz Semmelweis hat 1847 erklärt, warum sich
    Ärzte die Hände waschen sollten vor/nach Kontakt mit
    Patienten.
    Einhellige Reaktion: Dafür haben Doktoren keine Zeit.
     Angel: People who don’t care about anything will never
    understand the people who do.
     Marcus Hamilton: Yeah, but we won’t care.
    

    View Slide