Hi folks,
I recently made some changes to commons-cli to move it from JUnit 4 to
JUnit 5. This was mostly straightforward, and I think it went pretty well.
Currently looking into doing the same for commons-net, but there are a
couple of tricky tests that probably require some up front discussion,
mostly JUnit 3 style tests, and one tricky JUnit 4 Parameterized Test.
In previous versions, test classes could be extended and their test
methods would be executed as part of the child class' execution. This
was true for testt methods annotated with JUnit 4's @Test, or JUnit 3's
test-prefix naming convention.
Unfortunately, this is no longer the case in JUnit 5. I think this is a
poor design decision on their part, as it makes it significantly harder
to move to JUnit 5, and it makes certain types of tests just plain
difficult. There is some discussion about this in the JUnit community
[1], but I can't predict whether this will ever be resolved in a way to
makes commons-net's upgrade any easier.
One of those cases is AbstractFTPParseTest and its children. This
abstract base class has 11 concrete test classes. I'm struggling to see
a minimally invasive way to migrate these to JUnit 5. I'm loath to use a
heavy handed approach there.
A second tricky case is FTPSClientTest, which is a Parameterized test of
a form that no longer exists in JUnit 5. It basically creates two
instances of a test class with a boolean flag (once true, once false).
JUnit 5's @ParameterizedTest annotation operates on the **test method**
level, not on the class level, which I think would make the test case
slower and harded to read.
An alternative approach would be to use Dynamic Tests, which basically
generate test cases programmatically, but again, that makes grokking the
test a lot more difficult as it requires a greater understanding of
JUnit's features.
Any insights into this would be greatly appreciated.
Best,
Elric
[1] https://github.com/junit-team/junit5/issues/960
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
