Reflection or the "setter" antipattern?

Recently I came across an interesting dilemma. For some time up to now I've been including setter methods in my service interfaces to allow unit tests to setup mocks. The code though had a bad smell; all too often I kept asking the following question: why did my interfaces need to expose setters for internal details (e.g. the components used to achieve a certain functionality)? If I was a user of this API, would I like to see a bunch of setter methods which have nothing to do with the business functionality? All the time the answer was no.

An API should expose the minimum possible, both in terms of actual classes/operations and in terms of state. A business service is just that:  a collection of operations and state to perform some business functionality: exposing to clients setter methods which allow to setup the internal components is not necessary nor optimal; it just clutters the API with unnecessary signatures. This is what I call the setter antipattern.

So since I'm using Spring test support classes also for my unit testing, I came across the ReflectionTestUtil class, which in few words allows one to do so:

Service service = new ServiceImpl();

Dao dao = new ServiceDao();

ReflectionTestUtil.setField(service, "serviceDao", dao); //serviceDao should actually be a constant

With this class I can avoid exposing unnecessary setter methods in my interface (Service in this case) while still preserving encapsulation. However the price to pay is compile time check. Let's say that a refactoring renames the Service attribute "serviceDao" into something else, say "clientServiceDao" or whatever...Now my test is broken because the ReflectionTestUtil statement will fail.

So which one to chose? The setter antipattern or reflection? I think the answer depends on how much value one gives in keeping a clean API, free from boilerplate signatures. I realised that to me a clean API represents the greatest value, and if someone refactored my code by renaming variables used by the ReflectionTestUtil class, the tests would fail and the fix would be, although annoying, quite easy to make, especially if the field name was captured in a String constant.

From http://tedone.typepad.com/blog/2010/10/reflection-or-the-setter-antipattern.html