DEV Community: David Da Silva

Make your tests more readable using AssertJ and BDD syntax

David Da Silva — Tue, 02 Nov 2021 20:06:17 +0000

I love writing tests! I get a dopamine boost every time I see those green tests in my reports. Every test failing is a tiny puzzle to solve and you get a green result as soon as you find the solution. Supergreen!

But I know that writing and reading tests can be a chore for some devs. I believe this can be improved by making the tests easier to write and turning those long and boring succession of assertEquals more meaningful and fluent to read.

Remember that a developers spends more time reading code than writing it!

With those tips, reading your tests will be a breeze and your teammates will thank you for it!

Use AssertJ instead of Junit assertions

If you use Junit assertions in your tests, chances are you are mainly using the following assertions :

assertEquals(expected, actual);
assertTrue(condition);
assertFalse(condition);
assertNull(actual);

Most of the time I see tests using assertEquals() for anything like assertEquals(true, someList.size() == 5); 😱

A common pitfall of using Junit assertEquals() and it's 2 parameters is that you can easily invert the expected value with the actual value if you are not paying attention.
As long as the test is green you won't see the mistake, but if the test fail, the error message will be misleading!

Example : let's assume our method generateHash() is supposed to return a 35 chars string, but is failing :

    @Test
    void testHashMethod() {
        String actual = underTest.generateHash("some string");
        assertEquals(actual.length(), 35); // Wrong order!
    }

The error message will be misleading since the expected value is the result of the method:

org.opentest4j.AssertionFailedError: 
Expected :32
Actual   :35

If you are using intelliJ, you may have hints on which parameter is which :

but you won't have this hints during a code review on github for example. 🙈

Enter AssertJ

AssertJ comes with a variety of assertions that can be chained together and are specific to the type of your "actual" variable.

I've compiled some of my favorites assertions for various types. Some of those tests are redundant just to showcase the possibilities :

// actual is a String
assertThat(actual).isEqualTo("MD55AC749FBEEC93607FC28D666BE85E73A");
assertThat(actual).hasSize(35)
    .contains("A") // You can chain assertions if you want
    .startsWith("MD5")
    .isUpperCase()
    .isNotBlank();

// actual and expected are collections of String
assertThat(actual).hasSize(2);
assertThat(actual).contains("first value");
assertThat(actual).first().isEqualTo("first value"); // Get the first element
assertThat(actual).containsExactly("first value", "second value");
assertThat(actual).containsExactlyInAnyOrder("second value", "first value");
assertThat(actual).containsExactlyInAnyOrderElementsOf(expected);
assertThat(actual).doesNotContain("forbidden value", "another value");
// Make an assertion on all elements of the collection :
assertThat(actual).allSatisfy(s -> assertThat(s).doesNotStartWith("foo"));

// actual is an int
assertThat(actual).isEqualTo(42);
assertThat(actual).isGreaterThan(40);
assertThat(actual).isPositive();
assertThat(actual).isIn(0, 2, 42, 1337);
assertThat(actual).isBetween(30, 50);

// actual is an Instant
assertThat(actual).isAfterOrEqualTo(Instant.now())
    .isBetween(pastInstant, futureInstant)
    .isCloseTo(Instant.now(), within(1, ChronoUnit.MINUTES));

// Test an exception
Throwable thrown = catchThrowable(() -> List.of(1, 2, 3).get(4));
assertThat(thrown).isInstanceOf(ArrayIndexOutOfBoundsException.class);

As you can see, the assertion always starts with assertThat(actual) which exists for any type. This as 3 advantages :

You can't invert actual and expected values
The assertion reads like a normal sentence in English, allowing you to make your test very explicit on what you intend to verify
You can easily discover which assertion is available for your type of data with your IDE auto completion! For everything else, the documentation has plenty of examples.

One last note on AssertJ : error message are often more explicit than Junit assertions. For example if your list contain one more element than expected :

// assertJ (using assertThat(actual).containsExactly("first value", "second value"); )
java.lang.AssertionError: 
Expecting:
  ["first value", "second value", "third value"]
to contain exactly (and in same order):
  ["first value", "second value"]
but some elements were not expected:
  ["third value"]

// junit assertion (using assertLinesMatch(expected, actual); )
org.opentest4j.AssertionFailedError: more actual lines than expected: 1

If you are using Spring Boot, AssertJ is already bundled into spring-boot-starter-test along with Mockito and other testing libs. Good news!

Use the same pattern for all your tests

Define a pattern for you tests and stick to it in every test class.
This makes your tests more predictable for anyone of your team reading it.

I tend to use the following pattern, suggested by Robert C. Martin in Clean Code :

    @Test
    void someTest() {
        // Given
            // prepare your expected values, program mocks
        // When
            // call the method under test
        // Then
            // put all you assertions here, verify your mocks
    }

Which leads me nicely to my next point....

Use BDD syntax

Did you know that both Mockito and AssertJ offers an alternative syntax ?

For AssertJ you can use BDDAssertions.then to replace your assertThat():

import static org.assertj.core.api.BDDAssertions.then;
(...)
then(actual).isEqualTo(expected);// Everything else is the same

For Mockito you can use BDDMockito.given instead of when() :

import static org.mockito.BDDMockito.given;
(...)
// instead of :
when(myMock.someMethod(any())).thenReturn("Some mocked value");
// use this :
given(myMock.someMethod(any())).willReturn("Some mocked value");

This will turn something like this :

@Test
    void someTest() {
        when(myMock.someMethod(any())).thenReturn("some string");
        var expected = "MD55AC749FBEEC93607FC28D666BE85E73A";

        var actual = underTest.generateHash(10);

        assertThat(actual).isEqualTo(expected);
        verify(myMock).someMethod(10);
    }

into this :

@Test
    void someTest() {
        // Given
        given(myMock.someMethod(any())).willReturn("some string");
        var expected = "MD55AC749FBEEC93607FC28D666BE85E73A";

        // When
        var actual = underTest.generateHash(10);

        // Then
        then(actual).isEqualTo(expected);
        verify(myMock).someMethod(10);
    }

Beware that BDDMockito also have a then() method, I don't recommend using both in the same class.

I found this methods fits nicely inside the "Given, When, Then" pattern with no downsides since it's a simple alias of the original methods.

Use soft assertions

If your test method contains multiples assertions but one of them fails, the test stops at the first failure but don't run the other assertions. If you have 2 assertions failing, you won't know it until you have fixed the first assertion, run the test again and get the second failure. Such a waste of time!

Some devs will argue that a test method should only have a single assertion. I prefer the concept of "one test should only test one concept".
For example if the method under test returns a list I could have assertions on the size of the list, the values inside the list and their orders, test the absence of some values etc. I write all those assertions in the same test method.

Soft assertions allows you to run multiples assertions without stopping at the first failure. If anything fails you will have a report on which assertions failed.

    @Test
    void testList() {
        var actual = List.of("first value", "second value", "third value");
        var expected = List.of("first value", "second value");

        var softly = new BDDSoftAssertions();
        softly.then(actual).contains("first value");
        softly.then(actual).first().isEqualTo("first value");
        softly.then(actual).containsExactly("first value", "second value"); // fails
        softly.then(actual).containsExactlyInAnyOrderElementsOf(expected); // fails
        softly.then(actual).doesNotContain("forbidden value", "another value");
        softly.then(actual).allSatisfy(s -> assertThat(s).doesNotStartWith("foo"));
        softly.assertAll();
    }

Here is the result :

org.assertj.core.error.AssertJMultipleFailuresError: 
Multiple Failures (2 failures)
-- failure 1 --
Expecting:
  ["first value", "second value", "third value"]
to contain exactly (and in same order):
  ["first value", "second value"]
but some elements were not expected:
  ["third value"]

at SimpleTest.testList(SimpleTest.java:49)
-- failure 2 --
Expecting:
  ["first value", "second value", "third value"]
to contain exactly in any order:
  ["first value", "second value"]
but the following elements were unexpected:
  ["third value"]

at SimpleTest.testList(SimpleTest.java:50)

⚠️ Warning : do not forget the line with assertAll() otherwise your test will be green but no assertions are actually run!

There are other ways to use the Soft assertions in the documentation that allows you to omit the assertAll() if you want.

That's it for today! I still have plenty of tips regarding tests but those will be for another post.

Did you learn something new today? Do you have suggestions? Feel free to leave a comment below!

Unit testing time driven methods

David Da Silva — Sat, 23 Oct 2021 18:49:44 +0000

Hi! This is my first post on a series of quick tips to improve your tests in Java, I hope you will learn something today 👍

Have you ever used Instant.now(), LocalDateTime.now() or ZonedDateTime.now() in your code, only to find it difficult to test later on ?

Let's take an example :

public class Hohoho {

    public String isItChristmasYet() {
        LocalDate now = LocalDate.now();

        if (now.getMonth() == Month.DECEMBER) {
            if (now.getDayOfMonth() == 25) {
                return "Yes! Merry Christmas! 🎅";
            }
            else if (now.getDayOfMonth() == 24) {
                return "Almost there! 😁";
            }
        }
        return "Not yet 😔";
    }
}

How would you test this method?

You could pass the LocalDate as an argument of the method but that would change the semantic of the method.

You could also use some libs like Powermockito to mock the static method of LocalDate.now() but this would also affect other tests.

Here is a tip : use a java.time.Clock!

Every time you need to use a *.now() method, pass a Clock object as a parameter.
You can set the clock to be the system default in you constructor, and add a setter method to override it during tests.

Let's apply this in our example :

public class Hohoho {

    private Clock clock;

    public Hohoho() {
        // Set a normal value for the clock, here UTC
        this.clock = Clock.systemUTC();
    }

    // For testing purpose : override the clock
    public void setClock(Clock clock) {
        this.clock = clock;
    }

    public String isItChristmasYet() {
        LocalDate now = LocalDate.now(clock); // <- use the clock

        if (now.getMonth() == Month.DECEMBER) {
            if (now.getDayOfMonth() == 25) {
                return "Yes! Merry Christmas! 🎅";
            }
            else if (now.getDayOfMonth() == 24) {
                return "Almost there! 😁";
            }
        }
        return "Not yet 😔";
    }
}

If you want to avoid the setter, you could inject the Clock through dependency injection.
I personally don't mind having a setter in this case.

Now let's look how this will help our tests :

class HohohoTest {

    private Hohoho underTest = new Hohoho();

    @DisplayName("Should respond 'Not Yet' in February")
    @Test
    void februaryTest() {
        // Fix the clock to my birthday
        Clock clock = Clock.fixed(Instant.parse("2022-02-21T12:00:00Z"), ZoneId.of("UTC"));
        underTest.setClock(clock);

        String actual = underTest.isItChristmasYet();

        assertThat(actual).isEqualTo("Not yet 😔");
    }

    @DisplayName("Should respond 'Almost there' the 24th of December")
    @Test
    void december24thTest() {
        // Fix the clock to christmas eve
        Clock clock = Clock.fixed(Instant.parse("2022-12-24T12:00:00Z"), ZoneId.of("UTC"));
        underTest.setClock(clock);

        String actual = underTest.isItChristmasYet();

        assertThat(actual).isEqualTo("Almost there! 😁");
    }

    @DisplayName("Should respond 'Yes' on Christmas")
    @Test
    void christmasTest() {
        // Fix the clock to christmas day
        Clock clock = Clock.fixed(Instant.parse("2022-12-25T12:00:00Z"), ZoneId.of("UTC"));
        underTest.setClock(clock);

        String actual = underTest.isItChristmasYet();

        assertThat(actual).isEqualTo("Yes! Merry Christmas! 🎅");
    }

}

By fixing the Clock object to a specific instant in time, every method now() that use the clock will return exactly the same result.

This means your test will always be consistent, using the same values every time, no mater when they are run : be it on new year's eve, 28th of February or while switching from winter time to summer time!

Do you have another approach for testing time sensitive methods? Let me know in the comments! 👍