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)