Let's use AssertJ more

[Guillaume Smet]

Hi,

I highly recommend we start using AssertJ more in our code base and that we also try to use all the nice methods it provides to make our assertions as expressive as possible.

It makes debugging a test failure a lot easier as you actually know what the value was.

For instance, I recently changed the following code:

-        assertThat(logs.contains(infoLogLevel)).isTrue();
-        Predicate<String> datePattern = Pattern.compile("\\d{4}-\\d{2}-\\d{2}\\s\\d{2}:\\d{2}:\\d{2},\\d{3}").asPredicate();
-        assertThat(datePattern.test(logs)).isTrue();
-        assertThat(logs.contains("cdi, resteasy, smallrye-context-propagation, vertx, websockets")).isTrue();
-        assertThat(logs.contains("JBoss Threads version")).isFalse();
+        assertThat(logs).contains(infoLogLevel);
+        assertThat(logs).containsPattern("\\d{4}-\\d{2}-\\d{2}\\s\\d{2}:\\d{2}:\\d{2},\\d{3}");
+        assertThat(logs).contains("cdi, rest, smallrye-context-propagation, vertx, websockets");
+        assertThat(logs).doesNotContain("JBoss Threads version");

It used AssertJ but in a way that didn't help debugging. Using the proper AssertJ methods make things a lot better from a debugging perspective.

AssertJ also offers nice methods to test if a list contains some given elements (with several options: in any order, only these elements...) and a lot of other features.

I don't think we should go berserk and start a large campaign to adjust the code base but, when you're puzzled by a test failure, it's probably a good idea to improve the test with AssertJ so that we are not puzzled next time.

Thanks.

--

Guillaume

[Georgios Andrianakis]

+100

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9Fi4DiabFwbJqGTbem5c5VGXrJnTzLNU%2BDP69EKyJTrA%40mail.gmail.com.

--

Georgios Andrianakis

Independent Contractor

[Alex Soto Bueno]

Also why not adding as a default dependency in code starter so you have junit, rest assured and assertj 

El dj, 22 maig 2025 a les 13:57 'Georgios Andrianakis' via Quarkus Development mailing list <quark...@googlegroups.com> va escriure:

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-kMTzuArvAYzQkQPYBkhXc5ji4nMJRPoHgp8Lyv1HU3Yw%40mail.gmail.com.

[Georgios Andrianakis]

I am personally fine with that, but I am pretty sure some people will object as it's not strictly necessary by any means

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CAOaD6k%2BY2ynRBvzQgCU4ktY71TJEHCB2_zQeOvMKUzfyA%3Dghjg%40mail.gmail.com.

[Guillaume Smet]

Hmmm, I was really talking about the Quarkus project itself.

What people prefer to use for their own projects is beyond our control and I think we should stay lean on this side.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALeTM-kuMwf6mfunaNHhk7uf90WF0rfNw2v6AvjqMNdYhWOQ3w%40mail.gmail.com.

[David Lloyd]

It's really unfortunate that your example involved searching logs textually, because that is something we really need to do fundamentally differently. It's very brittle: if we change log formatting for example, there's a decent chance of breaking 1000+ tests, and for no reason other than the fact that the logs are searched textually instead of structurally examining the log records. I speak from experience here.

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9Fi4DiabFwbJqGTbem5c5VGXrJnTzLNU%2BDP69EKyJTrA%40mail.gmail.com.

--

- DML • he/him

[Guillaume Smet]

On Thu, May 22, 2025 at 4:20 PM 'David Lloyd' via Quarkus Development mailing list <quark...@googlegroups.com> wrote:

It's really unfortunate that your example involved searching logs textually, because that is something we really need to do fundamentally differently. It's very brittle: if we change log formatting for example, there's a decent chance of breaking 1000+ tests, and for no reason other than the fact that the logs are searched textually instead of structurally examining the log records. I speak from experience here.

I don't disagree with that but it wasn't the point :).

The example was one from this morning, there are many others (I think Holly improved a few recently).

I don't think improving things with AssertJ makes it harder to improve on what you suggested so I would say: let's improve on both.

--

Guillaume

[Bruno Baptista]

+1

The domain specific assertions are great, like the ones in OTel. 

It actually mitigates the issues with the OTel API itself. 

Example:

assertThat(textSummaryMax)
        .hasDescription("This is a test distribution summary")
        .hasDoubleGaugeSatisfying(
                gauge -> gauge.hasPointsSatisfying(
                        point -> point
                                .hasValue(500)
                                .hasAttributes(attributeEntry("tag", "value"))));

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/quarkus-dev/CALt0%2Bo9E6ZTr3x7WG4nBQ_fo1%3DFcqewGJEiOxb5FXaPtuVEVDw%40mail.gmail.com.

--

Bruno Baptista
http://twitter.com/brunobat_