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