Comments (17)
You mean something like Spock assertions messages?
Condition not satisfied:
stack.size() == 2
| | |
| 1 false
[push me]
from assertj.
My first idea was less ambitious, I would like to use a message builder to build them in consistent way.
For the time being the error message is hard coded, and, for example, if I want to change the indentation I will have to change almost every error messages.
But if you have ideas for better error message and how to build them, I'm all ears.
from assertj.
Hello Joel,
It seems like a complicated refactoring to me.
If it must be done, we should try to define what defines an assertion error message.
Can it be considered like something with, at most, 4 parts which meets most of our needs :
- Expecting
- To be / have / end with / ...
- But found / was / had ...
- And not expecting ...
What should be done for assertion error messages which don't fit this model :
- Change it to fit this model (if possible) ?
- Add custom methods to handle these cases ?
- Sub-questions : Allow string formats to customize easily messages ? Doesn't this mean less uniformity ?
Some examples of this :
- ShouldBeWithin :
super("%nExpecting:%n <%s>%nto be on %s <%s>", actual, fieldDescription, fieldValue);
- ShouldContainExactly :
super("%n" + "Actual and expected have the same elements but not in the same order, at index %s actual element was:%n" + " <%s>%n" + "whereas expected element was:%n" + " <%s>%n%s", indexOfDifferentElements, actualElement, expectedElement, comparisonStrategy);
- ShouldNotContainAtIndex :
super("%nExpecting:%n <%s>%nnot to contain:%n <%s>%nat index <%s>%n%s", actual, expected, index.value, comparisonStrategy);
We could have BasicErrorMessageFactory taking an AssertionErrorMessageBuilder in its constructor instead of a formatted String with arguments. Its create() methods would call the toString method of the builder :
Also, what about unit tests and their maintenance ?
The assertion error messages and their formatting is tested so every change to the formatting will mean that many tests must be fixed. If we go for uniformity many more tests will be broken after a reformatting of error messages.
Other ideas are welcome :)
from assertj.
@abalhier, did you start working on this? This is something that I'd be interested in helping out with.
As @abalhier suggested we need to be clear on where we want to end up. But I think it would be useful to state what we believe is wrong with the current (MessageFormatter/ErrorMessageFactory) implementation.
I'm not sure the Spock style suggested by @mariuszs would work for assertj. Spock allows only a single assertion per line, whereas assertj's fluent style means you could have:
assertThat(stack).hasSize(2).contains(1, 2);
A Spock style message would make it more difficult to see which criteria had not been met
Lastly, assuming this gets rolled out iteratively, where is the best place to start?
from assertj.
I'm actually wondering if this can be addressed without too much work as it is not the most important assertj issue.
I in the first place wanted a message builder to handle indentation when displaying a value, in most of the error message indentation is one space, ex:
Expecting values:
<["Sam", 38]>
in fields:
<["name", "age"]>
but were:
<["Frodo", 33]>
in <Frodo 33 years old Hobbit>.
Comparison was performed on fields:
<["name", "race", "age"]>
I would like two spaces to make the error more readable, ex:
Expecting values:
<["Sam", 38]>
in fields:
<["name", "age"]>
but were:
<["Frodo", 33]>
in <Frodo 33 years old Hobbit>.
Comparison was performed on fields:
<["name", "race", "age"]>
from assertj.
@dorzey, No I haven't started anything yet. I was waiting for answers.
@dorzey @joel-costigliola, for this minimal feature, maybe we can just add a method which will do the normalization and apply it to the actual/expected/notExpected arguments. Many tests may have to be fixed. Perhaps they should be refactored to assert on trimmed lines instead of comparing to the whole error message. What do you think ?
from assertj.
@abalhier sorry for the lack of feedback.
I don't think that error messages tests should change a lot. Building the error message differently should be an implementation detail.
I want to keep these tests as they are because they show what a real error message looks like to the end user, it's important to provide nice and helpful error messages.
We should do a POC/spike to see if can create a message builder that can take care of indentation and also try to address #263.
from assertj.
I may try something next week-end, but if you want to start asap @dorzey, then you can :)
There are other issues I can help with.
from assertj.
@joel-costigliola - I might have time this week to begin this.
If I've understood your idea correctly then rather than BasicErrorMessageFactory taking a String in the constructor it will take a MessageBuilder meaning that all hard coded Strings, such as those in ShouldBeEqualByComparingOnlyGivenFields, can be removed. Is my understanding correct?
Something like: dorzey@652bdc5
from assertj.
@dorzey at first sight, it looks really good ! can you try migrate different kind of error messages to see if it fits well. Let ShouldBeEqual
aside as it is not a simple error message.
from assertj.
I've migrated the following (see https://github.com/dorzey/assertj-core/commits/message_builder_spike):
ShouldHaveAtLeastOneElementOfType
ShouldBeGreaterOrEqual
ConditionAndGroupGenericParameterTypeShouldBeTheSame
It's already highlighted some inconsistency in spacing and line break usage.
from assertj.
I'm more than happy to continue this if we think it is heading in the right direction.
from assertj.
I'm happy you're happy, please continue in this happy direction.
from assertj.
Happy to 😺
from assertj.
I've not had time to contribute for a while now. Is this still required? Or are there more pressing issues?
from assertj.
Welcome back ! :)
I need to think about this one, I'm not so sure it is that important. Let's put it on hold for the time being.
from assertj.
spiking #683 would be really nice.
from assertj.
Related Issues (20)
- support for isImmutable() HOT 2
- `isUnmodifiable` assertion for `Iterator` instances HOT 3
- Standardize ShouldBeEqual and remove AssertionErrorFactory HOT 2
- Failed containsOnlyNulls Assertion for Null-Extracted List Elements HOT 4
- Missing consistent order of Javadoc tags
- Merge assertj-core-java17 into assertj-core HOT 3
- Generating Javadoc in a Maven project using <detectLinks> does not work HOT 5
- Navigation to `assertj-core` or `guava` types from `assertj-guava` Javadoc site has unnecessary header
- `satisfiesOnlyOnce` stack trace does not point to failed nested assertion HOT 3
- Evaluate `DateTimeFormatter` as replacement of `SimpleDateFormat` for internal usage
- Support for Duration in Assertions.byLessThan, Assertions.within HOT 2
- Add an unwrap method to the API to get actual value HOT 3
- Unable to construct iterable assertions across a specific type easily HOT 7
- Ambiguous `assertThat` for `Temporal` instance implementing `Comparable` HOT 3
- 3.26 - Ambiguous assertThat with Temporal implementation HOT 1
- Extra variant for doesNotMatch
- Add an annotation Class navigation method
- Recursive Comparison With Ignored Fields Fails On Equal Collections HOT 4
- hasFieldOrPropertyWithValue accepting arrays
- reference to assertThat is ambiguous when asserting a `java.time.Year` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from assertj.