Question

After comming from Ruby world, I’m having little problems doing TDD in Java. The biggest issue is when I have application that is just communicating with external API.

Say I want to just fetch some data from Google Calendar, or 5 tweets from some Twitter user and display it.

In Ruby, I don’t have any problems, because I can monkey-patch the API library in tests directly, but I have no such option in Java.

If I think about this in terms of MVC, my model objects are directly accessing the API through some library. The question is, is this bad design? Should I always wrap any API library in some interface, so I can mock/stub it in Java?

Because when I think about this, the only purpose of that interface would be to simulate (please don’t kill me for saying this) the monkey-patch. Meaning that any time I use any external resource, I have to wrap each layer in interface that can be stubbed out.

# do I have to abstract everything just to do this in Java?
Twitter.stub!(:search)

Now you might say that I should always abstract away the interface, so I can change the underlying layer to anything else. But if I’m writing twitter app, I’m not going to change it to RSS reader.

Yes, I can add for example Facebook and then it would make sense to have interface. But when there is no other resource that can be substituted for the one I’m using, than I still have to wrap everything in interfaces to make it testable.

Am I missing something, or is this just a way to test in the Java world?

Answer 1

Using interfaces is just generally good practice in Java. Some languages have multiple inheritance, others have duck typing, Java has interfaces. It’s a key feature of the language, it lets me use

1. different aspects of a class in different contexts and
2. different implementations of the same contract without changing client code.

So interfaces are a concept you should embrace in general, and then you would reap the benefits in situations like this where you could substitute your services by mock objects.

One of the most important books about Java best practices is Effective Java by Joshua Bloch. I would highly suggest you to read it. In this context the most important part is Item 52: Refer to objects by their interfaces. Quote:

More generally, you should favor the use of interfaces rather than
classes to refer to objects. If appropriate interface types exist, then parameters, return values, variables, and fields should all be declared using interface
types. The only time you really need to refer to an object’s class is when you’re
creating it with a constructor.

And if you take things even further (e.g. when using dependency injection), you aren’t even calling the constructor.

One of the key problems of switching languages is that you have to switch the way of thinking too. You can’t program language x effectively while thinking in language y. You can’t program C effectively without using pointers, Ruby not without duck typing and Java not without Interfaces.