Kolumne: Quality Time

Mist finden und bereinigen

Tobias Schlitt


Code Coverage spielt typischerweise beim automatisierten Testen eine Rolle: „Wie viel produktiver Code wird durch Tests abgedeckt?“, fragen sich Entwickler, Teamleiter und Manager, und meinen eigentlich „Wie gut ist unser Code getestet?“. Die Code Coverage ist aber völlig ungeeignet, diese Frage zu beantworten. Denn auch wenn eine bestimmte Codezeile ein- oder mehrfach in den Tests ausgeführt wird, bleiben viele Fragen unbeantwortet: „War der entsprechende Test sinnvoll? Hat er überprüft, dass die Codezeile das tut, was sie soll? Bei Bedingungen in Schleifen oder Verzweigungen: Welcher Teil war true/false, und welche Bestandteile wurden ggf. nicht getestet?“ Die Code Coverage als Gütekriterium für die Testabdeckung zu verwenden, ist also nicht sinnvoll.Wesentlich interessanter sind die Codezeilen, die nicht von Tests abgedeckt wurden. Das verrät uns die Code Coverage ebenfalls und gibt damit einen ersten Hinweis darauf, für welche Codebereiche noch Tests entwickelt werden sollten. Für diesen Zweck ist in Ausnahmefällen sogar eine Kombination der Code Cov­er­age mit Behat-Tests sinnvoll [2]. Aber bitte gehen Sie jetzt nicht gleich an Ihre Tests und versuchen, jeden Getter auch noch abzudecken. Denn das ist weder wirtschaftlich haltbar, noch macht es als Entwickler Spaß, solchen Code zu testen.Es stellt sich also die Frage, wie jene Codestellen herausgefiltert werden können, bei denen ein Test lohnenswert ist. Hier bietet der Change-Risk-Anti-Patterns-Index (CRAP-Index) einen guten Ansatz: Die Metrik kombiniert die Code-Coverage-Werte auf Methodenebene mit deren Codekomplexität (gemessen anhand der Cyclomatischen Komplexität [3]). Ohne Sie mit ausufernden Formeln zu langweilen, ist das Ergebnis wie folgt: Für komplexe Methoden, die nicht von Tests abgedeckt sind, explodiert der CRAP-Index exponentiell. Ist Code allerdings gut von Tests abgedeckt, so steigt der CRAP-Index nur gemächlich mit der Komplexität. Komplexer, aber gut getesteter Code ist entsprechend weniger schlimm. Ein hoher CRAP-Wert bedeutet also, dass der Code einer Methode entweder komplex aber nicht getestet ist, oder – bei hoher Testabdeckung – wirklich sehr komplex ist.Damit gibt Ihnen der CRAP-Index eine wesentlich bessere Grundlage zur Forschung nach dem nächsten Test- oder Refactoring-Opfer. Aber lassen Sie sich nicht hinters Licht führen: Auch der CRAP-Index ist nur eine Metrik und deren Ergebnisse müssen auf Basis von Erfahrung hinterfragt werden. Für die Analyse, welche Codebereiche...

Kolumne: Quality Time

Mist finden und bereinigen

Tobias Schlitt


Code Coverage spielt typischerweise beim automatisierten Testen eine Rolle: „Wie viel produktiver Code wird durch Tests abgedeckt?“, fragen sich Entwickler, Teamleiter und Manager, und meinen eigentlich „Wie gut ist unser Code getestet?“. Die Code Coverage ist aber völlig ungeeignet, diese Frage zu beantworten. Denn auch wenn eine bestimmte Codezeile ein- oder mehrfach in den Tests ausgeführt wird, bleiben viele Fragen unbeantwortet: „War der entsprechende Test sinnvoll? Hat er überprüft, dass die Codezeile das tut, was sie soll? Bei Bedingungen in Schleifen oder Verzweigungen: Welcher Teil war true/false, und welche Bestandteile wurden ggf. nicht getestet?“ Die Code Coverage als Gütekriterium für die Testabdeckung zu verwenden, ist also nicht sinnvoll.Wesentlich interessanter sind die Codezeilen, die nicht von Tests abgedeckt wurden. Das verrät uns die Code Coverage ebenfalls und gibt damit einen ersten Hinweis darauf, für welche Codebereiche noch Tests entwickelt werden sollten. Für diesen Zweck ist in Ausnahmefällen sogar eine Kombination der Code Cov­er­age mit Behat-Tests sinnvoll [2]. Aber bitte gehen Sie jetzt nicht gleich an Ihre Tests und versuchen, jeden Getter auch noch abzudecken. Denn das ist weder wirtschaftlich haltbar, noch macht es als Entwickler Spaß, solchen Code zu testen.Es stellt sich also die Frage, wie jene Codestellen herausgefiltert werden können, bei denen ein Test lohnenswert ist. Hier bietet der Change-Risk-Anti-Patterns-Index (CRAP-Index) einen guten Ansatz: Die Metrik kombiniert die Code-Coverage-Werte auf Methodenebene mit deren Codekomplexität (gemessen anhand der Cyclomatischen Komplexität [3]). Ohne Sie mit ausufernden Formeln zu langweilen, ist das Ergebnis wie folgt: Für komplexe Methoden, die nicht von Tests abgedeckt sind, explodiert der CRAP-Index exponentiell. Ist Code allerdings gut von Tests abgedeckt, so steigt der CRAP-Index nur gemächlich mit der Komplexität. Komplexer, aber gut getesteter Code ist entsprechend weniger schlimm. Ein hoher CRAP-Wert bedeutet also, dass der Code einer Methode entweder komplex aber nicht getestet ist, oder – bei hoher Testabdeckung – wirklich sehr komplex ist.Damit gibt Ihnen der CRAP-Index eine wesentlich bessere Grundlage zur Forschung nach dem nächsten Test- oder Refactoring-Opfer. Aber lassen Sie sich nicht hinters Licht führen: Auch der CRAP-Index ist nur eine Metrik und deren Ergebnisse müssen auf Basis von Erfahrung hinterfragt werden. Für die Analyse, welche Codebereiche...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang