title: Unit testing and too many mocks
body: <p>I'm starting to practice TDD in my project, as a background it also contains legacy code. We use Mockito as a mocking framework and follow a Spring MVC approach. </p>
  
  <p>There are times when there's a <code>Service</code> class implemented with many different <code>DAO</code> objects as <code>@Autowired</code> properties. There are simple methods within these services, like for example <code>completeTransaction</code>. </p>
  
  <p><code>completeTransaction</code> will use many of the <code>DAO</code> objects to complete its responsibilities </p>
  
  <ul>
  <li>Update and save the transaction</li>
  <li>Advance a business process</li>
  <li>Closing other pending operations</li>
  </ul>
  
  <p>However, in performing those operations, the method requires calls to different <code>DAO</code> to fetch and update the transaction, fetch a business process ID, fetch pending transactions (and save their updates). This means that unit testing this method makes me add many <code>@Mock</code> properties. And I need to set up the mock objects before the test will actually finish for me to test a certain condition.</p>
  
  <p>This seems like a code smell, and to me it almost feels like the test is ensuring the implementation of the code instead of just its contract. Again, without mocking the dependencies, the test case will not run (due to NPE and others).</p>
  
  <p>What is a strategy that I can follow to clean up code like this? (I can't really provide the actual source code on the question though). I'm thinking that one possibility would be to set up a facade class with methods like ("getPendingOperations" and "advanceBusinessProcess"). Then I can mock a single dependency. But then I figure that in all other classes that have situations like this I would need to do the same, and then I'm afraid to end up with a lot of "helper" classes just for the sake of cleaner tests.</p>
  
  <p>Thank you in advanced.</p>