Ayende @ Rahien

Jeremy Gray commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Sat, 05 Jul 2008 18:33:08 GMT

@Aaron - when it increases clarity, it gets used. When it doesn't, it doesn't. To do otherwise is the only thing that could be considered asinine. There are people that like Expect and VerifyAllExpectations, there are people that like using Stub and AssertWasCalled instead. There are also people who mix and match, choosing the option that best fits easch situation. I haven't been calling out for anything that would limit those options, I've just been calling out for simplifications that might (emphasis on might, as this is still an exploration, after all) help the whole model be more understandable to a wider audience and require less mental gymnastics even for those already somewhat familiar with the technology. I dare say you've hyper-focused on a non-issue.

Aaron Jensen commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Wed, 02 Jul 2008 22:11:34 GMT

I agree when it comes to the old pre-3.5 way of doing things. But with the new syntax, you're clearly willing to change some things. It's moot though, as we don't agree. Some day, if I ever finish/really get started on Machine.Mocks I'll have an alternative with a simple, opinionated api and no remnants of record/replay exposed to the user. I'm still quite happy using the many portions of Rhino.Mocks I love though :)

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Wed, 02 Jul 2008 18:08:19 GMT

Aaron, Regardless of my feeling (or yours), I am not going to going to break published API if I can avoid it in any way

Aaron Jensen commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Wed, 02 Jul 2008 15:51:36 GMT

Jeremy, Moving assertions into the middle of the flow of a test just to save one line is asinine. Often it doesn't even save that line because you're calling VerifyAll any way. Regardless, I'd say the situation where you could use expect is rare. I think the following conditions need to be met: * You are verifying interaction * AND The return value from that interaction is "important" * AND The interaction can't be tested by some other state change/whatever that is a result of the return value Even *IF* you meet all of these conditions, having two lines of code is more readable. Even in pseudo code it's more readable: foo.Bar will return 5 DoSomething foo.Bar should have been called. vs. foo.Bar should be called soon, and it will return 5 DoSomething Verify that everything I said should be called was actually called Also, I can practically guarantee you that many of Rhino.Mocks users misuse Expect all the time. Heck, I used it completely wrong a year ago. I didn't even know about SetupResult. The guidance wasn't there. As a result my tests were highly coupled to my implementation and I was testing far more than I intended to test. The guidance should be in the framework. Unfortunately, Ayende stated that he feels it is "more natural" to expect before the interaction and I have no way of arguing against his feelings, so I don't expect Expect/Verify to go away from RM any time soon.

Jeremy Gray commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Wed, 02 Jul 2008 15:25:34 GMT

@Ayende - I really regret having been away from this thread through the last day, because it has become quite clear that you and I still have wires crossed re: the intended behaviour of a call like StubUnexpectedinteractions. In this proposed syntax change under discussion, you have based the default behaviour on that of a dynamic mock. As such, we don't even need a StubUnexpectedInteractions call, because it is that way by default. We need just two calls: one to go strict and throw on all unexpected interactions, another to add property behaviour. These two calls would push the mock in opposite directions from the default middle ground of stubbing unexpected interactions. While these two could technically be applied in combination, I wouldn't be opposed by restricting doing so, which would put the three possible states on a continuous line that ranges from very loose, very stub-like behaviour on the one end, through the default dynamic mock -style behaviour in the middle, to the very strict, throwing on all unexpected interactions behaviour on the other end. Given the above, in my view ANY generated test double, regardless of whether or not a call was made to make it go strict or to give it property behaviour, could have expectations set on it and later verified, and through any of the available syntactical elements for doing so. In this model, test doubles are just test doubles. For some you may just stub some behaviour, making them colloquial stubs. For some you may just set and validate some expectations, making them colloquial mocks. For others, you may do both simultaneously (and I often need to do so if I want to avoid over-specified tests.) Admittedly, the fact that I'm having to clarify this repeatedly is a possible sign that this exploration may not end up anywhere useful, but it may also just be a sign of a simple wire-crossing and we might end up somewhere much better. Either way, we'll have validation of whatever syntax results, and I'm all for validating things from time to time.

Jeremy Gray commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Wed, 02 Jul 2008 15:24:56 GMT

@Aaron - Expect is not a crutch, it is a way to set an expectation and provide a return value without doubling lines of code. Unless you consider ways of avoiding doubling lines of code to be a crutch. ;) @Bellware - The whole reason this discussion got started is because it is exactly the current terminology and, to a lesser degree, behaviour that is keeping this technology from being approachable by the masses, at least in terms of the masses I've run into. If by the end of this discussion we don't have something that clearly improves things well then I am all for leaving them as they are. After all, one needs to question their own assumptions from time to time. I recommend you give it a try.

Aaron Jensen commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Wed, 02 Jul 2008 07:18:01 GMT

According to MF's bliki ( http://www.martinfowler.com/bliki/TestDouble.html ) The only generic term is Test Double. That said, I don't particularly care for that term, and I think assigning terms to the objects themselves isn't as useful as using verbs to describe what you're doing to the methods. Since "Mocking a method" has less intrinsic meaning than "Expecting a method to be called" or "Specifying that a method should be called", I would just say you should use Mock. Take the term back and continue using it for the greater good. You create a mock. On that mock, you can stub methods, you can specify that methods should be called, you can forward methods to the real implementation, you can do whatever you want. Or just call it TestDouble.

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Wed, 02 Jul 2008 06:49:24 GMT

Scott, Fake has a meaning of its own in TDD terminology

Scott Bellware commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Wed, 02 Jul 2008 06:47:41 GMT

Have to give it more thought, but off the top of my head, maybe something as simple as: - Fake.Create() - Fake.Of()

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 13:46:09 GMT

Scott, A naming suggestion would be welcome.

Scott Bellware commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 08:46:39 GMT

I think "Test Double" is yet more obscure, self-indulgent pattern language that keeps mocking - and more importantly, the designs that it supports - from being more approachable by the masses.

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:23:11 GMT

I mean, we know how it works, and what the semantics are. What we are arguing about is what should be done to make this happen. In other words, we are discussing the facade that you will see as you work with Rhino Mocks

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:22:06 GMT

No need to be scared. It is just interception again. It is rhino mocks using rhino mocks to do its work, I consider this beautiful

jdn commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:21:06 GMT

How the API works is window dressing? Feh.

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:19:28 GMT

No need to be scared. It is just interception again. It is rhino mocks using rhino mocks to do its work, I consider this beautiful

Aaron Jensen commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:18:15 GMT

Ayende, Work and my desire to get MSpec into a more usable form preclude me from doing much else at the moment. Also, I'm a little frightened of the AssertWasCalled implementation, so I'm really scared of AssertOnlyTheseWereCalled :). Oh, and if I patched that my patch would include removal of Expect and VerifyAllExpecattions ;)

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:13:40 GMT

Aaron, I really want to get AssertOnlyTheseWereCalled, fancy committing that? For AssertWasCalledInOrder, it wouldn't work. Ordered is for cross mocks things.

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:12:12 GMT

The functionality is there, tested and is working. What we have left is the windows dressing.

Aaron Jensen commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:11:56 GMT

I would strongly recommend against StubUnexpectedInteractions. That should be the default behavior. I'd also recommend getting rid of Expect and VerifyAllExpectations, but I know my view is extreme. I'm yet to see a compelling argument for not doing AAA in all tests. If you want to ensure something wasn't called, you should assert it: mock.AssertWasNotCalled( x=>x.Foo()); If you want to make sure only what you expect to have been called was called, you should assert it: mock.AssertOnlyTheseWereCalled( x => { x.Foo(); x.Bar(); }); If you want to assert things were called in a particular order: mock.AssertWasCalledInOrder( x=>{ x.Foo(); x.Bar(); }); Obviously some of these things can be moved to the options, but you get the idea. Expect is a crutch and it obfuscates the true desire of the test.

jdn commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 02:00:10 GMT

This may be a stupid question, but if you are still deciding on how the API will work, how is Rhino.Mocks 3.5 a release candidate?

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 00:49:18 GMT

Graham, The methods are never on the class, they are extension methods

Graham Nash commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 00:45:24 GMT

I'd prefer to keep it as GenerateMock, GenerateStub, GeneratePartialMock, and GenerateStrictMock. First, it is more intention revealing. I know exactly what kind of test double I am working with. Second, there won't be any odd cases where methods either do nothing or should cause a failure because they won't be on the class. This is more object oriented also because all of the methods on the class will be supported. I don't think having to learn a couple of TDD terms is a large barrier for entry.

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 00:23:00 GMT

pb, Backward compatibility with 3.4 will be maintained. There is no concept of backward compatibility with the beta or RC.

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 00:18:28 GMT

Jeremy, A stub is something that will not fail the test.

Ayende Rahien commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Tue, 01 Jul 2008 00:16:58 GMT

Steve, Partial mocks _are_ supported, they just won't have a shortcut static method. Those mocks _will_ be able to take part in AAA syntax. The error you see is probably a bug, can you create a test case?

Jeremy Gray commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Mon, 30 Jun 2008 21:49:23 GMT

@pb - oh, definitely. The traditional syntax will be sticking around, from what I would guess at the moment. As for the AAA syntax, on the other hand, it has never been officially released so what we're trying to do at the moment is nail that syntax down so that it can last a long while upon release.

Steven Harman commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Mon, 30 Jun 2008 21:22:30 GMT

So, just to be clear... are Partial mocks no longer supported via the AAA Syntax? I have a case where I've created a partial Mock via an explicit repository, then as part of a shared test context I've stubbed out a public virtual method on that mocked object (via myPartialMock.Stub(x => x.foo())...). Arrange is now done and so I switch the partial to replay mode via mocks.Replay(myPartialMock). I then Act on a different method on the partial. myPartialMock.bar(); Next I want to myPartialMock.AssertWasCalled(x => foo()), but I get a Rhino.Mocks exception saying that "System.ArgumentException: Constructor arguments should not be supplied when mocking an interface." I'm guessing that some changes happened between 3.5 beta and RC to cause this to no longer be a valid scenario?

pb commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Mon, 30 Jun 2008 20:14:13 GMT

Er, backwards compatibility would be nice too...

Jeremy Gray commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Mon, 30 Jun 2008 20:10:02 GMT

(where #1 in the above essentially allows one to push the test double towards the classic CreateMock behaviour and #2 in the above essentially allows one to push the test double towards the current AAA GenerateStub behaviour)

Jeremy Gray commented on Rhino Mocks 3.5 Design Decisions: Getting closer to conclusion

Mon, 30 Jun 2008 20:07:55 GMT

But one can already do that by calling .Stub instead of .Expect. My assumptions previously centered on the default behaviour being more strict-mock-like, which drove the suggestion for StubUnexpectedInteractions(). Assuming the centering of default behaviour on what would previously have been known as a dynamic mock allows me to throw StubUnexpectedInteractions away and ask this: Setting aside for the moment whether or not one should be able to set expectations on "stubs", don't we just need to be able to control the following (in addition to calling .Stub and/or .Expect): 1. Strict versus loose (default is loose, strict via something along the lines of FailOnUnexpectedInteraction()) 2. Property and event backing store implementation versus not (default is presumably not) ? In parallel with this, what in the end really makes a stub a stub: a) property behavior? b) lack of expectations? c) inability to set expectations? Some combination?