Thanks for the hints guys!

Patrick and Rasto basically both suggested the same approach as far as
I understood.
Just calling the methods and then asserting that the request was only
sent once to the server.
By following this approach there is no need to "Reset" a mock object,
however I'm still curious if this is even possible.
If somebody has an answer pls let me know.

@Rasto, to your question: Yes, I definitely prefer using only the
public API of an object and do not use "testing backdoors".
By using this approach you ensure that the CUT is really in the
correct state before you start your test. Remember that the test
should not know about the implementation details of the CUT, but if
you are using backdoors your are automatically exposing too much
functionality/state of the CUT to the test, which might bite you when
you refactor the code. I have been burned multiple times by following
that approach and have decided to never do it again...  ;-)

br
Karl



On 4 Apr., 07:26, Rastislav Svoboda <[email protected]>
wrote:
> I know that Karl prefers to use just "client" API
> but I usually initialize CUT "with the shortcut", not whole (sometimes
> complex) flow used by "client" API.
> Using whole flow makes test method longer, more brittle, harder to
> understand (and test runs slower).
>
> If "shortcut" method is dangerous (can make problems/inconsistence
> when real client code will use it) -
> name can start with Testing, /* like Michael Feathers' stuff with
> setting testing instance for Singleton */
> method can be internal (and assembly has InternalVisibleTo attribute)
> and used just in debug mode
>
> So I would have the test like this:
>
>       [Test]
>       public void
> ChangeRole_DeselectRoleRequestIsPending_DoesNotSendDeselectRoleCadRequest()
>       {
>          // Arrange
>          InitializeObjectUnderTest();
>          // something like this
>          _logic.TestingSetStateToDeselectRoleRequestPending();
>
>          // Act
>          _logic.ChangeRole();
>
>          // Assert
>          DispServerConnection.AssertWasNotCalled(x =>
> x.SendDeselectRoleCadRequest());
>       }
>
> QST: guys, do you prefer to use just "client" API ???
>
> On Apr 2, 11:59 pm, Karl <[email protected]> wrote:
>
>
>
> > Hi all,
>
> > I want to test the following behaviour.
>
> > When the method ChangeRole() of my object under test (variable name
> > "_logic") is called and the same request is already pending the object
> > under test should not send a second request to the server.
> > The server is represented by the mock object "DispServerConnection".
>
> > The precondition for my test would be to call the method ChangeRole.
> > (Arrange)
> > Then I call the method a second time (Act)
> > And afterwards I assert that the SendDeselectRoleCadRequest method was
> > not called on the DispServerConnection mock when the ChangeRole method
> > was called a second time.
>
> > The problem however is, that the test always fails because the method
> > was actually called during the Arrange phase. So I'm wondering how I
> > can tell my mock to "forget" everything it has recorded until now and
> > start from scratch. Is this even possible without creating a fresh
> > mock instance?
> > In the Record/Replay model all recordings on a mock were cleared after
> > calling Verify but I'm not sure how this is supposed to work in the
> > AAA model.
>
> >       public void
> > ShouldNotSendDeselectRoleCadRequest_IfDeselectRoleRequestPending()
> >       {
> >          // Arrange
> >          InitializeObjectUnderTest();
> >          _logic.ChangeRole();
> >          // How can I clear the recorded method calls on my mock
> > here???
>
> >          // Act
> >          _logic.ChangeRole();
>
> >          // Assert
> >          DispServerConnection.AssertWasNotCalled(x =>
> > x.SendDeselectRoleCadRequest());
> >       }
>
> > Thx for your help!- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

-- 
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.

Reply via email to