One minor but important detail - this feature/task will only be
available in the 1.10.x releases (whichever release we decide to include
this in) and won't be available in 1.9.x releases of Ant.
-Jaikiran
On 27/01/18 8:40 AM, Jaikiran Pai wrote:
Here's an update on where this effort now stands. As of yesterday, I
have the basic minimal functionality that I had planned for this (new)
task ready. There are other enhancements that this task will need as
we go along but at this point, this should be usable.
While working on this new task, I kept thinking whether it would make
more sense to just have this task as a separate project under the Ant
umbrella and have its own release/versioning cycle. Plus maybe a bit
of ease in building/testing it given that it won't need some of the
conditional logic that we do in Ant build itself when it comes to such
tasks. It did look like a good idea to separate it out but ultimately
I decided _not_ to do it mainly for the reason that I think it makes
more sense to have a task in Ant which allows users to write tests
(using a modern test framework) and test them, right out of the box of
an Ant installation. This first class experience, IMO, outweighs all
the other "advantages" that seem to come with having this as a
separate project.
Coming to the task itself, the task is called "junitlauncher". In the
current state of this task[1], the following goals/features are
implemented and functional:
- Ability to launch the JUnit 5 platform
- Ability to specify a classpath to use for the launched tests
- Ability to specify one or more single test classes that need to be
run as part of this launch
- Ability to specify specific methods on these test classses that need
to be run as part of the launch
- Ability to specify "batch tests" which essentially is a way to use
Ant's resource collections to pattern match files that should be
passed on to the JUnit platform to be evaluated and run as test cases.
- Ability to specify "listeners" for tests. These listeners are
expected to implement (intentionally) JUnit platform's interface and
_not_ any of Ant's interfaces.
- Test result formatters are implemented as "listeners". This task
comes with 2 (for now) implementations out of the box, "plain" and
"brief". The idea behind these 2 is the same as that of what we
current have with the "junit" task formatters.
- Users can define custom formatters as "listeners" by specifying a
class which implements the JUnit's test listener plus (optionally) one
of Ant's own (new) custom interface. This custom interface will let
them have access to output stream to which they might want to write
out the results.
(I might be missing a few more details, but these are the major
functional features. The manual that I plan to write, will have the
whole details)
In its current state the task should be able to run both "vintage"
(JUnit 4.x) and "jupiter" (JUnit 5.x) based tests.
TODO/enhancements for later (a few days/weeks down the line):
- Ability to "fork" these tests in a separate JVM. I haven't fully
thought about this and might need some inputs on whether we need this
or not. If we do add this, I might do it slightly differently that
what we current do with "junit" where there are numerous attributes to
the task/test elements which are only applicable if fork mode is
enabled. I might perhaps just introduce a new element within the
task's element which specifically is meant to deal with any forked VM
characteristics. But that's something I will get to after the other
easier enhancements are done.
- Provide the XML formatter out of the box. I was planning to do this
in the first version itself, but I haven't had enough time to
understand the schema of this XML plus whether or not the details that
we put in here are available through the new JUnit launcher APIs.
- Ability to more specifically say which JUnit test engine needs to be
used for the tests. Right now, the classpath decides which engine gets
used and thus which classes are considered as tests. If the classpath
has both "vintage" and "jupiter" engines then such tests will be run.
However, I want users to be able to say "just use jupiter engine for
these tests" without having to worry about checking if the classpath
is polluted with some other engines.
- Make the current "junitreport" task be usable with the XML results
of this "junitlauncher" task. I haven't yet got to this but this
should be doable I think, of course once the XML formatter itself is
ready and functional. I don't plan to introduce a new task for this
and instead plan to reuse/enhance the existing junitreport task to
work seamlessly both with existing "junit" task and the
"junitlauncher" task.
(Few other minor enhancements here and there and any user feedback
reports)
For those of you curious to see what the task usage is going to look
like, here's an example[2] build file which shows its many usages.
That file will be cleaned up a bit, before I send a PR for review/merge.
[1] https://github.com/apache/ant/compare/master...jaikiran:junit5
[2]
https://github.com/apache/ant/compare/master...jaikiran:junit5#diff-3e0911ed925129e68c543aca0abc5d7aR52
-Jaikiran
On 14/12/17 5:14 PM, Stefan Bodewig wrote:
On 2017-12-14, Jaikiran Pai wrote:
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.
In addition some of the complexity inside of JUnitTask stems from the
fact that it must not refer to any JUnit 4.x API in order to be usable
in a pure JUnit 3.x environment. If you try to add JUnit 5 on top of
that this sounds diffciult.
I too had toyed with the idea of adding JUnit5 support but it is quite a
bit further down my TODO list and I've not looked into JUnit5 as deeply
as you did. What you've got so far looks promising, please please push
ahead.
My idea was to create a completely new task and mainly try to keep the
XML output the way it has been for some fifteen years so junitreport
would still work. I even though about placing it in a separate antlib
rather than Ant's core to allow it get released independently.
My vote would go to a separate task.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
