In den letzten 10 Monaten haben die Entwickler von edX hart daran gearbeitet, die Abdeckung automatisierter Tests zu erhöhen. Unsere 2,491 Python-Einheitentests decken derzeit 87 % der Zeilen im edx-platform-Repo ab. Diese Tests werden zusammen mit unseren Selenium-Akzeptanztests und JavaScript-Komponententests bei jeder Pull-Anforderung ausgeführt, sodass wir vorgeschlagene Codeänderungen schnell validieren können.
Wie haben wir die Testabdeckung in nur 50 Monaten von weniger als 87 % auf 10 % erhöht? Ein Teil der Antwort ist ein Tool namens Diff-Abdeckung.
In einem typischen Arbeitsablauf stellt ein Entwickler, der an einem großen Projekt arbeitet, möglicherweise eine Pull-Anforderung, die ein paar Dutzend Codezeilen ändert. Vor der Änderung lag die Testabdeckung möglicherweise bei 72 %; danach könnten es immer noch 72 % sein. Die Größe des Projekts macht es schwierig, die Wirkung eines einzelnen Pull-Requests zu erkennen. Mit Diff-Cover können Sie sich auf die Qualitätsmetriken eines einzelnen Pull-Requests konzentrieren, anstatt auf das Projekt als Ganzes.
Diff-Cover misst Codezeilen in einem Git-Diff. Bei einer vorgeschlagenen Änderung des Codes wird Ihnen angezeigt, welche der geänderten Zeilen nicht abgedeckt sind. Dies ist eine einfache Idee, aber sie hat starke Auswirkungen:
- Für Entwickler bietet diff-cover eine klare und erreichbare Metrik: Wenn Sie eine Codezeile berühren, sollte sie abgedeckt werden.
- Für Codeprüfer erleichtert diff-cover die Überprüfung, ob Entwickler Tests für alle Codeänderungen schreiben.
Indem sie sich auf die Diff-Abdeckung konzentrieren, können Entwickler kleine, sichtbare Schritte zur Verbesserung der globalen Abdeckung machen. Ein bestimmtes Commit kann zunehmen globale Abdeckung nur um einen Bruchteil eines Prozents, aber immer noch 95 % diff Abdeckung. Als die Entwickler Tests für ihre Codeänderungen schrieben, begann die globale Abdeckung langsam aber sicher ebenfalls zuzunehmen. Infolgedessen konnten wir bestimmte Arten von Fehlern früher erkennen.
Noch wichtiger ist, dass andere Entwickler begannen, sich an diff-cover selbst zu beteiligen und das Tool in Besitz zu nehmen. Beispielsweise hat Cale das Tool verallgemeinert, um zusätzliche „Qualitätsprüfungen“ zu unterstützen, und Sarina hat es erweitert, um pep8- und Pylint-Verstöße in einem Diff zu melden. Viele andere Entwickler haben während eines ersten Betatests von diff-cover Feedback und Vorschläge gegeben. Das Tool wurde zum Ausgangspunkt für eine erneute Überprüfung unserer Codeüberprüfungs- und Teststandards, was zu einer echten Veränderung unserer Testkultur führte.
Natürlich hat die Reichweitenmessung immer noch einige wichtige Einschränkungen. Insbesondere eine hohe Diff-Abdeckung tut es kein Frontalunterricht. Fehlerfreien Code garantieren: In einem eng gekoppelten System könnte eine Änderung an einer Komponente weitreichende und unbeabsichtigte Folgen für andere Teile des Systems haben – selbst wenn der geänderte Code zu 100 % abgedeckt ist. In solchen Fällen können Integrationstests Fehler finden, die Einheitentests möglicherweise übersehen.
Wenn Sie der Meinung sind, dass diff-cover für Sie nützlich sein könnte, sehen Sie sich das Projekt an – es ist Open Source und verfügbar auf GitHub. Der Code ist so konzipiert, dass er auf andere Versionskontrollsysteme und Qualitätsprüfer erweiterbar ist, also zögern Sie nicht, Funktionen hinzuzufügen und eine Pull-Anfrage zu stellen!
Will Daly ist Testingenieur bei edX. Wenn er nicht gerade testgetriebene Entwicklung befürwortet oder einen Jenkins-Cluster optimiert, rennt er gerne entlang von Flüssen und minimiert die Anzahl der Dinge in seiner Wohnung.
