I prefer the following test design rule for mock objects and test doubles. Object which contains logic e.g. of type service, factory or repository should be mocked instead of DTOs, value objects or entities (plain Java Beans) with getters and setters e.g. configuration objects this kind of object should never be mocked.
Here small example, a test with to much mocking, please don't write such kind of tests:
This simple unit test above has to much mocking logic and should be refactored to this test:
If you like you could use the builder pattern for the simple objects like sale to get the test a little bit nicer (see the links for eclipse tooling). A smell is when you need to mock classes, in most cases then you should use another test double pattern for this kind of objects, or something with the design of the SUT is wrong.
What I like to say is you should not always use our preferred mocking framework to create a mock object as test double for everything. There are situations where mock object I believe are a test design anti pattern / smell. Think about stubs and dummy object before creating a mock object and read the great xUnit test pattern book “xUnit Test Patterns” from Gerard Meszaros. Then you are on the right way to get an agile tester ;-)
Links
- xUnit Paterns - http://xunitpatterns.com/
- Test Double - http://xunitpatterns.com/Test%20Double.html
- Builder Eclipse Plugin - http://code.google.com/p/fluent-builders-generator-eclipse-plugin/
