Let's bikeshed std.experimental.testing assertions/checks/whatchamacallits

Atila Neves via Digitalmars-d digitalmars-d at puremagic.com
Mon Jul 13 08:36:38 PDT 2015


On Sunday, 12 July 2015 at 15:15:07 UTC, Jacob Carlborg wrote:
> On 2015-07-10 14:37, Atila Neves wrote:
>
>> So... unconvinced again. I tried implementing it and it 
>> started getting
>> to be a right royal pain, and then I realised that there's 
>> nothing to
>> prevent a user from writing their own matchers right now. From 
>> your
>> example:
>>
>>      void shouldBeParsedAs(Code code, ASTNode node) {  //I 
>> don't really
>> know what the types should be
>>          if(...) {
>>              throw new UnitTestException(...);
>>          }
>>      }
>>
>> And... done. No need for a `Should` struct, no need for the
>> complications I faced trying to use one. I think the design is 
>> as good
>> as it can be.
>
> If I compare this with RSpec. A custom matcher in RSpec would 
> implement one method, returning a bool, to indicate if the 
> assertion passed or not. In your example the user need to worry 
> about throwing exceptions and which kind to throw. I consider 
> that an implementation detail.
>
> Also, RSpec is able to automatically infer a failure message 
> based on the name of the matcher. Optionally the matcher can 
> customize the failing message.
>
> It seems like with your version you need to implement both a 
> positive and negative version.

There's a reason for that and I'm curious as to how RSpec handles 
it. If it were just a matter of pairing up assertions for the two 
boolean values of a condition that'd be easy. But the formatting 
of the error message is anything but. `shouldEqual` and 
`shouldNotEqual` have very different outputs even if what causes 
an exception to be thrown is just a check on the opposite 
condition.

For the same reason, a user wanting to extend the framework has 
to format their own error messages, which means just defining a 
predicate isn't enough.

If I'd seen any more duplication I'd've removed it, but the 
different positive and negative versions of the `should` 
assertions are due to the very asymmetrical error messages. If 
there's a better way of doing it I'd love to find out.

Atila


More information about the Digitalmars-d mailing list