Hello Aleksei,
On 22/12/21 7:59 pm, Aleksei Zotov wrote:
Hi Ant Developers,
I'm working on the migration of Apache Cassandra project from JUnit 4 to
JUnit 5 (CASSANDRA-16630
<https://issues.apache.org/jira/browse/CASSANDRA-16630>) which turned out
to be larger than I originally expected. At the moment, three PRs got
merged:
- https://github.com/apache/ant/pull/147
- https://github.com/apache/ant/pull/168
- https://github.com/apache/ant/pull/172
And there are a few more I'd like to discuss with you.
Sorry, I remember seeing a PR from you where you asked for some inputs
in this area, but I haven't been able to get to it due to some other
priorities.
Formatters Extensibility
Apache Cassandra extended the existing JUnit 4 formatters in order to
integrate them with a custom logic required for a better CI process. It was
easily achievable for JUnit 4 since the formatters are marked public. On
the contrary, for JUnit 5 all formatters are package private. Even
*AbstractJUnitResultFormatter* is package private. Of course, we can
copy-paste all these classes to our project and customize them based on our
needs, but that seems to be a bit of an overhead.
Currently, we'd like to make *AbstractJUnitResultFormatter *extensible.
Here is the corresponding PR: https://github.com/apache/ant/pull/169/
The reason why these formatters are package private and not extensible
is intentional. When I added these formatters, one of the goals of these
formatters was to only make them generate output to an extent that it
matches the JUnit4 style formatters of the "junit" task (hence the name
"legacy-" to those formatters). All these pre-shipped "legacy-"
listeners that you see in Ant are only there for minimal support and
their implementation is considered to be internal to the Ant distribution.
The new JUnit5 framework itself is extensible and also comes with some
pre-shipped "listeners" (implementations of TestExecutionListener).
That's one of the reasons why the junitlauncher task's "listener"
element provides a direct way to use any implementation of the JUnit5
framework's "org.junit.platform.launcher.TestExecutionListener". i.e.
for any code that seeks extensibility, the
org.junit.platform.launcher.TestExecutionListener is expected to be the
extension point/interface and not Ant's internal
AbstractJUnitResultFormatter. This allows the junitlauncher task to be
minimal and allows it to achieve its goal of just being something that
will launch the JUnit5 framework.
I can understand that some of the code in the
AbstractJUnitResultFormatter might appear reusable and would be tempting
to reuse/extend, but I wouldn't want anything outside of Ant to start
using these classes and instead just code against the JUnit5
classes/interfaces.
Having said all this, if any of other maintainers of the Ant project
feel that we should allow these internal classes to be extensible, I
won't mind having this work reviewed and merged.
Fork Mode Support
Apache Cassandra is a large and complex product and in order to guarantee
its quality we run many tests independently. It lets us ensure different
test suites do not affect each other. For isolated testing we spin up a new
JVM per tests suite via *forkMode* property. Unfortunately,
*junitlauncher* task
does not provide such a functionality.
Currently, we'd like *mode* attribute to *fork* element. Here is the
corresponding PR: https://github.com/apache/ant/pull/174
I remember there was some bugzilla discussion of a similar question (or
maybe on some other forum). I'll take a look at this PR soon.
I'd be glad if you could provide some feedback on that. Also I need some
guidance here - I have a suspicion that *JUnitLauncherTaskTest* is not
being run during "./build clean test" (I cannot grep it in logs). Could you
please help me to run this particular test from CLI.
Have you fetched the optional JUnit5 libraries before running these
tests? A lot of Ant's tasks are optional and their tests are only run if
the corresponding libraries are available in the classpath. To fetch
these dependencies you can do:
ant -f fetch.xml -Ddest=optional
and then run the tests using the command you currently use.
Use File Support
Apache Cassandra does not always need to write testing output to a file.
Even though it is possible to achieve writing into standard output (by
overriding *TestResultFormatter.setDestination *method) instead of a file,
it is impossible to prevent empty files from being created on the file
system. Of course, we can delete these files, however, it would be nice to
have the functionality similar to *junit* task.
I've already started a related discussion on the PR (please, chime in):
https://github.com/apache/ant/pull/171
I'll take a look at this one.
-Jaikiran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
