Please, definitely not assert-j or hamcrest. I'd rather stay with the
current mess.
I've actually spent time replacing assert-j with JUnit calls because Java
is verbose enough without this type of code. JUnit has the right balance
and approach IMO. I've seen code using assertj that is silly when all you
need is assertEquals().
Junit-pioneer OTOH is a fantastic library. Actually useful.
Gary
On Tue, Nov 19, 2024, 4:27 PM Piotr P. Karwasz <pi...@mailing.copernik.eu>
wrote:
> Hi Gary,
>
> On 18.11.2024 17:11, Gary Gregory wrote:
> > -1 you are undoing the port to JUnit 5. This commit is a classic JUnit
> > mistake imo, please stop, these JUnit APIs exist for a reason: The
> lambdas
> > avoid construction of failure message strings, which, as a pattern, add
> > processing, can have side effects, and always creates more garbage. This
> is
> > bad since in general toString() methods can do anything. String.format()
> is
> > a great way to create nice messages in a compact way but is not free.
> >
> > Gary
> >
> > On Mon, Nov 18, 2024, 7:53 AM <ebo...@apache.org> wrote:
> >
> >> - assertNotNull(result, () -> action + " value ValidatorResult
> >> should not be null.");
> >> - assertTrue(result.containsAction(action), () -> action + "
> value
> >> ValidatorResult should contain the '" + action + "' action.");
> >> + assertNotNull(result, action + " value ValidatorResult should
> not
> >> be null.");
> >> + assertTrue(result.containsAction(action), action + " value
> >> ValidatorResult should contain the '" + action + "' action.");
> >> assertTrue(passed ? result.isValid(action) :
> >> !result.isValid(action),
> >
> As a compromise we could switch to AssertJ, which has parameterized
> descriptions and more readable:
>
> assertThat(result).as("ValidatorResult for %s", action).isNotNull();
>
> Piotr
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
