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 >> >>
