reflect written assertion functions in reporting

[robstoll]

Issue is based on https://github.com/robstoll/atrium/issues/292#issuecomment-571599350 So far I had the rational that the bullet points in the reporting should reflect the assertions a developer made. For instance

expect(listOf(1,2)).containsExactly(1)

Results in

expect: [1, 2]        (java.util.Arrays.ArrayList <410495873>)
◆ contains only, in order: 
  ✔ ▶ entry 0: 1        (kotlin.Int <110771485>)
      ◾ to be: 1        (kotlin.Int <110771485>)
  ✘ ▶ size: 2        (kotlin.Int <710239027>)
      ◾ to be: 1        (kotlin.Int <110771485>)
        ❗❗ additional entries detected: 
           ⚬ entry 1: 2        (kotlin.Int <710239027>)

The size check is within the contains only, in order bullet point. The reason why I decided to do it this way is to guide newcomers. Having it first like this:

expect: [1, 2]        (java.util.Arrays.ArrayList <410495873>)
◆ size: 2        (kotlin.Int <710239027>)
  ◾ to be: 1        (kotlin.Int <110771485>)
◆ contains only, in order: 
  ✔ ▶ entry 0: 1        (kotlin.Int <110771485>)
      ◾ to be: 1        (kotlin.Int <110771485>)
        ❗❗ additional entries detected: 
           ⚬ entry 1: 2        (kotlin.Int <710239027>)

might be confusing as it looks like one wrote:

expect(listOf(1,2)
 .hasSize(1)
 .containsExactyle(1)

Due to the above linked issue I mulled this concept over and following a few thoughts:

• I still think it might be helpful for newcomers, but learning that containsExactly comprises two checks is probably easy as well
• as soon as people start to combine assertions (and I do this almost all the time) then the bullet points do not reflect the assertions anyway.
• I had once a project where I needed fail fast behaviour, always, regardless if the failure reporting was not informative. Having the size check outside of the contains, only, in order check would be beneficial in this case as we don't have to search at all. However, this is probably a rare case and more or less neglectable.

What do you think, should remove this restriction and implement assertion functions also in other ways if we find it more suitable?

[jGleitz]

Hm, I think it makes sense to pull some assertions on the same level, like in the example you have given.

I noticed that atrium’s reporting has a tendency to increase in indentation very rapidly. This does not always help readability, IMHO.

Additionally, I do not think that it is really a use case to teach newcomers how to compose assertions by having them read reports. I think the reports should focuse only on understandability and clarity. Newcomers learn fast by looking at existing code and docs.

[robstoll]

So let's change that with 0.10.0, created https://github.com/robstoll/atrium/issues/299