I think I have reproduced what you described, @Graou74. The solution is that, when you import a JPMS-ified Gradle project for the very first time into Eclipse/Buildship, you must do one of these three things before you run a regular Eclipse JUnit test:
- Do
Run as a Gradle Testfirst - Execute the
:testor:checktask from the Gradle Task view first - Execute the
:eclipsetask from the Gradle Task view first
Like I’m doing in this recording…
The reason that is necessary is centered on what @st_oehme says here…
„…Buildship doesn’t use the module path, it uses the classpath. You’ll find all your dependencies in the “Project and External dependencies” container…“
You might be able to see at brief instances in the recording, Eclipse’s Java Build Path. First you see it before Eclipse Modulefication. Only the JDK’s built-in modules are on the module path.
Then you see the Java Build Path after Eclipse Modulefication. All the declared dependencies (except for test dependencies) are then on the module path. After that, Eclipse’s Run As JUnit Test worked as expected for me.
The job of the mrJar feature that I have dubbed Eclipse Modulefication is to add your declared dependencies to the module path. Because Buildship is brain dead in that department.
Without mrJar’s intervention, Buildship does not even know what a module path is. So, you gotta explicitly set it in one of the three ways listed above.
At some point, I will look into refactoring mrJar’s Eclipse Modulefication so that it is more or less automatic. Actually, I would have sworn that I had already solved that before believe it or not. But some very recent change has knocked it out of whack it looks like.
But as long as you don’t do a Gradle Refresh, manual Eclipse Modulefication should be a set-and-forget type deal.
By the way, @Graou74. This explanation is not intended to persuade you to return to the JPMS fold 
I just thought it might be informative as general usage guidance for other prospective users.