Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Automatische Tests -- die Hausratversicherung des kleinen Entwicklers

Automatische Tests -- die Hausratversicherung des kleinen Entwicklers

Eine Motivation, warum Testen wichtig ist.

schaueho

April 09, 2009
Tweet

More Decks by schaueho

Other Decks in Programming

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