I personally use a Do to capture the object and assert directly against it.
Now if only I could figure out a way to use Do without having to create a
custom delegate every time...
On Wed, Oct 1, 2008 at 7:19 AM, ssteinegger <[EMAIL PROTECTED]> wrote:
>
> Ok, I just can use Do. My second solution isn't actually far from
> that.
>
> I just tried to make it more explicit, probably even more declarative.
> More like "check-for-argument-values-here" than "execute-some-custom-
> code-here". Everything you can find by name in an API, you don't have
> to explain to the people. IMHO, it is not obvious how to assert for
> argument values.
>
> What are other people thinking about that?
>
> On 1 Okt., 12:38, "Ayende Rahien" <[EMAIL PROTECTED]> wrote:
> > 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-t...>)
> > > 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
-~----------~----~----~----~------~----~------~--~---
