You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So I'm wondering what people's actual use cases are. In other words, what are some examples where you feel you need a custom message over the default one (that can't be solved better by improving the default one or creating a custom assertion)?
For me, I'd say the places where I'm tempted to use this are often places where a custom assertion would work as an alternative. It's usually where the assertion is "in the weeds" and lacks the context necessary to understand the problem.
For instance, I wrote a test recently that for each plan code in an insurance domain, there should be cash value metadata for a given issue age, plan duration, and gender. By the time I work my way through all those factors, if I discover the plan isn't there, just getting a message that the object is null is not very useful. I want an error message that says that there's no metadata for a given plan code, issue age, plan duration and gender.
In this case, I ended up finding it simpler to just write classic JUnit assertions with a custom failure message, but I probably could have made a custom assertion. I'm tempted to go back and try just to compare the two paths. A custom assertion feels like more work, but that's probably in part because I've only made one a few times, so it doesn't come naturally to me yet.
Since assertk was inspired by assertj, might sa well copy what assertj has
Example of a failing assertion with a description :
TolkienCharacter frodo = new TolkienCharacter("Frodo", 33, HOBBIT);
// failing assertion, remember to call as() before the assertion, not after !
assertThat(frodo.getAge()).as("check %s's age", frodo.getName()).isEqualTo(100);
The error message starts with the given description in [] :
Assertion messages usually dont get much love. That's because if your tests pass, then you dont see the value of assertion messages.
But if your tests fails, that's where you get the value. And it's hard to tell what the error is if you have multiple assertions and you dont have custom assertion messages. Without custom assertion messages, devs starts putting break points on their tests.
I was specifically looking into the .withFailMessage(Supplier) version. That has the benefit of not evaluating the assertion until it is printed, which is very handy for more costly messages, DB lookups and such, e.g.:
also, another benefit of lambda is that it is evaluated after the assertion, not before. So if assertion changes state, that new state would be printed, not the previous one.
Activity
astrdark commentedon Apr 3, 2018
I'll take this
evant commentedon Apr 3, 2018
Sure! See linked issue for what api I was thinking, let me know if you want to discuss it.
pavelicii commentedon Feb 20, 2019
Would it be implemented?
evant commentedon Jul 13, 2019
If anyone's wondering, the reason this hasn't been implemented is there's some design questions around it like:
[name] ... (value)ex:So I'm wondering what people's actual use cases are. In other words, what are some examples where you feel you need a custom message over the default one (that can't be solved better by improving the default one or creating a custom assertion)?
geoffreywiseman commentedon Sep 3, 2019
For me, I'd say the places where I'm tempted to use this are often places where a custom assertion would work as an alternative. It's usually where the assertion is "in the weeds" and lacks the context necessary to understand the problem.
For instance, I wrote a test recently that for each plan code in an insurance domain, there should be cash value metadata for a given issue age, plan duration, and gender. By the time I work my way through all those factors, if I discover the plan isn't there, just getting a message that the object is null is not very useful. I want an error message that says that there's no metadata for a given plan code, issue age, plan duration and gender.
In this case, I ended up finding it simpler to just write classic JUnit assertions with a custom failure message, but I probably could have made a custom assertion. I'm tempted to go back and try just to compare the two paths. A custom assertion feels like more work, but that's probably in part because I've only made one a few times, so it doesn't come naturally to me yet.
franz-see commentedon Jan 2, 2020
Since assertk was inspired by assertj, might sa well copy what assertj has
https://joel-costigliola.github.io/assertj/assertj-core-features-highlight.html
franz-see commentedon Jan 2, 2020
Assertion messages usually dont get much love. That's because if your tests pass, then you dont see the value of assertion messages.
But if your tests fails, that's where you get the value. And it's hard to tell what the error is if you have multiple assertions and you dont have custom assertion messages. Without custom assertion messages, devs starts putting break points on their tests.
evant commentedon Jan 2, 2020
A custom description is already handled by the
nameparam, ex:I believe this issue is asking about replacing the message part.
franz-see commentedon Jan 2, 2020
Great! thanks @evant 😄
Hope that can be added in the README/docs 😄
agoston commentedon Feb 12, 2021
I was specifically looking into the
.withFailMessage(Supplier)version. That has the benefit of not evaluating the assertion until it is printed, which is very handy for more costly messages, DB lookups and such, e.g.:For now, I'll keep using assertJ for this use case.
evant commentedon Feb 12, 2021
hm, would it be useful to allow appending additional state to an assertion? Something like:
agoston commentedon Feb 13, 2021
yes, that would help a lot!
also, another benefit of lambda is that it is evaluated after the assertion, not before. So if assertion changes state, that new state would be printed, not the previous one.
evant commentedon Feb 13, 2021
Cool, created a new issue to track this specifically #344.