aspose file tools*
The moose likes Testing and the fly likes Tomek's opinion on Fowler's opinion on mocking... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Tomek Watch "Tomek New topic
Author

Tomek's opinion on Fowler's opinion on mocking...

andrew ennamorato
Ranch Hand

Joined: Oct 03, 2007
Posts: 100
Martin Fowler said "I don't see any compelling benefits for mockist TDD, and am concerned about the consequences of coupling tests to implementation." in his classic Mocks aren't Stubs post.

I agree somewhat, yet at the same time often find myself using a mock because it just seems to make sense. So I'm curious what Tomek's opinion of mocking in general is, and also how much time is devoted to that in the book (i.e. is Mockito just a few sections, or is mocking used throughout).

Thanks!
Tomek Kaczanowski
author
Ranch Hand

Joined: Oct 26, 2005
Posts: 40

Hi Andrew,

thanks for this interesting question. it is hard for me to directly discuss Fowler's word, but I will share some comments with you regarding mocking in general.

First of all, please note that the article you mention comes from January 2007, which is long time ago. In 2007 we had neither the tools, nor the knowledge and experience that we have now. Now to the main point.

I would say that currently we have a pretty good understanding of what is worth mocking. Following Gerard Meszaros' advice - "use the front door" - we should always try to use state testing (that is verify the outcome and/or state) instead of interactions testing. This should prevent us from writing tests, which are tightly coupled to implementation. Second, we know that only some types of collaborators - i.e. "services", which offers some functionalities - are worth mocking (in contrast to "value objects" - see here). This helps to avoid unreadable tests.

For me, TDD + mocking makes sense, as long as I stick to these two guidelines, and write small, focused tests. TDD + mocking prevents me from doing typical design errors like breaking the Law of Demeter or Tell Don't Ask principle.
Currently available mocking frameworks (i.e. Mockito) helps you to achieve this, by giving you strict control over what is being verified, thus making your tests not-so-tightly-coupled to the implementation. However, there is always a price involved when using mocks - because they make assumptions about the implementation of tested object (i.e. about the fact that X sends message Y to Z) they are always prone to break when the code changes.

As for the book, it definitely discusses mocking. There is a separate chapter (~50 pages) devoted solely to dealing with collaborators (it also introduces Mockito and ends with a detailed example of TDD+Mockito). Then, in consecutive chapters there are selected sections devoted to specific mocking-related issues: stubbing of void methods, using of Mockito matchers, dealing with "new" operator and capturing of arguments passed to collaborators, syntactic sugar of Mockito (Mockito annotations and BDD support). There are also some hints and comments regarding tests with mocks within the last chapters which are related to tests quality and maintainability issues (BTW. you can find book's ToC on book's site).





Tomek Kaczanowski
Book author: Practical Unit Testing with TestNG and Mockito
http://practicalunittesting.com
andrew ennamorato
Ranch Hand

Joined: Oct 03, 2007
Posts: 100
Wow, awesome answer, thanks!! (Although, you referenced an article from 2007, too ).

Looking forward to checking out the book.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Tomek's opinion on Fowler's opinion on mocking...