Ist diese Jacoco Testcoverage Konfiguration sinnvoll

[8u3631984]

Hallo ich habe in meinem folgende Testcoverage Konfiguration angeleget :

tasks.jacocoTestCoverageVerification {
    dependsOn(tasks.test)

    violationRules {
        rule {
            limit {
                counter = "CLASS"
                value = "COVEREDRATIO"
                minimum = "0.9".toBigDecimal()
            }
        }

        rule{
            element="CLASS"
            limit {
                counter = "LINE"
                value = "COVEREDRATIO"
                minimum = "0.9".toBigDecimal()
            }
        }

        rule{
            element="METHOD"
            limit {
                counter = "LINE"
                value = "TOTALCOUNT"
                minimum = "1.0".toBigDecimal()
            } 
        }

nach meinem Verständnis müssen 90% aller Klassen durchlaufen sein. in den Klassen müssen dann 90% aller zeilen erreicht worden sein. Und in jeder Funktion müssen alle Zeilen besucht worden sein.

Nun meine Frage : Ist diese Konfigurataion sinnvoll - oder wie messt ihr eure Testabdeckung ?

 

[LimDul]

Meines Erachtens viel zu hoch. Es gibt immer Zeilen, die man im Code nicht erreichen kann. Und sei es eine default in einem Switch-Case was aktuell nicht auftreten kann, aber trotzdem zur Sicherheit drin ist. Seien es Exception-Handlings, auch wenn aktuell eine Exception gar nicht auftreten kann, seien es Sonderkonstellationen für die man 1 Woche braucht um einen Unit Test zu schreiben oder die man in einer Stunde direkt in der Anwendung testen kann. UI Code den man nicht testen kann.

Insbesondere bei einer bestehenden Anwendung, die nicht von vornerein so gebaut wurde, nicht erreichbar.

Siehe z.B. hier

For test-driven development, you need to aim for 100%. Hitting 100% in a large code base can be a pipe dream, but your emphasis should be on improvement.

When it comes to those large projects, increasing coverage above 70-80% is time consuming, and you need to assess the costs and benefits. For higher risk systems, higher coverage is needed.

Who Cares About Code Coverage and Why? - Codecov

Code coverage is a simple metric to measure the effectiveness of your tests; increasing it helps you spot problems. That gives teams confidence in their tests, and increases the quality ...

about.codecov.io

Das man das als Ziel hat die Zahlen ist ok - aber als Regel halte ich für größere Projekte für unrealistisch.

 

[mrBrown]

Ich werf einfach mal Goodharts Law ein 🙃

 

[KonradN]

Also ich gehe da aus einem sehr praktischen Ansatz ran. Und da ist es dann sehr extrem: Manche Klassen Namespaces sind bei 100% oder sehr dicht dran und andere Klassen sind effektiv bei 0% (Coverage sagt da was anderes, weil da irgendwas bei anderen Unit Tests aufgerufen wurde. Aber die Klasse selbst hat dann ggf. nicht mal eine Test-Klasse).

Wie kann das so extrem sein? Und wie kann ich das vor mir selbst rechtfertigen?

Diese nicht getesten Klassen sind dann einfache Entities - Datenklassen ohne Logik.

Da habe ich dann in der Klasse etwas wie:

@Getter
@Setter
private String name;

Was soll ich da einen Test schreiben, der prüft, ob es einen Getter gibt, der name setzt und einen Setter, der die Variable zurück gibt? Das ist generierter Code und da gilt etwas: "Generierter Code wird nicht getestet".

Ist aber keine Schwarz-/Weiss- Malerei. Wenn es fachliche Anforderungen gibt, die über die reine Existenz hinaus geht, dann wird es interessant. Ggf. gibt es Anforderungen, die bei der generierten Methode erfült sind, die aber explizit wichtig sind. Die ggf. Probleme bereiten könnten, wenn man etwas anpasst.

Also den Getter / Setter von name werde ich nicht in einem eigenen Unit-Test testen. Aber evtl. ruft ein anderer Unit Test direkt oder indirekt einen Getter oder Setter auf und damit würde der dann auch grün.

Wenn ich eine Funktionalität schreibe, dann gibt es da aber kein Vertun: Das wird - so es möglich ist - direk getestet.

Die nächste Abweichung kommt dann nur bei der UI. Da wären dann UI Tests zu schreiben oder so - da gibt es dann also auch Abstriche.


Das einfach einmal als schnelle, ganz grobe Übersicht, wie ich oft vorgehe. Ohne Bewertung, ohne groß irgendwas zu argumentieren. Denn klar: Wenn es eine Anforderung gibt, dass eine Entity einen Namen hat, dann ist diese Anforoderung auch problemlos testbar. Das geht also.