Hello Tibor,
I've played around a bit with the idea and I think there is a problem:
If you want to compile and run test using JUnit 4 annotations using JUnit
5, you need the vintage enigne in your dependencies. Otherwise you get
compile errors, because neither jupiter engine nor jupiter api ship the old
annotations. So I end up with a dependency declaration like this:
<dependencies>
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-engine</artifactId>
<version>${junit.jupiter.version}</version>
<scope>test</scope>
</dependency>
<!-- Needed because otherwise test won't compile because @Test is missing -->
<dependency>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
<version>${junit.vintage.version}</version>
<scope>test</scope>
</dependency>
</dependencies>
This will cause JUnit 5 to execute everything on the vintage engine. If we
want to share test code across JUnit versions, I need to also add the
jupiter API annotations to the test code. But I still need the vintage
engine in order to get it to compile.
Now I have a test like:
public class MixedTest
{
@org.junit.Test
@org.junit.api.jupiter.Test
public test()
{
// do something
}
}
Which engine will execute the test? No one knows... So I don't think it's a
good idea to share test classes.
Regards,
Benedikt
Benedikt Ritter <[email protected]> schrieb am So., 9. Okt. 2016 um
14:25 Uhr:
> Hello Tibor,
>
> I think I understand what you're thinking of. I'll give it a try and see
> if I can come up with something useful :-)
>
> Regards,
> Benedikt
>
>
> Tibor Digana <[email protected]> schrieb am Mi., 5. Okt. 2016
> um 00:18 Uhr:
>
> Instead of using <classpathDependencyExcludes/> in Surefire (may affect the
> ITs), there is a better trick.
> See the POM surefire-junit47.
> You will see the section of compiler endorsed classpath but Surefire has
> different one:
>
>
>
> <plugin>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <id>main</id>
> <phase>process-sources</phase>
> <goals>
> <goal>copy</goal>
> </goals>
> <configuration>
>
> <outputDirectory>${project.build.directory}/endorsed</outputDirectory>
> <overWriteIfNewer>false</overWriteIfNewer>
> <silent>true</silent>
> <artifactItems>
> <artifactItem>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>4.7</version>
> <type>jar</type>
> </artifactItem>
> </artifactItems>
> </configuration>
> </execution>
> <execution>
> <id>test</id>
> <phase>process-sources</phase>
> <goals>
> <goal>copy</goal>
> </goals>
> <configuration>
>
> <outputDirectory>${project.build.directory}/endorsed-test</outputDirectory>
> <overWriteIfNewer>false</overWriteIfNewer>
> <silent>true</silent>
> <artifactItems>
> <artifactItem>
> <groupId>junit</groupId>
> <artifactId>junit</artifactId>
> <version>4.12</version>
> <type>jar</type>
> </artifactItem>
> </artifactItems>
> </configuration>
> </execution>
> </executions>
> </plugin>
> <plugin>
> <artifactId>maven-compiler-plugin</artifactId>
> <configuration>
> <compilerArguments>
> <endorseddirs>${project.build.directory}/endorsed</endorseddirs>
> </compilerArguments>
> <testCompilerArguments>
> <endorseddirs>${project.build.directory}/endorsed-test</endorseddirs>
> </testCompilerArguments>
> </configuration>
> </plugin>
>
>
>
>
>
> On Tue, Oct 4, 2016 at 7:47 PM, Benedikt Ritter <[email protected]>
> wrote:
>
> > Hello Tibor,
> >
> > Tibor Digana <[email protected]> schrieb am Di., 4. Okt. 2016
> um
> > 02:29 Uhr:
> >
> > > Can you simplify and speed up writing integration tests in the way that
> > you
> > > would parameterize the existing JUnit 4 testing by adding Maven
> profiles
> > > (one default profile and junit5 profile) having another dependencies
> and
> > > @RunWith(Parameterized.class)?
> > > This would be cool because we can have identical assertion statements,
> > > means behavior, for multiple providers.
> > >
> >
> > I was already thinking about this, because right now I'm duplicating a
> lot
> > of the code from the ITs. This is definitely a good idea. But right know
> I
> > don't have a clear view of how we could implement that. Do we just share
> > the test class and work with separate test projects? Or do we want to
> even
> > share the test projects and work with profiles in the test project pom?
> >
> > JUnit 5 also has support for running legacy tests (they call it
> "vintage").
> > To make a complete IT suite, we would have to run all the JUnit 4 tests
> > against the JUnit 5 vintage engine as well.
> >
> > Lot a work ahead :-)
> >
> > Regards,
> > Benedikt
> >
> >
> > >
> > > On Mon, Oct 3, 2016 at 7:38 PM, Benedikt Ritter <[email protected]>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > now that we have a separate branch for the JUnit 5 support in the
> > > surefire
> > > > repo, I'm asking myself how to much things forward. I've added some
> > > > additional IT implementations in my GitHub fork, but they all fail
> > > because
> > > > the 5.0.0-M2 release of junit-surefire-provider does not implement
> the
> > > > desired features.
> > > >
> > > > At this point I'm pretty much blocked: I can not pick up the latest
> > > changes
> > > > to the JUnit 5 provider, because the JUnit team has not released it.
> > The
> > > > JUnit team does not push the development of the provider further,
> since
> > > > they don't have integration tests...
> > > > Right now I think it would be best to start implementing a JUnit 5
> > > provider
> > > > ourself in the junit5 branch, so we can add the missing features and
> > have
> > > > it ready when JUnit 5 reaches GA.
> > > >
> > > > Thoughts?
> > > >
> > > > Benedikt
> > > >
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Tibor
> > >
> >
>
>
>
> --
> Cheers
> Tibor
>
>
