[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440417#comment-17440417
]
Aleksei Zotov commented on CASSANDRA-16630:
-------------------------------------------
Hi [~e.dimitrova],
Quick summary on the current state:
* I agree with Benedict that migrating existing tests makes no much sense (it
is complicated and tiresome process that leads to conflicts). The plan for this
ticket is just to support JUnit5 for tests without any tests migration.
* There were two important concepts missing in ant's Junit5 support: ability
to create own wrapper (I fixed it in
[https://github.com/apache/ant/pull/147|https://github.com/apache/ant/pull/147)])
and fork modes support. In
[junit|https://ant.apache.org/manual/Tasks/junit.html] task there was possible
to configure different fork modes: perTest, perBatch and once whereas
[junitlauncher|https://ant.apache.org/manual/Tasks/junitlauncher.html] supports
once mode only (see
[this|https://stackoverflow.com/questions/63294995/running-junit-tests-and-forking-the-jvm-correctly-ant]).
I was going to implement such a support in ant but it turned out to be
complicated since they do not even have proper test coverage.
* I parked the activity at this stage assuming that the migration would be
easier after having Maven/Gradle in place.
* Anyway, I feel it is still possible (I have an idea on a workaround) to
achieve Junit5 with ant.
As far as I understand it is a blocker for Java 17, so let me give a try with
ant. Is there any particular reason why some tests require "perTest" mode? I
believe it just helps to prevent any issues with shared state (configs,
statics, system properties, etc).
> Migrate to JUnit5
> -----------------
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
> Reporter: Aleksei Zotov
> Assignee: Aleksei Zotov
> Priority: Low
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
