Re: [Nmock-general] Proposal for a change.

[Joe W. <jo...@tr...>]

I have a need for this too.

How about changing the interface of IConstraint (is this the kind of 
thing you meant with the TestValue approach?).

From:

    interface IConstraint {
      bool Eval(object actual);
      string Message { get; };
    }

To:

    interface IConstraint {
      bool Eval(object actual);
      string Message(object actual);
    }

The LastValue suggestion doesn't quite feel right. Could make 
IConstraints harder to implement (they're very clean at the moment) and 
could get confusing  if reusing constraints.

So when are we gonna see the IExplorer/DOM stuff then? I'm intrigued.... :)

-joe

Steve Freeman wrote:

> We've been using the NMock constraints and have come across a little 
> problem. We're using it for testing the contents of DOM elements by 
> driving IExplorer through its API. We've written some extra 
> constraints that match parts of an element, which works fine, but we 
> means we have a hard time printing meaningful error messages because 
> it's only the constraint that extracts the final value to check, we 
> can't tell from the containing assertion. For example:
>
>   IConstraint constraint = new IElementTextEquals("some text");
>
>   Assert("Expected " + constraint.Message + " got " + ielement,
>          constraint.Eval(ielement));
>
> will only show the class of ielement when it fails. We can't find its 
> text contents.
>
> The object that /does/ know the actual value is the constraint, so 
> that seems like the right object to ask. I can see two ways of doing 
> this:
>
> - add a method, say,
>     object TestValue(object actual)
>   that unpacks the value you want to test against, in this case the 
> element text,
>   by default the 'actual' object.
>
> - hang on to the the last test value during the Eval and make it 
> available via a LastValue property.
>
> Thoughts?
>
> S.
>