Doorgaan naar hoofdcontent

Junit 5 never runs in maven

We've had it so, so often.

Junit 5 is a bitch to run in maven. First there were issues with the surefire plugin. Make sure that is updated.

Then there were issues with the versions you need to use together.

Whelp, that was all set up right. And of course... still no junit 5


A fun thing was seeing this:


[INFO] --- maven-surefire-plugin:3.1.2:test (default-test) @ my-project ---
[INFO] Using auto detected provider org.apache.maven.surefire.junit4.JUnit4Provider

 

Yeah, that's not how it should go. This forces the junit 4 provider... Which is not the junit 5 generic one.
After a lot of digging, it turns out that surefire determines which provider to use... through some magic from the classpath. Of course, nowhere is there a junit4 dependency. They're all gone.

Well... Except...

Except...
The platform dependency

 

<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-launcher</artifactId>
<version>${platform.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.junit.platform</groupId>
<artifactId>junit-platform-runner</artifactId>
<version>${platform.version}</version>
<scope>test</scope>
</dependency>
That turned out to be the culprit. That was using an old version. And apparently, surefire triggers on that.
With that removed it gave:
[INFO] --- maven-surefire-plugin:3.1.2:test (default-test) @ sam-jar ---
[INFO] Using auto detected provider org.apache.maven.surefire.junitplatform.JUnitPlatformProvider
 
 And then, finally, it started running junit5 tests

And I could finally go to bed again. 

Reacties

Een reactie posten

Populaire posts van deze blog

Spring's conditional annotation with properties

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...
Een reactie posten
Meer lezen

Windows batch scripting god ( java runtime switch)

 I am a batch scripting god. After a lot of pain, I managed to create a script which allows me to switch jvm's easily. For posterity, and my own flex skills, the script: @echo off rem set your local path to all the JVM's here. set jvmdir=c:\code\apps\jvms if NOT EXIST %jvmdir% goto invaliddir rem a little bit of manipulation rem first we remove everything before the jvms dir call set __temp=%%path:*%jvmdir%\=%% rem then we determine everything that follows after the next slash set __lastbit=%__temp:*\=% rem then we remove that lastbit, leaving only the entire directory and a \ at the end. call set __currentpath=%%__temp:%__lastbit%=%% rem then we remove the \ at the end set __currentjvm=%__currentpath:\=% if "%~1"=="" goto missingarg if NOT EXIST %jvmdir%\%1 goto unknowndir set __currentpath=%jvmdir%\%__currentjvm% set __replacement=%jvmdir%\%1 call SET path=%%path:%__currentpath%=%__replacement%%% CALL SET JAVA_HOME=%%JAVA_HOME:%__currentpath%=%__replacemen...
Een reactie posten
Meer lezen

Using spring's @transactional to only roll back when you really want to

In spring you can use the @Transactional annotation to marcate public methods as transactions. Any exception thrown in such an exception causes a rollback... Any exception? No, spring only does so on runtime exceptions. Checked exceptions are allowed and do not result in a rollback. And even then, you can allow some transactions to rollback, or not, with the proper properties for the transactions. For examle, @Transactional(rollbackFor="MyCheckedException.class") will rollback for a specific checked exception, and similarly, you can use @Transactional(noRollbackFor="MyUncheckedException.class") for unchecked exceptions. Of course, you might want to make it a little simpler on yourself. This article on stackoverflow shows us a different way: we can use our own transaction handler by overriding spring's. Let's have a sample interface which defines whether an exception should perform a rollback: interface ConfigurableRollback shouldRollbackOnE...
Een reactie posten
Meer lezen