I'm creating a custom mock object that uses the classic Expect()/Verify() pattern.
In the Verify() method I use the following collections
Queue<object> actualQ;
Queue<object> expectedQ;
public void Verify()
{
Assert.That(actualQ, Is.EqualTo(expectedQ));
Reset();
}
What I want to do is allow the expectedQ to contain either normal objects or Constraints ! Allowing collections to contain constraints is very cool and I'm sure this would have wider usage than just my problem.
I've had a look at the source for Constraints.EqualConstraint.ObjectsEqual()
And I'm wishing that it included this case ...
if (expected is Constraint) {
return ((Constraint)expected).Matches(actual);
}
... and then I guess you'd need extra code to ensure that the failure point correctly used ((Constraint)expected).WriteDescriptionTo()
Thanks,
Tony.
I'm not comfortable with a feature that turns Equality into some other constraint - even inequality!
I do understand what you want to accomplish. In fact NUnit.Mocks does exactly this by allowing
constraints in the expected value field.
What if instead we had a syntax element Satisfies() taking an array of constraints as an argument?
Matches() would make sense as well, except that that's what we use for regular expressions.
Or taking it from Hamcrest, we could use AllOf and AnyOf. Any other ideas?
Charlie
That all makes good sense Charlie. I agree that its no longer an Equality constraint and your suggested naming & features are wise.