ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <>
Subject Re: Ant support for users who use JUnit5
Date Thu, 14 Dec 2017 11:13:10 GMT
After sending this mail, the more I think of it, I am not too sure 
introducing a new task (junitlauncher) is serving any useful purpose. Of 
course it does allow me to keep the task implementation simpler without 
using the existing JUnitTask as an entry point of the call. But that is 
an internal implementation detail, now that I think of it. So perhaps 
just using the existing <junit> task and introducing relevant 
attribute(s) to support this JUnit 5 launcher might be a better idea. 
Even if we do stop supporting non-launcher based approach in some 
distant future, we could still do that just by changing the internal 
implementation detail of this task (and maybe removing support for 
certain attributes).

Either way, I would still like to hear others thoughts on this.


On 14/12/17 3:39 PM, Jaikiran Pai wrote:
> I've started some experiments in adding support for the recently 
> released JUnit5 [1] in Ant. I don't mean using JUnit5 for test cases 
> written within our Ant project, instead I am talking about allowing 
> users to use a Ant task to be able to run JUnit5 based test cases as 
> requested here [2].
> Before I get into the details of what I have tried so far, I would 
> like to quickly explain what JUnit5 brings for us (build tool 
> developers). As they note in their documentation, JUnit 5 has 
> introduced proper APIs targetted towards build tools and IDEs to be 
> able to launch tests, in a simple way. Furthermore, they have 
> separated out these APIs from the core of the tests itself. What that 
> means is, the JUnit platform launcher APIs, allow build tools to 
> launch the JUnit platform and then once launched, the ability to 
> "identify" tests that need to be run depends on the plugged in engine, 
> which is/can be controlled by the user's environment. So essentially 
> the launched platform can be used to run JUnit 5 test cases (written 
> using JUnit 5 test APIs) or can be used to run JUnit 4 test cases 
> (they call these vintage). This decision is done by a pluggable test 
> engine, typically placed within the classpath.
> With that context, I would like to explain what I have attempted so 
> far and I would like inputs on whether I should follow this path 
> and/or if there are other suggestions on how we should go ahead. As 
> you are probably aware, the JUnitTask (the Ant task backing the 
> <junit> element) has very complex logic which deals with launching the 
> test runners responsible for running JUnit tests (3.x or 4.x). IMO, 
> most this logic can now be handed off to the JUnit 5 platform 
> launcher, using their APIs.
> So one way to add JUnit 5 support would probably be to introduce a new 
> attribtue on the <junit> task, something like "use-junit-launcher" 
> which when set, will let us rely on this JUnit 5 launcher APIs. Of 
> course, we would also document that the usage of this attribute would 
> imply that they will have to setup their library dependencies to 
> include all relevant JUnit 5 related jars that provide this support, 
> plus the relevant JUnit test engine that suits their needs. This will 
> allow them to use the existing <junit> task and just add a new 
> attribtue to deal with JUnit5.
> The other approach is to introduce a new task (say <junitlauncher>) 
> which has the exact same support in terms of what attributes and 
> nested elements are supported but its implementation is completely 
> going to rely on the JUnit 5 platform launcher to deal with the test 
> execution. Practically, that means, all the existing complex code in 
> JUnitTask need no longer be used with this task and instead it will be 
> a much simpler implementation. Users who want "pure" junit 3.x or 4.x 
> can still stick to <junit> task, whereas users who want to use JUnit 5 
> based platform, either to run JUnit 4.x or 5.x can use this newer 
> <junitlauncher> task. Over time, in some release, we might probably 
> just advertise <junitlauncher> and deprecate <junit> (that's a long 
> way away of course, if we do indeed do that)
> In my experiment, I have implemented the latter approach to show its 
> usage. The code/commit resides here [3]. It by no means is complete, 
> but does currently support JUnit 5 (and JUnit 4) in its current form. 
> Before I actually spend more time on this approach, I would like 
> inputs and thoughts on it. The usage of this task would be something 
> like this (just a snippet from my experimental build.xml):
> <target name="test" depends="compile-tests">
>         <junitlauncher>
>             <!-- Multiple tests contained in the build.classes.dir-->
>             <batchtest>
>               <fileset dir="${build.classes.dir}"/>
>             </batchtest>
>             <!-- A specific test -->
>             <test name="org.myapp.FooTest"/>
>             <!-- classpath to be used for the tests -->
>             <classpath refid="test.classpath" />
>         </junitlauncher>
> </target>
> [1]
> [2]
> [3] 
> -Jaikiran

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message