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 <tibor.dig...@googlemail.com> 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 <brit...@apache.org>
> wrote:
>
> > Hello Tibor,
> >
> > Tibor Digana <tibor.dig...@googlemail.com> 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 <brit...@apache.org>
> > > 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
>

Reply via email to