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