On 05/07/2018 11:57 PM, Johannes Loher wrote:
On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote:
I think I'm siding with Johannes here. Much as the overloads look
nice, I don't really see the advantage over `shouldEqual`. Also,
what's with `all.these.identifiers`? Any particular reason why you are
more fond of them rather than of good ol' pascalCase?
Fluent assertions have one major advantage over using pascalCase
assertions: There is no ambiuguity about the order of arguments.
When using e.g. assertEquals, how do you know wheter is is supposed to
be assertEquals(actual, expected), or assertEquals(expected, actual)?
The first one is the only one that makes sense wirh UFCS, but it is not
clear directly from the API. On top of that, some popular Frameworks
(I‘m looking at you, JUnit...) do it exactly the other
way round.
With fluent assertions, you don‘t have this Problem, it is much more
clear that it should be actual.should.equal(expected) and not
expected.should.equal(actual), because it fits naturally in the chain of
ufcs calls.
I don't think that's the issue. At least, it isn't for me.
It's not a question of "assert equals" vs "should equal" (Though I am
convinced by your argument on that matter).
The question is: Why "should.equal" instead of "shouldEqual"? The dot
only seems there to be cute.
Not that I'm necessarily opposed to any of it (heck, I like cuteness in
any sense of the word), it's just that: If the "~" thing is operator
abuse, then I don't see how "should.equal", "should.not.be" etc,
wouldn't fall into the same category.
