You can use a Do to do that, that is what it is for.
On Wed, Oct 1, 2008 at 1:15 PM, ssteinegger <[EMAIL PROTECTED]> wrote:
>
> I would like to make a difference between "Filtering" and "Asserting"
> arguments of expected calls.
>
> The problem is, there is an important difference between "Filtering"
> and "Asserting". "Filtering" means, the expectation only matches if
> all the criteria match. This is defined with the classical Constraints
> or the inline Arg's.
>
> Asserts are if you test that some values are correctly passed to the
> expected call.
>
> Until now, with Rhino.Mocks 3.4 I also use the Constraints as
> "Asserts". I wrote expectations like this:
>
> LastCall.Constraints(
> Is.TypeOf<TestObject>()
> && Property.ValueConstraint("BusinessId",
> Is.NotEqual(Guid.Empty))
> && Property.Value("LatestVersionNumber", (long)1)
> && Property.ValueConstraint("ReleasedVersion", Is.Null())
> && Property.ValueConstraint("ProposedVersion",
> Property.Value("VersionNumber", (long)1)) );
>
>
> This works quite well, you can define whole object graphs with the
> constraints. I have many such constraints when mocking the data access
> layer. Some entities are created in the unit under test, stored in
> database and never visible to the caller.
>
> The fundamental problem is the message I get when a value is wrong. I
> get something like "IGeneralDataAccess.Store( <all the constraints> );
> Expected #1, Actual #0.
>
> This is not the information I need. To find out what actually has been
> passed, I need to debug. I would like to have a message like
> "Argument Assertion failed: IGeneralDataAccess.Store( <constraints> ),
> argument 0 - property ProposedVersion - property VersionNumber
> expected 1, actual 0."
>
> I found this blog (http://ayende.com/Blog/archive/2008/07/02/Rhino-
> Mocks-3.5-A-feature-to-be-proud-of.aspx<http://ayende.com/Blog/archive/2008/07/02/Rhino-Mocks-3.5-A-feature-to-be-proud-of.aspx>)
> from Ayende mentioned in
> another discussion.
> With Rhino.Mocks 3.5 I can do this:
>
> dataAccessMock
> .Stub(x => x.Store(Arg<object>.Is.TypeOf<TestObject>()))
> .Do(invocation =>
> {
> // get the argument and cast it
> TestObject entity = invocation.Arguments[0] as TestObject;
> Assert.AreNotEqual<Guid>(Guid.Empty, entity.BusinessId);
> Assert.AreEqual<long>(1, entity.LatestVersionNumber);
> // ... and so on
> });
>
> Without trying it myself, it should work fine. It matches the
> expectation and asserts the arguments afterwards. This syntax is
> indeed not very intuitive, and only few people will ever use it. (IMO,
> Do should usually not be used, because mocks should not contain logic.
> Except for some special cases, Do has some smell for me.)
>
> I would like something as follows:
>
> dataAccessMock
> .Stub(x => x.Store(Arg<object>.Is.TypeOf<TestObject>()))
> .AssertArguments(
> Property.ValueConstraint("BusinessId", Is.NotEqual(Guid.Empty))
> && Property.Value("LatestVersionNumber", (long)1)
> ...
> );
>
> (I know there is a better syntax for the properties that does not use
> the property names in strings. But i don't know how to use it when
> having more then one criteria.)
>
> -- OR --
>
> dataAccessMock
> .Stub(x => x.Store(Arg<object>.Is.TypeOf<TestObject>()))
> .Arguments(
> (TestObject entity) =>
> {
> // Test-Framework asserts
> Assert.AreNotEqual<Guid>(Guid.Empty, entity.BusinessId);
> Assert.AreEqual<long>(1, entity.LatestVersionNumber);
> // ... and so on
> }
> );
>
> I think I'd prefer the last one. It is simpler to implement and
> simpler to use - except that it does not tell the user explicitly that
> he most likely should write Assert's in the lamda expression.
>
> Actually, it's nothing more than "Do" with an action for each
> argument. Very simple.
>
> Ayende, what do you think about that? I could write another patch.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Rhino.Mocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/RhinoMocks?hl=en
-~----------~----~----~----~------~----~------~--~---
