0

I use assertJ and have multiple assertThat assertions in my test case. When first assertion fails test is finished but I don't want that. I'd like to have information about all failing assertions after single executing of test case. Is it any way to do that ? I have found solution with SoftAssertions here -> http://joel-costigliola.github.io/assertj/assertj-core-features-highlight.html#soft-assertions but it's ugly to add variable. before each assertThat

kris82pl
  • 977
  • 3
  • 12
  • 21

3 Answers3

3

A bit of example code would help, but then, this is more of a theoretical problem, as the real answer is: consider not having multiple assertions in one test call!

Meaning: the idea of a failing test is to get you to a problem as quickly as possible. When you combine multiple asserts into a single test, then you make our life harder by default. Because instead of knowing "test X with assertion Y failed, you have to first study logs very carefully to identify which asserts passed, and which one failed.

Therefore the recommend practice is to not put multiple asserts/check into a single test.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • Hey me dear ! Always a pleasure to read your post and to look your around ! Agree about "the idea of a failing test is to get you to a problem as quickly as possible." but agree less about "practice is to not put multiple asserts/check into a single test." – davidxxx Jun 14 '18 at 08:48
1

If you don't like soft assertions, you can give a try to JUnit 5 assertAll but otherwise I would follow @GhostCat advice and try to assert one thing per test (that usually leads to only a few assertions).

Joel Costigliola
  • 6,308
  • 27
  • 35
  • 1
    The `assertAll` example in the referenced question seems something that we can very well achiev with the excellent `assertThat(...).extracting(...).containsExactly(...)` of your library ! Thanks for that :) – davidxxx Jun 14 '18 at 08:53
1

I think that in some cases you may and sometimes even you have to assert multiple things in a single test method if your method perform multiple changes that you should check through different levels/abstractions.
For example as you test a method that adds an element in a object that stores it, you can assert that the number of elements contained in the object were incremented by one but you can also check that the new element were correctly added concerning its values.
You have two levels/abstractions : the object that contains the element that has a "direct/core" state and the elements that it contains that have their own states.

In splitting it in two assertions, it would give a test that looks like :

@Test
public void addElt(){
    foo.addElt(new Element("a name", "a role"));

    assertThat(foo).extracting(Foo::getSize)
                   .contains(actualSize+1);    
    assertThat(foo.getLastElt()).extracting(Element::getName, Element::getRole)
                                .containsExactly(addedElt.getName(), addedElt.getRole());
}

So now why trying to couple two assertions that checks two different things ?
Does it really bring a value for debugging your test ?
I don't think so.
Trying to assert the changes on the two level of abstraction in a single assertion makes clearly no sense : complex and useless noises.
If the first assertion fails :

assertThat(foo).extracting(Foo::getSize)
               .contains(actualSize+1);

It very probably means that the element was not added.
So in this case, performing the second assertion :

assertThat(foo.getLastElt()).extracting(Element::getName, Element::getRole)
                            .containsExactly(addedElt.getName(), addedElt.getRole());

makes no sense as it will very probably be also in error.
The developer that handles the failure test needs only to have useful information and not noise that can make its solving harder. So having a feedback about the size that is not which one expected is just what you need.

What I try to explain is right for AssertJ as for any testing framework.

davidxxx
  • 125,838
  • 23
  • 214
  • 215