1. Warum?
1.1. Fehlerlokalisierung
1.1.1. Kostensenkung
1.2. Dokumentation
1.3. Codequalität
1.4. Sicherheit/Feedback
1.4.1. Für Entwickler
1.4.1.1. Refactoring
1.4.2. Für Kunden
2. Fragen/Probleme
2.1. Sind meine Tests gute Tests?
2.1.1. Codeabdeckung
2.1.2. MutationTesting
2.1.2.1. Jester?
2.2. Welche Funktionalität muss getestet werden?
2.3. wie soll mit vorhandenem Code ohne Tests umgegangen werden?
2.4. Erhöhter Zeitaufwand bei der Entwicklung
3. alexa
3.1. Client Tests
3.1.1. Mock Server
3.2. Server Tests
3.2.1. Cactus
3.2.2. Mock Client
3.3. Testdatenbank
3.3.1. DB Flashback
3.3.2. Steuerung der Systemzeit (SYSDATE)
3.3.3. Kontrolle der Serveruhr
3.3.4. Erlaubt Mehrfachausführung von Integration- und Akzeptanztests
3.3.5. Poteniell größter Mehrwert
3.3.6. In Memory DB
3.3.7. laufen auf einer VM-Ware erschlägt die Zeit- und Flashbackprobleme (VM-Ware Snapshot)
3.3.7.1. Um eine Isolation der einzelnen Tests zu erreichen müsste nach jedem Test ein Flashback erfolgen - evtl. macht es aber Sinn einen Flashback erst dann auszuführen, wenn ein Test fehlschlägt und diesen einen Test nach dem Flashback erneut auszuführen.
3.3.7.2. Man könnte auf jedem Entwicklerrechner eine lokale VM-Ware laufen lassen.
4. Continuous Integration
4.1. Integration Server
4.2. Automatischer Build
4.2.1. Buildtools
4.2.1.1. ANT?
4.2.1.2. Maven?
4.2.2. Compilierung
4.2.3. automatische Tests
4.2.3.1. schnellste Tests zuerst
4.2.3.2. langsame Test ggf im Nightly Build
4.2.4. DB Integration (alterDB-Script)
4.2.5. Deployment
4.2.6. Dokumentation
4.2.6.1. JavaDoc
4.2.7. schneller Build für schnellen Feedback
4.2.7.1. Nightly Build
4.2.7.2. Feedback on Commit im aktuellen Entwicklungsprozess dank spätem Mergen nicht möglich
4.2.7.2.1. alexa Entwicklungsprozess: Macht es Sinn bereits beim Commit statt beim Build zu mergen?
4.2.7.3. schnell fehlschlagende Builds
4.3. Coding Style
4.4. Versionsverwaltung
4.4.1. Synergy?
4.4.1.1. Automatisches Mergen?
4.4.1.2. Erlaubt einen genaue Steuerung welcher RID auf welchem System landet -> Rollback eines RIDs möglich
4.5. prüft ob sich das System überhaupt bauen lässt
5. Granularität von Tests
5.1. Unittests
5.1.1. Vorteile
5.1.1.1. geringe Ausführungzeit
5.1.1.2. schnelle Fehlerlokalisierung
5.1.1.3. sofortiger Feedback
5.1.1.4. klein/kurz/schnell geschrieben
5.1.2. Probleme/Ziele
5.1.2.1. Schaffung der "heilen" Welt
5.1.2.1.1. Isolation
5.1.2.1.2. Stubs
5.1.2.1.3. Mockobjekte
5.1.2.1.4. "Gottklassen"
5.1.3. vom Entwickler geschrieben
5.1.4. können während des Builds ausgeführt werden
5.2. Modultests
5.2.1. Testet das Zusammenspiel einzelner Teilfunktionalitäten
5.3. Integrationstests
5.3.1. externe Abhängigkeiten
5.3.1.1. Datenbank
5.3.1.1.1. alexa Testdatenbank
5.3.1.2. hohe Ausführungzeit
5.3.1.3. Isolation schwierig
5.4. Akzeptanztests
5.4.1. Automatisierung schwierig
5.4.1.1. FIT/FITNESSE?
5.4.1.2. GUI Recorder?
5.4.2. von Konzeptern/Kunden entwickelt
5.4.3. fachliche Dokumentation
5.4.4. Implementierungsunabhängig
5.4.4.1. geringer Wartungsaufwand
5.5. grob- vs feingranulare Tests
5.5.1. Aufwand für Fehlerlokalisierung
5.5.2. potentielle Codeabdeckung
5.5.3. Aufwand/Schwierigkeit der Testisolierung
5.5.4. Ausführungszeit