unit-threaded v0.7.45 - now with more fluency

Johannes Loher johannes.loher at fg4f.de
Tue May 8 03:57:25 UTC 2018


On Monday, 7 May 2018 at 09:19:31 UTC, Dechcaudron wrote:
> On Saturday, 5 May 2018 at 15:51:11 UTC, Johannes Loher wrote:
>> Personally, I don't like that kind of "abuse" of operators at 
>> all. I think it looks really unusual and it kind of breaks 
>> your "flow" when reading the code. Additionally, people, who 
>> don't know about the special behaviour the operators have in 
>> this case, might get really confused. I would much prefer it, 
>> if you used a more common fluent style (like 
>> 1.0.should.be.approximately(1.0001);).
>>
>> Anyways, thanks for working on this awesome project!
>
> 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.



More information about the Digitalmars-d-announce mailing list