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
  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.
  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!
  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
  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
  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
  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)‏
  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
  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!
  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
  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.
  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!
  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)
  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.