unit-threaded v0.7.45 - now with more fluency

[Cym13]

On Tuesday, 8 May 2018 at 07:07:30 UTC, Nick Sabalausky 
(Abscissa) wrote:
> 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.

I wouldn't say it's an abuse, the dot means exactly the same 
thing as everywhere else in the language. I'm way less fan of 
overidding ~ since that doesn't have that meaning in any other 
context.

Without having actually used it, I like the composability over 
pascalCasing here, it looks like it fits nicely in a functional 
environment with things like aliases and partials I think, 
defining your own primitives naturally... Nothing one can't do 
with regular functions and pascalCased assertions, but it sounds 
like it would be way more verbose.

It also sounds like it's easier on the implementation side since 
you never have to define both a "shouldSomething" and 
"shouldNotSomething", and that means as a user I can expect less 
bugs and better maintainance of the library.

That said, it'll have to be field-tested to be sure.