Jacoco Testcoverage bei Abstracten Klassen in verschachtelten Modulen

[8u3631984]

Hallo zusammen ich habe mal wieder eine Frage zu Jacoco :
Ich habe ein Multi Modul Project in Gradle. In der main build.gradle File habe ich folgende Testcoverage Konfiguration :

...
        jacocoTestCoverageVerification {
        dependsOn test

        violationRules {
            rule {
                limit {
                    counter = 'METHOD'
                    minimum = 0.95
                }
                limit {
                    counter = 'LINE'
                    minimum = 0.95
                }
            }
        }

Nun habe ich ein commons Modul. In diesem existieren verschiedene Abstracte Klassen.
Diese werden aber nicht im common Modul implementiert sondern in einem andern.
Aber nun passiert eins :
Der Check der Testcoverage für das Common Modul schlägt fehl, da die Abstracten Klassen in den Common Tests noch nciht auftaucen. Diese werden ja erst in einem anderen Modul erzeugt und getestet.

Nun meine Frage gibt es für das Problem eine Lösung ?

 

[LimDul]

Schreib Tests für die abstrakten Klassen.
In den Tests gibt es eine Ableitung als Innerclass der abstrakten Klassen mit einer Dummy-Implementierung.

PS: Ich finde für die Praxis 95% deutlich zu hoch.

 

[LimDul]

Hier noch ein Artikel dazu: https://www.atlassian.com/continuous-delivery/software-testing/code-coverage - da stehen z.B. drin, dass 80% generell als gut angesehen werden. Für sich privat kann man natürlich sich auch mal höhere Ziel setzen - aber ob die wirklich zu besserem Code führen, ist fraglich.

 

[8u3631984]

Danke für die Antwort und den Hinweis.
Eine Default Implementierung, nur um die Abstrakte Klasse zu Testen finde ich nicht so glücklich.

 

[LimDul]

Die Implementierung existiert ja nur im Test. Ist ja nie im Produktiv-Code. Das ist ganz normaler Standard sowas zu machen. Wir haben bei uns zig TestXY Klassen die einfach Dummy-Implementierungen von abstrakten Klassen sind.

 

[8u3631984]

OKay das war mir nicht bewusst. Dann versuche ich den Weg einmal - vielen Dank für die Hilfe

 

[LimDul]

Beispiel (etwas gekürzt).

Das Interface hat Default-Methoden, der Test sieht dann wie folgt aus:

public class HasAddressTest {

    private TestHasAddress hasAddress = new TestHasAddress();

    @Test
    public void testUebernehmeAdresse_AdresseNichtNull() {
        hasAddress.setPartnerId("partnerId");
        hasAddress.setAddressId("addressId");
        Address address = new Address();
        address.setAddressId("neueAddressId");

        hasAddress.uebernehmeAdresse(address);

        assertThat(hasAddress.getAddressId(), is("neueAddressId"));
    }


    private class TestHasAddress implements HasAddress {

        private String partnerId;
        private String addressId;

        public TestHasAddress() {
            super();
        }

        @Override
        public String getPartnerId() {
            return partnerId;
        }

        @Override
        public void setPartnerId(String partnerId) {
            this.partnerId = partnerId;
        }

        @Override
        public String getAddressId() {
            return addressId;
        }

        @Override
        public void setAddressId(String addressId) {
            this.addressId = addressId;

        }

    }
    
}

Es wird eine Dummy-Klasse (die aus simplen Gettern & Settern besteht) im Test definiert, damit man die Default-Methode testen kann, die auf diese getter & setter zugreift.