unit-threaded v0.7.45 - now with more fluency
Nick Sabalausky (Abscissa)
SeeWebsiteToContactMe at semitwist.com
Tue May 8 07:07:30 UTC 2018
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.
More information about the Digitalmars-d-announce
mailing list