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