I wrote up some guidelines for new tests in
https://github.com/apache/parquet-site/pull/190.

@Gunnar I don't think there's an immediate need to forbid JUnit assertions.
However, it's worth mentioning that using JUnit assertions generally makes
migrating from JUnit4 to JUnit5 much more difficult because all of the
assertions have been flipped in their actual/expected parameter order.
Using AssertJ at least for new tests made migrating to JUnit5 much easier
in the Iceberg codebase.

On Fri, Jul 3, 2026 at 6:07 PM Eduard Tudenhöfner <[email protected]>
wrote:

> That high-level plan sounds good to me and aligns with my thinking on
> this. However, I don't think we can forbid JUnit asserts via *spotless*.
> In Iceberg [1] we forbid those by using *checkstyle*, but *checkstyle* isn't
> used in the parquet project.
>
> [1]:
> https://github.com/apache/iceberg/blob/2f05390e0730200866f52a7e8585480bd6c4596e/.baseline/checkstyle/checkstyle.xml#L482-L491
>
>
> On Fri, Jul 3, 2026 at 3:36 PM Steve Loughran <[email protected]> wrote:
>
>> On Mon, 29 Jun 2026 at 15:37, Russell Spitzer <[email protected]>
>> wrote:
>>
>> > +1
>> >
>> > I do think these are generally worthwhile. They are also a great help
>> > for consistency. As long as it doesn't require a huge rewrite of the
>> > existing
>> > codebase I think it's worth while gradually switching.
>> >
>> >
>> >
>> I'd propose something like
>>
>>    1. PR to add assertJ to POMs: no source code changes
>>    2. Policy of new test suites to be assertJ only, changes to existing
>>    test suites to remain junit.
>>    3. move individual modules to assertj;
>>    4. spotless rules to forbid junit asserts
>>
>>
>> Doing in this order means there'd be a mix of the different asserts for a
>> while, and existing prs would need some work.
>>
>> Getting the AI tools to do a lot of the migration will help.
>>
>

Reply via email to