Mark Needham

TDD: Hungarian notation for mocks/stubs

with 9 comments

[Test]
public void ShouldDoSomething()
{
	var someDependency = MockRepository.CreateMock<ISomeDependency>();
 
	someDependency.Expect(x => x.SomeMethod()).Return("someValue");
 
	var myController = new MyController(someDependency);
        myController.DoSomething()
 
	someDependency.VerifyAllExpectations();
}

[Test]
public void ShouldDoSomething()
{
	var someDependencyMock = MockRepository.CreateMock<ISomeDependency>();
 
	someDependencyMock.Expect(x => x.SomeMethod()).Return("someValue");
 
	var myController = new MyController(someDependencyMock);
        myController.DoSomething()
 
	someDependencyMock.VerifyAllExpectations();
}

[Test]
public void ShouldDoSomething()
{
	var someDependencyMock = MockRepository.CreateMock<ISomeDependency>();
 
	someDependencyMock.Stub(x => x.SomeMethod()).Return("someValue");
 
	var myController = new MyController(someDependencyMock);
        myController.DoSomething()
}

9 Responses to 'TDD: Hungarian notation for mocks/stubs'

Subscribe to comments with RSS or TrackBack to 'TDD: Hungarian notation for mocks/stubs'.

1. Interesting, I like adding Mock to the end of the mocked dependency exactly because then I don't have to go where it was assigned but can just read the test. Also for small tests. Have you seen my Specifications post? There I auto mocks and use a different way to acces the mocks using a small DSL. What are your thoughts on that?

   

   Mark Nijhof

   6 Jan 10 at 12:48 am
2. Hi Mark,

   I tent to agree with you, however I sometimes use the 'hungarian notation' approach when coaching people who are new to mocking and stubbing and who can often have trouble distinguishing between what is a mock and what is a real object in even quite simple tests.

   I find it helps avoid a surprisingly common problem with beginners where they set an expectation, and then fulfill that expectation in the test rather than in the implementation.

   Also, then if I come across a test with a stub mislabeled as a mock then that gives me a clue that the person that wrote it is having trouble understanding the difference.

   

   Perryn Fowler

   6 Jan 10 at 12:55 am
3. I tend to use mockSomething or stubSomething, but I think I might drop that.

   One thing I do with Mockito is create "mocks" of dependencies I don't care about for this test and call them dummySomething. I do this rather than pass in null (don't get me started on null =))

   

   Andy Palmer

   6 Jan 10 at 1:24 am
4. @Perryn ah that's interesting I hadn't thought of it from that perspective. That makes sense.

   @Andy hmmm that's a cool idea, don't think I've seen that so explicitly done before. Might give that one a try!

   @Mark I think I might have seen that but I'd need to re-read it. Do you have a link to it?

   

   Mark Needham

   6 Jan 10 at 7:42 am
5. Mark,

   My personal preference is to just never use CreateMock. In my mind, instances are not mocks or stubs–you either stub or mock methods. It's entirely possible to stub MethodA on IFoo and mock MethodB.

   Rhino makes this easy–just use CreateStub (always) and use .Stub or .AssertWasCalled. CreateMock causes more coupling than I think is healthy in a test. If you want to assert that something was not called, use AssertWasNotCalled. It's very rare that I actually want to spec out that *nothing* was called on a dependency other than one thing. That's just the kind of coupling that leads to brittle unit tests.

   Oh and back to the point of your post, I don't like the suffix either. It is what it is, the fact that parts of it are mocked or stubbed is evident by the .Stub or .AssertWasCalled calls.

   

   Aaron Jensen

   6 Jan 10 at 8:26 am
6. When looking at a test I personally want to know where an object is a test double. However I'm not bothered whether its specifically a stub or mock (far better seeing that from its usage), I'd be happy with one or other term used consistently or just use of nameTestDouble.

   

   Colin Jack

   6 Jan 10 at 2:34 pm
7. I also favor not specifying whether the dependency is a mock or stub. However, if I feel the need to make it clear that it is not "real" code being used, I like to just use the word fake. So I would use "someFakeDependency". I guess this is similar to Andy's idea of using "dummy" but to me "fake" is more a part of the testing lexicon.

   

   MM

   6 Jan 10 at 2:36 pm
8. I like to name the variable for the role the object is acting in too, I agree that "mock" or "stub" is unecessary noise.

   I'm only interested in the role something is playing and the interactions it has; I don't care what it is. What the thing is actually is (mock, stub, spy) is something I find only changes as the code changes so I want that detail to leak into the test as little as possible.

   

   Brent Snook

   6 Jan 10 at 2:56 pm
9. @MM I have used a number of different test double type names (including fake) when that is how I am using it… I think this might be introducing more noise than I need.
   On the other hand, I use dummySomething to specifically indicate that this is not being used in this test… if a test fails because a mock didn't respond correctly and it's called dummySomething, that gives me a clue that something new is happening in the real code

   

   Andy Palmer

   8 Jan 10 at 12:55 am

Leave a Reply