Java >> Java tutorial >  >> Tag >> JUnit

Reparation af NoSuchMethodError JUnit-fejlen

JUnit

1. Oversigt

I denne artikel skal vi lære at rette op på NoSuchMethodError og NoClassDefFoundError JUnit fejl . Sådanne problemer opstår normalt, når vi har to forskellige JUnit-versioner i vores classpath . Denne situation kan for eksempel opstå, når projektets JUnit-version er forskellig fra den, der bruges i en Maven- eller Gradle-afhængighed.

2. JUnits NoClassDefFoundError i et forårsprojekt

Lad os sige, at vi har et Maven-projekt, der bruger Spring Boot 2.1.2 og Spring Boot Starter Test-afhængigheden. Med en sådan afhængighed kan vi skrive og køre automatiserede test ved hjælp af JUnit 5.3.2, som er JUnit-versionen af ​​spring-boot-testen afhængighed.

Antag nu, at vi fortsætter med at bruge Spring Boot 2.1.2. Vi ønsker dog at bruge JUnit 5.7.1. En mulig tilgang ville være inklusion af junit-jupiter-api , junit-jupiter-params , junit-jupiter-motor , og junit-platform-launcher afhængigheder i vores pom.xml fil:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>5.7.1</version>
    <scope>test</scope>
</dependency>
...

Ikke desto mindre får vi i dette tilfælde en NoClassDefFoundError når vi kører vores test:

[ERROR] java.lang.NoClassDefFoundError: org/junit/platform/commons/util/ClassNamePatternFilterUtils

I stedet for NoClassDefFoundError , en NoSuchMethodError vil ske, hvis vi migrerer til JUnit 5.4.0.

3. Forståelse og udbedring af fejlen

Som illustreret i det foregående afsnit endte vi med en NoClassDefFoundError da vi forsøgte at migrere vores JUnit-version fra 5.3.2 til 5.7.1.

Fejlen opstod, fordi vores klassesti endte med at have to forskellige versioner af JUnit . Derfor blev vores projekt kompileret med en nyere version af JUnit (5.7.1), men fandt en ældre version (5.3.2) under kørsel. Som et resultat forsøgte JUnit-starteren at bruge en klasse, der ikke er tilgængelig i den ældre version af JUnit.

Dernæst skal vi lære forskellige løsninger til at rette denne fejl.

3.1. Tilsidesættelse af JUnit-versionen af ​​Spring

En effektiv tilgang til at rette fejlen i vores eksempel er at tilsidesætte JUnit-versionen administreret af Spring:

<properties>
    <junit-jupiter.version>5.7.1</junit-jupiter.version>
</properties>

Nu kan vi også erstatte vores JUnit-afhængigheder med følgende:

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter</artifactId>
</dependency>

Denne enkelte afhængighed vil omfatte junit-jupiter-api , junit-jupiter-params , og junit-jupiter-motor . junit-platform-launcher afhængighed er normalt kun nødvendig, når vi skal køre vores JUnit-tests programmatisk.

På samme måde kan vi også tilsidesætte den administrerede version i et Gradle-projekt :

ext['junit-jupiter.version'] = '5.7.1'

3.2. Løsning til ethvert projekt

I det forrige afsnit lærte vi, hvordan man fikser NoSuchMethodError og NoClassDefFoundError JUnit-fejl i et forårsprojekt, som er det mest almindelige scenarie. Men hvis disse fejl sker, og vores projekt ikke bruger Spring, kan vi prøve at rette kollisionen af ​​afhængigheder i Maven .

I lighed med hvad der skete i vores eksempel med Spring, kan et projekt have flere versioner af JUnit på grund af transitive afhængigheder . For et sådant scenarie har vi en detaljeret vejledning om, hvordan man løser kollisionerne i Maven.

4. Konklusion

I dette selvstudie har vi reproduceret og lært, hvordan vi løser NoSuchMethodError og NoClassDefFoundError JUnit fejl. Kodestykkerne kan som altid findes på GitHub. Bemærk venligst, at i dette kildekodeeksempel tilsidesætter vi JUnit-versionen i pom.xml fil af moderprojektet.


Java tag