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
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.