The latest BileBlog from Hani strangely resonated with me today:
So what’s the acid test for a good design? I have no idea. The closest I could come up with is A good design allows your code to do things you never expected it to have to do. It’s not about ‘oh I’ll add an interface here so I can plop in different implementations’ when there’s no sane reason you’d ever need more than one implementation, for example. […] For example, there are interfaces for simple objects that have both getters and setters specified, which makes creating a read-only implementation pretty unpleasant. I’d also argue that putting getter+setter style methods in an interface is an implementation leak anyway, mind you.
I just started working on a new project and the colleague I’m working with on it insists on putting interfaces on everything, even on beans which are mostly just containers for properties. And of course, getters and setters are specified in the interface.
I think getters and setters are indeed evil, but they are a necessary evil when your objects are used as containers for data to be shipped back and forth between a GUI and a database. They do not certainly belong to the interface, though.
I’d also argue that specifying an interface for these kind of (pseudo) objects is way overkill. The problem is he is also heavily into TDD, which I heartily applaud, but somehow thinks it’s necessary to test everything via mock objects, which requires having interfaces.
This goes to the point of mocking an OrderItem implementation to test that Order.getTotalAmount will call OrderItem.getQuantity and OrderItem.getPrice once for each OrderItem, which I find a bit too extreme.
Personally, I find this type of test to be:
- Overspecified, as it does not just test that the correct amount is computed, but also that it is done following a specific algorithm.
- Brittle, as the algorithm might change and we couldn’t care less as long as the correct result is computed, but we would be forced to rewrite the test.
- An abuse of mock objects, which IMHO should be used to avoid dependencies on concrete implementations of external APIs. The same test, assuming it made sense, could be implemented in the traditional way without mock objects.
- Much less readable than a traditional test.
I’m afraid all this TDD stuff, which is certainly valuable if done sensibly, is becoming to be abused as a means for avoiding to have to think about a proper design beforehand, as Hani hints to in hist post.
On the other hand, I will readily admit of being way too lazy in writing proper test cases, so I’ll concede the benefit of doubt. Maybe we can find a comfortable middle ground and I can start being more test-infected, which would be good.
What do you think?
You don’t have to use interfaces to mock things. Maybe you should try a different mocking library. We use jmock and you can mock against interfaces and concrete classes.
My two pence is that if it is hard to test the design is wrong.
Well, some points to consider:
- Interfaces (Java interfaces I mean) are not mandatory to drive developing using mocks. Jmock/Cglib version can mock concrete classes. Maybe are there for some other reasons.
- Behavioral testing doesn’t force a specific algorithm but a specific set of outgoing relationships and thus interfaces (in a broader sense, not Java interfaces). How those relationships are then used is not forced but of course their presence is checked.
- Mocking system boundaries is one way to use mock objetcts, not the only one. In this case I call them Stubs.
- I agree that behavioral test are less readable (more lines to read instead of state testing), but I think it dependes on the mocking framework.
- I don’t think that testing behavior is a way to avoid front design. Instead it forces you to think about a division of responsabilities exactly the same a CRC session can do. And a CRC session is a light-weight front design.
Have a look at http://www.jmock.org/oopsla2004.pdf and http://martinfowler.com/articles/mocksArentStubs.html for an in-depth.