Behavior of BackToRecordAll() and mock.Unordered()

[David Frey]

Hi,
while tracking down an error in a unit test, I came across some (IMO) odd behavior of BackToRecordAll. I boiled it down to the following test case:

    public interface IDummy
    {
      bool GetValue();
    }

    [Test]
    public void TestBackTorecordAll()
    {
      MockRepository mock = new MockRepository();
      IDummy test = mock.StrictMock<IDummy>();

      using (mock.Unordered())
      {
        Expect.Call(test.GetValue())
          .Return(true)
          .Repeat.AtLeastOnce();
      }
      mock.ReplayAll();

      Assert.IsTrue(test.GetValue());
      mock.VerifyAll();

      mock.BackToRecordAll(BackToRecordOptions.All);
      Expect.Call(test.GetValue())
        .Return(false)
        .Repeat.AtLeastOnce();

      mock.ReplayAll();
      Assert.IsFalse(test.GetValue());

      mock.VerifyAll();
    }

This test case fails. Is this the expected behavior? If so, why does the test succeed, if i remove the mock.Unordered() call?

Maybe I'm misunderstanding what BackToRecordAll does. I expected it to go back to record mode and reset all expectations.

[haifisch]

Hi Honggoff,

for me this seems to be some undesired behavior in a corner case (you could also call it a bug). The problem is that BachToRecordAll seems to only remove expectations on the "root-Recorder", but the mock.Unordered() introduces a new "sub-recorder". So in this case BackToRecorded changes nothing ;-)

Maybe I'll take a look at the code and try to find a useful solution during the next days.

But one annotation - I don't know your concrete scenario, but I'll find it quite curious that you'll use Ordered/Unordered-Expectations together with some resting of expectations, because I can only imagine that you'll need this for a very complex/hard to understand test?

Br,

Andreas

[haifisch]

Hi,

I just commited a patch for this issue - but haven't created a new binary release for now.
https://github.com/alaendle/rhino-mocks/commit/d8a4d41778321a673e1ef49b03a27fde2e5d00ca

Best regards,

Andreas

[bill richards]

Just out of interest, but why are we developing against Record/Replay?

[haifisch]

Hi Bill,

I'm sorry but I think I doesn't get your point. Is something wrong with the behavior hanggoff and I expected? What exactly did you mean by "developing against Record/Replay"?

Best regards,

Andreas

[bill richards]

Andreas,

I'm not sure if there is anything wrong with the behaviour you are expecting. What I mean by "developing against Record/Replay" is really in response to your post (included below)

"Hi,

I just commited a patch for this issue - but haven't created a new binary release for now."

I'm not saying don't do it, or you shouldn't do it or anything like that; It's simply that my interest was piqued when I noticed that you had committed a code change in the area of Record/Replay; mainly because my understanding was that Record/Replay is not really currently a focus of attention in Rhino and instead efforts were being put into AAA.

It has been "suggested" on multiple occasions in the past that the Record/Replay syntax be either attributed as deprecated, or at least moved to an alternate namespace which would show a clear separation of functionality between it and AAA. -the later proposal mainly to support those establishments who have a large existing investment in Record/Replay tests.

It's just a question to help my understanding of the current development in Rhino :o)

[haifisch]

Hi Bill,

everything is clear to me now ;-) I totally agree with you that rhinomocks should focus on AAA (personally I only use new AAA-syntax in my tests), but on the user side my limited spare time doesn't allow me to really force such huge changes in Rhino.Mocks - but I'll think maintenance is crucial for every piece of software which wants to be successful - and I also found that the partial behavior criticized by hanggoff is strange - I just wanted to provide some small/simple improvement.

And while Rhino.Mocks project is multi-forked on github nobody is constrained to use my fork ;-)

Best regards,

Andreas