Following Gerard Meszaros: “Good names help us communicate the concepts”.
There is this Test Spy framework I worked on lately. Unfortunately, it doesn’t use ‘test spy’ metaphor at all. It talks about ‘mocks’ all the time. Some even say that the name of the library has something to do with mocking…
Was I just a foolish ignorant who didn’t want to acknowledge different kinds of mocks. Ouch! I should say: Test Doubles. In case you haven’t heard about Doubles: all those substitutes of real objects that make testing simpler or faster or more maintainable. I like them because they shrink the unit under test and make it easier to test.
I like simplicity. Introducing new concepts doesn’t make things simple. Do I really need Double, Dummy, Fake, Mock, Spy and Stub to write decent code? On the other hand, I definitely need them to communicate how to write decent code.
At the back of my weird mind I used to think that Test Double breakdown was a bit disconnected from the reality where subtle differences are blurred (and the existing tools/libraries didn’t really reduce the confusion). I tried to keep things plain but I reached the boundary: trying to keep things simple (and sticking to mocks and stubs) actually could have increased the confusion and made things complicated.
That’s why I’m about to sort out Mockito terminology. Better late than never, right?
In all of my previous posts ‘Mockito mock’ should be read ‘Test Spy’. But what’s the Test Spy anyway? Or better: what’s the difference between a Test Spy and a Mock? Both serve verifying interactions but the Spy is simple, lightweight and it gives very natural testing experience, close to good old assertions. Sounds interesting? Have a look at some of my previous rants or read this excellent post by Hamlet D’Arcy (don’t miss Collaborator Continuum).
Let’s get back to my favourite Test Spy Framework. Do you think following changes makes things simpler and easier to understand (I don’t really know the answer…):
@Mock -> @Spy
mock(Foo.class) -> createSpy(Foo.class)
March 21, 2008 at 12:36 am |
I’m really glad you’re addressing the test spy issue. I totally agree that Test Spys are necessary to writing clear and concise mockist style unit tests. It was the largest take-away I had from Gerard Mezaros’ xUnit Patterns.
I think the Test Spy issue hasn’t gained traction for two reasons:
1: The only place I’ve seen them mentioned is in xUnit Patterns
2. As people learn to write unit tests, the progression from beginner to expert seems to progress from simple state tests, to hand rolled mocks, then to the most popular mock frameworks (EasyMock, jMock). Mockito is the first spy framework I’d seen released. I think Test Spys are the next step in test evolution as far as history goes, but I think they should be between “hand rolled mocks” and “mock frameworks” in the learning progression.
I really want to play with Mockito in the next couple weeks and I promise to let you know what I think. I think the potential is huge because of the over-specified software the record-playback encourages. Thanks for putting this out there!
March 23, 2008 at 8:07 pm |
This is really great. It’s so nice to get away from record/playback when it is unneeded. Here is my first impressions: http://hamletdarcy.blogspot.com/2008/03/mockito-new-mock-framework-on-block.html
March 31, 2008 at 8:00 pm |
sorry guys i am a bit late. but 1. mockito provides stubs and spys. and as it happens what mockito now calls a mock is both. so why not define: mock implements stub, spy. then we can safely carry on calling these things mocks. btw i have no idea how mezaros defines stub
.
April 9, 2008 at 1:28 am |
Personally, I’d prefer to keep calling them “mocks.” Three reasons:
1. Discoverability. Everyone knows that they need a mock framework — I have no idea why I’d need a “spy” framework. You’d have to educate everyone what Mockito (Spyito?
) even does before they’d realize that they’re interested in it. This kind of goes to Hamlet’s point about “Test Spy” not being a well-known term.
2. Consistency. Yes, yes — it’s fine to argue about language purity. But in my experience, the term “mock” has come to mean what language purists refer to as a “Test Double” — any object that can impersonate another and provide test support/verification. And that’s fine, right? There’s nothing inherently bad about calling those things “mocks.”
3. Catchiness. “Mock” sounds less intimidating than “Spy” and is catchier than “Test Double.”
Anyway, $0.02 from the peanut gallery.
July 12, 2008 at 5:33 pm |
[...] it’s relevant. That’s why I really like state based testing. That’s why I prefer spying to mocking. Finally, that’s why I don’t write verifyNoMoreInteractions() in every [...]