Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

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

 
andrew ennamorato
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 40
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).




 
andrew ennamorato
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wow, awesome answer, thanks!! (Although, you referenced an article from 2007, too ).

Looking forward to checking out the book.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic