When using jmock, you can mock a concrete class if you set the class imposteriser. I noticed that the class imposterizer is in the legacy package, so I really don’t want to use it (especially because it super easy to extract an interface using the refactoring tools in my IDE). I don’t like to have instance variables of concrete classes either.
Extracting the interface, however, I’ve noticed a pattern emerging in my code base. A lot of the time an interface has only one implementing concrete class. I prefer to use an interface wherever possible, but it seems really verbose to have all these extra files. Also, it’s slightly tedious to update the interface and update the implementer every time I want to add a new method to the class.
Is this just the price you pay for proper abstraction or is there a better approach that I haven’t thought of? Should all classes implement an interface even if the only thing in the interface is getters/setters?
If the interface is only getters and setters, that sounds like it’s more to do with data than behaviour – and doesn’t sound like the sort of thing I’d mock. I’m happy to use simple production code directly within tests for other classes. I only inject dependencies for classes providing services.
I feel your pain, but personally I do still write the interface, even if there’s currently only one production implementation. Quite often I’ll find I write a stub or fake implementation as well after mocking for a while. Fakes can end up being rather simpler to use (leading to clearer tests) unless you’re really interested in testing the interaction between the caller and the service.
It also means that when someone wants to look at methods a particular dependency provides, they can see just the interface with no implementation involved.