Would it make sense to just convert the JUnit 3 tests to JUnit4? Or would that be a waste of time?
On Thu, 29 Feb 2024 at 21:19, Gary Gregory <garydgreg...@gmail.com> wrote: > > Oops, I mean TestNG. > > Gary > > On Thu, Feb 29, 2024, 3:41 PM Gary Gregory <garydgreg...@gmail.com> wrote: > > > 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 > >> > >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
