Consider plan for test libraries for Jackson 3.x (or consider removing Junit4)

[JooHyukKim]

Background

Currently, there co-exist JUnit 4 and JUnit 5 in Jackson 2.x.
By intuition starting Jackson 3.x, it would be effective to only have JUnit 5 and above --consistency wise, vocabulary, etc...

Considerations

• Should we consider removing JUnit4 from Jackson 3.0?
• At what point shoud migration apply?
  • Right before 3.0 release? or
  • Start now, slowly?
• What should we keep from BaseTest and BaseMapTest utilities? and how?
• How about assertJ? Like we have in jackson-core

Scope (if pushed through)

• Change all JUnit4 style test to JUnit5 test, works done per package.

[cowtowncoder]

Ideally it'd still be possible to extend BaseMapTest, but I suspect there may be issues (I vaguely recall problems wrt use of @Test annotation and base class).

My main/only concern really is amount of work involved. Well. that, and possible added difficulty going forward wrt merging Jackson 2.x test code to 3.0. Other than that, +1 for upgrade in 3.0 (and removal of JUnit 4)

Actually we could even consider this for 2.17, depending on exactly how much work is involved; backwards compatibility this important for test code.

[JooHyukKim]

Targeting the removal of JUnit4 closer to the Jackson 3 release, as @pjfanning suggested, may minimize risks. Ideally after all key features are in place but before the release candidate phase.

[JooHyukKim]

maybe we can try openrewrite. they have been helpful with micronaut 4 migrations, so they may be helpful here too

Great 👍🏼 There was literally a guide about this in OpenRewrite titled "Migrate to JUnit 5 from JUnit 4" :))

Also, there is a blog from JetBrains about migrating using Intellij Idea "Migrating from JUnit 4 to JUnit 5".

Seems like we have useful tools at our disposal for the migration work.

[cowtowncoder]

Agreed: the one real concern is that we don't want to increase friction for merging 2.x test changes/additions to 3.0.
That can be somewhat tackled by starting conversion from 2.x, converting test incrementally or in batches.

[JooHyukKim]

starting conversion from 2.x, converting test incrementally or in batches.

💡💡Makes sense. This way we don't make 2.x and 3.x anymore different and also addresses what @pjfanning was saying.

[JooHyukKim]

Maybe we can start from 2.17? I will try to make action plan (list of TODO's)

[cowtowncoder]

Quick note: I guess we did not really discuss much about exactly why upgrade to JUnit 5.
From what I have read, there are some minor incremental benefits (I like, f.ex, assertThrows), none of which seems necessarily worth tons of work. Especially since we can also start using AssertJ (which IMO we should add to databind too).

So to me the main question is return on investment -- how much work to do to get maybe some minor improvement.
And avoid busy work of changes for sake of changes.

@pjfanning I know you have reservations here. What do you think?

[pjfanning]

I'm not against writing new tests using Jupiter and/or AssertJ. My issue is bulk changing existing tests.

I code mainly in Scala and there are Scala tools like Scalafix that can be used to bulk refactor code but hand refactoring a large code base is a big task and needs careful review.

[cowtowncoder]

Ok this makes complete sense to me. I have similar concern about level of effort wrt benefits.

But maybe we can tip our collective toes and see how things go, by conversion of that one package.

[JooHyukKim]

Resolved! With final touch made by #4462

[cowtowncoder]

So, at this point converted:

• jackson-core
• jackson-databind

should also be relatively simple to convert

• jackson-annotations

and from that point on probably dataformat modules next.

[JooHyukKim]

Right, will check out the annotations issue later.

[JooHyukKim]

Reopening as per comment