Die Tragödie von 100 % Codeabdeckung

Es ist komisch, wie sich die Dinge drehen. Seit fünfzehn Jahren predige ich TDD (Test-Driven Development, oder wie es früher hieß: Test-First-Ansatz), oder zumindest für Entwickler, einige Unit-Tests zu schreiben. In letzter Zeit sage ich jedoch häufiger: “Warum haben Sie diesen Test geschrieben?” statt “Du solltest einen Test schreiben.”

Was ist los?

Als ich im Büro umherging, wurde ich von einem Entwickler gebeten, ihm bei einigen Unit-Tests zu helfen. Es scheint, dass er Probleme hatte, Mockito zu verwenden, um den folgenden Code zu testen:

Ich glaube, er war sehr überrascht von meiner Antwort: “Das brauchen Sie nicht zu testen.”

“Aber ich muss!” er sagte. “Woher weiß ich dann, ob der Code funktioniert?!”

“Der Code ist offensichtlich. Es gibt keine Bedingungen, keine Schleifen, keine Transformationen, nichts. Der Code ist nur ein bisschen einfacher alter Klebecode.”

„Aber ohne Test kann jeder kommen, etwas ändern und den Code brechen!“

„Sehen Sie, wenn dieser imaginäre böse/ahnungslose Entwickler kommt und diesen einfachen Code bricht, was glauben Sie, was er tun wird, wenn ein zugehöriger Komponententest bricht? Er wird ihn einfach löschen.“

“Aber was wäre, wenn du den Test schreiben müsstest?”

“In diesem Fall würde ich es so testen:”

“Aber du benutzt Mockito nicht!”

“Na und? Mockito hilft dir nicht. Ganz im Gegenteil: Es steht dir im Weg und es wird den Test weder lesbarer noch einfacher machen.”

„Aber wir haben uns entschieden, Mockito für alle Tests zu verwenden!“

Mir: “…”

Als ich ihn das nächste Mal traf, erklärte er stolz, dass er es geschafft hatte, den Test mit Mockito zu schreiben. Ich verstehe die mentale Befriedigung, es zum Laufen zu bringen, aber trotzdem machte es mich traurig.

Ein anderes Beispiel

Ich wurde von einem Entwickler angezogen, der ganz begeistert war von der hohen Codeabdeckung einer ihrer neuen Anwendungen und ihrer neu entdeckten Liebe zu BDD (Behaviour-Driven Design). Als wir uns im Code umsahen, fanden wir den folgenden Cucumber-Test:

Wenn Sie Cucumber schon einmal verwendet haben, werden Sie nicht überrascht sein, wie viel unterstützenden Code es benötigt:

Und das alles zum Testen:

Ja, eine einfache Kartensuche. Ich hatte genug Vertrauen in den Entwickler, um unverblümt zu sagen: „Das ist eine große Zeitverschwendung.“

„Aber mein Chef erwartet von mir, dass ich für alle Klassen einen Test schreibe“, antwortete er.

“Auf Kosten von?”

“Ausgaben?”

“Jedenfalls haben diese Tests nichts mit BDD zu tun.”

“Ich weiß, aber wir haben uns entschieden, Cucumber für alle Tests zu verwenden”​

Mir: “…”

Ich verstehe die mentale Befriedigung, die Werkzeuge deinem Willen zu beugen, aber trotzdem machte es mich traurig.

Wo ist die Tragödie?

Die Tragödie ist, dass zwei brillante Entwickler (beide würde ich zu einem nehmen Mannschaftsgespräch) verschwenden Zeit damit, diese Art von Tests zu schreiben, Tests, die sinnlos sind und die von zukünftigen Generationen von IG-Entwicklern gepflegt werden müssen.

Die Tragödie besteht darin, dass wir, anstatt das richtige Werkzeug für den Job zu verwenden, ohne besonderen Grund beschließen, uns immer wieder mit den falschen zu beschäftigen.

Die Tragödie besteht darin, dass wir, sobald eine „gute Praxis“ zum Mainstream geworden ist, scheinbar vergessen, wie sie entstanden ist, welche Vorteile sie hat und was am wichtigsten ist, wie hoch die Kosten ihrer Anwendung sind.

Stattdessen wenden wir es einfach mechanisch an, ohne zu viel darüber nachzudenken, was normalerweise bedeutet, dass wir am Ende bestenfalls mittelmäßige Ergebnisse erzielen, die meisten Vorteile verlieren, aber alle (oder sogar noch mehr) Kosten tragen. Meiner Erfahrung nach ist das Schreiben guter Unit-Tests harte Arbeit.

Lohnt es sich also, eine 100-prozentige Codeabdeckung anzustreben?

Ja, alle sollen es schaffen … in einem Projekt. Ich bin der Meinung, dass man bis zum Äußersten gehen muss, um zu wissen, wo die Grenze liegt.

Wir haben bereits viel Erfahrung mit einem Extrem: Projekte mit 0 Unit-Tests, also kennen wir den Schmerz, an diesen zu arbeiten. Was uns normalerweise fehlt, ist die Erfahrung im anderen Extrem: Projekte, bei denen eine 100%ige Codeabdeckung durchgesetzt wird und alles TDD ist. Unit-Tests (insbesondere der Test-First-Ansatz) sind eine sehr gute Praxis, aber wir sollten lernen, welche Tests nützlich und welche kontraproduktiv sind.

Aber denken Sie daran, nichts ist kostenlos, nichts ist eine Wunderwaffe. Halten Sie inne und denken Sie nach.

Similar Posts

Leave a Reply

Your email address will not be published.