Messen Sie die richtige Abdeckung

Ich habe festgestellt, dass viele Leute Wert auf eine hohe Testabdeckung legen. Sie sagt etwas darüber aus, wie gut Ihr Code getestet ist. Oder doch nicht?

Unit-Tests testen in der Regel den kleinsten Teil des Codes. Es ist eine ausgezeichnete Strategie, Ihre Tests in Verbindung mit dem Produktionscode zu schreiben. Die Tests helfen Ihnen bei der Gestaltung der Schnittstellen und bei der Erforschung des Problembereichs.

Die große Frage ist: Ist das dem Unternehmen/Produkteigentümer wichtig? Was sagen ihm (oder ihr) diese Tests über die tatsächlich gelieferte Funktionalität? Eigentlich recht wenig, wenn überhaupt. Daraus ergibt sich die nächste Frage: Warum sollte man sich dann um die Abdeckung der Unit-Tests kümmern?

Hier bietet es sich an, die Abdeckung Ihrer Akzeptanztests zu testen[1]. Akzeptanztests definieren eine Anforderung aus geschäftlicher Sicht, d.h. sie machen die tatsächlichen Anforderungen an das Produkt nutzbar.Bei der agilen Softwareentwicklung geht es um die Schaffung von Geschäftswert. Die Akzeptanztests repräsentieren den geschaffenen Geschäftswert.

Der Erfassungsgrad bei diesen Tests sagt Ihnen ein oder zwei Dinge. Es ist der Beweis für den Pudding. Wenn Ihr Abdeckungsgrad ziemlich niedrig ist, gibt es Bereiche der Anwendung, die von keinem Akzeptanztest abgedeckt werden. Bedeutet dies, dass es keine Anforderungen an diesen Code gibt? Oder gibt es einen Grund dafür, dass er nicht abgedeckt ist?

Möchte ich dafür plädieren, Unit-Tests ganz aufzugeben? Ganz bestimmt nicht. Wie ich bereits zu Beginn dieses Beitrags erklärt habe, sind Unit-Tests ein hervorragendes Mittel für die Entwicklung Ihres Codes. Konzentrieren Sie sich nur nicht auf die Abdeckung durch Unit-Tests: Verwenden Sie Unit-Tests, um die schwierigeren Teile des Codes zu konstruieren und zu testen. Nachdem der Code konstruiert ist und die Akzeptanztests grünes Licht geben, sollten Sie herausfinden, welche Unit-Tests von Wert sind (z.B. für die zukünftige Entwicklung oder Wartung) und den Rest loswerden.

Sie müssen Ihre Unit-Tests pflegen, genauso wie Sie es mit dem "Produktionscode" tun. Finden Sie heraus, welche Tests wichtig sind und welche nicht. Tests, die eng mit dem Code und der Struktur verbunden sind, sind möglicherweise nicht die besten Tests, die Sie beibehalten sollten. Sie müssen bei jeder Codeänderung oder Umstrukturierung geändert werden.

Denken Sie einfach daran, dass wir hier Geschäftsfunktionen (Werte) schaffen. Kümmern Sie sich darum. Messen Sie das. Lassen Sie die Details beiseite und messen Sie das, worauf es Ihrem Unternehmen ankommt: Funktionalität.

Abnahmetests sind Ihr stabiler Einstiegspunkt, um sicherzustellen, dass Änderungen das System nicht zerstören.