Thank you for digging into this Eric. Another component to consider for JUnit 5 migration is Commons VFS. This one is challenging due to some similar JUnit 3 and 4 heritage issues.
It is possible that between Net and VFS, what we need are custom JUnit extensions. I had started a Commons Testing repository a long time ago but never got far with adding what at the time were JUnit 4 rules. I too find some of the JUnit 5 changes baffling but that's what we got... unless we want to switch to TextNG or some other test framework which would be a big change. Gary On Thu, Feb 29, 2024, 3:13 PM Elric V <elri...@melnib.one> wrote: > 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 > >
