Migrate JUnit asserts to AssertJ - migration

[Pankraz76]

• [POC] Migrate JUnit asserts to AssertJ - impl #2307

[Bukama]

Have we decided to go away from JUnit assertions and add AssertJ?

That's not about if they are "better" or not, but I have in mind that Maven only uses core JUnit ones?

[Pankraz76]

For me its only about asking and avoiding overhead. JUnit will work fine as well as they have modern API as well im sure. Just going for syntax assetJ might be better in story telling:

With help of rewrite we should be able to apply what we desire. I would suggest to go with one single source of truth and not pay double the cost of carry and raising questions.

Thanks.

[Bukama]

I would suggest to go with one single source of truth and not pay double the cost of carry and raising questions.

Where was the question about migrating to AssertJ risen and discussed already? Please provide me a link, I might have overseen it in my mails.

[Pankraz76]

no i have not done that as im not aware of ATM. I heave tried to pitch an issue but its not possible like on any project i know. Please excuse my pragmatism. Im just making offers and try to gain knowledge.

Therefore its marked draft and the liked issue POC, as its just a demo to start a thread like this.

[olamy]

https://hamcrest.org/JavaHamcrest/ is really nice
This will turn into preferences discussion :)

[Pankraz76]

https://hamcrest.org/JavaHamcrest/ is really nice This will turn into preferences discussion :)

yes and checkstyle has another great solution for the exact same problem.

We use Truth

checkstyle/pom.xml

Lines 381 to 385 in 02b1e1e

com.google.truth
truth
1.4.4
test

checkstyle/checkstyle#17047 (comment)

I aim to have one to rule then all, not to ask questions which one to choose.

We dont need the overhead, its one thing like in our software design. SOC and not everything together.

[Pankraz76]

This will turn into preferences discussion :)

Leadership and the Single Source of Truth (SSOT) Imperative

The Fundamental Issue

This isn't a technical challenge - it's a leadership and standards compliance failure. We're violating basic software engineering principles that were settled decades ago.

Current Unacceptable State:

• ▶️ 3 competing styles creating maintenance nightmares
• ▶️ Architectural indecision masquerading as flexibility
• ▶️ Violating the SSOT principle at massive future cost

Non-Negotiable Truths

1. This isn't debatable
   SSOT isn't some "interesting approach" - it's table stakes for professional software development.
   "Which style should we use?" is the wrong question - the right question is "Why aren't we enforcing our standard?"

2. Framework neutrality

   - Arguing about frameworks while ignoring architectural integrity
   + Standardizing first, then implementing consistently
   

Yes Hamcrest is really nice.

Lets pick one and go with that, removing rivals and using gained liberty.