Ein gute Continuous Integration läuft weniger als 10min － etwa die Zeit, um einen neuen Kaffee zu holen. Diese Ansicht teilen die Entwickler:innen von Dolby mit vielen Kolleg:innen aus anderen Organisationen und Pionieren wie Martin Fowler. Die größte Herausforderung liegt dabei in der Laufzeit der (automatisierten) Tests. In vielen Projekten bei Dolby übersteigt diese bereits auf der niedrigsten Testebene alleine deutlich die 10min-Marke, weil die an sich schnellen Tests mit einer Vielzahl von Hardware-Optionen durchlaufen werden, wodurch die tatsächliche Anzahl ausgeführter Testfälle explodiert.
Ein Lösungsansatz ist, eine Teilmenge der Tests für schnelles Feedback direkt auszuführen und die übrigen Tests in nachgelagerte Test-Builds (z.B. nightly) auszulagern, die auch länger brauchen dürfen. Dieser Ansatz steht und fällt natürlich mit der Teilmenge, denn je nach Auswahl bleiben Teile des Software-Systems ungetestet. Was aber, wenn wir die Teilmenge abhängig von den konkreten Änderungen auswählen, die getestet werden sollen? Schließlich können neue Testfehlschläge ja nur von Änderungen verursacht werden. Die Test-Impact-Analyse verfolgt genau diese Idee. Sie ermöglicht es vollautomatisch diejenigen Tests zu bestimmen, die am wahrscheinlichsten Fehler in gegebenen Änderungen finden. So lassen sich rund 90% der Testfehlschläge in nur 2% der Testlaufzeit erkennen.
Lars Kempe (Dolby) und Sven Amann (CQSE) haben die Test-Impact-Analyse im letzten Jahr für C/C++-Systeme bei Dolby zum Einsatz gebracht. Hierzu konnten Sie die vorhandene Test-Impact-Analyse des CQSE-Werkzeugs Teamscale über einen simplen Plugin in die pytest-basierte Testautomatisierung bei Dolby integrieren. Anschließend haben sie gemessen, wie viel schneller die Continuous Integration dadurch wurde. Im Vortrag stellen die beiden die Grundlagen der Analysen und Datenerhebung vor, führen durch das technische Setup und sprechen über die Ergebnisse und ihre Erfahrungen.