I've got one paramterized contract test working now, a new one for a PoC PR
https://github.com/apache/hadoop/pull/7316 https://github.com/apache/hadoop/blob/3a3e6f3159473456e449678adfcab938a1cc95c0/hadoop-tools/hadoop-aws/src/test/formats/org/apache/hadoop/fs/contract/s3a/ITestIcebergBulkDelete.java 1. Update of the junit version, maven surefire 2. Use of the new parameterization 3. Adding @BeforeEach to all subclassed setup() methods, even though the parent declared it #3 took me a while to track down; in Junit 4 the @Before test didn't need to be repeated. Now we do. Same for teardown, presumably I suspect that the other thing we used -naming paths and tests from the parameterized values- is completely broken, which we have to deal with. Proposed: JIRAs for * updating the versions (low/medium risk. Big risks are failure to discover tests (again), failure on java versions) * ITest on junit5 aws, assigned to me, which I will subclass with some different intermediate points I have read the junit5 docs; it'll take some time to understand it all. But some things we can use * make naming junit test threads to match the method something we can due via tagged default interface methods * add tags @Flaky, @Scale, @Load, which can be added to appropriate tests; the flaky one is key as we can tell test runners to skip these * cleaner ways of doing test runs where a single class instance can be reused. Everything else is mostly of interest to people who want to do stuff like embedding test runners, writing their own test frameworks etc. I have done this in the past -including running distributed Junit tests- but it's very much niche. What they have done there is good, FWIW, even if their deprecation of the classic XML Junit format makes me a bit sad. I remember when we did it -it's format is actually defined by the limits of the XSL skills of us Ant devs. We knew what was wrong with it a while back (works for unit tests, doesn't scale to production tests that take half an hour and which don't want the XML doc buffered just so you can save the passed, failed and skipped attributes on the root node. Anyway, I'll have a quick go at one of the ITests to work. On Mon, 7 Jul 2025 at 13:09, Shilun Fan <slfan1...@apache.org> wrote: > > I believe it’s best to proceed step by step. I suggest we tackle this in > phases, avoiding the mixing of tasks like upgrading Junit unit tests, the > Maven version, and Junit5 versions. Since I’m unsure whether combining > these tasks could introduce new issues, I propose that we first focus on > migrating the Junit unit tests. Let’s start by upgrading the tests based on > Junit 5.8, removing Junit 4, and then move on to upgrading other components. > > Best, > Shilun Fan. > > On 2025/07/06 19:26:18 Cheng Pan wrote: > > Upgrading JUnit from 5.8 to 5.13 sounds like a straightforward > > version bumping, and should be low risk, so just do it? > > > > Thanks, > > Cheng Pan > > > > On 2025/07/04 14:55:38 Steve Loughran wrote: > > > I see that Junit5 completely breaks parameterization because its test > > > running is completely different...the value gets passed as a parameter > to > > > the test method, which is too late for any test setup. As a result, > all s3a > > > ITests are broken. > > > > > > The good news, JUnit 5.13 appears to restore this functionality, > somehow > > > > > > > https://docs.junit.org/current/api/org.junit.jupiter.params/org/junit/jupiter/params/ParameterizedClass.html > > > > > > I'm trying this on a new test suite I'm writing; if it works we will > have > > > to move all those parameterized test cases in hadoop-aws, maybe > elsewhere > > > back to it. > > > > > > I'm a bit disappointed with the Junit team here, though their key > > > contribution to software development "make writing tests easy" is > profound. > > > Pity they left out "make upgrading existing test suites easy" > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > >
