How do you balance Framework/API Design and TDD

Question

We are building a framework that will be used by other developers and for now we have been using a lot of TDD practices. We have interfaces everywhere and have well-written unit tests that mock the interfaces.

However, we are now reaching the point where some of the properties/methods of the input classes need to be internal, and not visible to our framework users (for example object Id). The problem then is that we can't put those fields/methods on the interface as the interface does not describe accessibility.

We could:

1. Still use interfaces and upcast in the first line of the method, but that seems to defeat the purpose of interfaces.
2. Use classes as input parameters - breaking the TDD rule that everything should be interfaces
3. Provide another layer which does some translation between public interfaces and internal interfaces

Is there an existing pattern/approach to deal with this? What do the TDD people say should be done?

Answer 1

Sounds like you want your class to have a dependency injection. Search stackoverflow too. Then you can set this Id by your choice of either within constructor or through a setter.

[1l

Answer 2

You need to be able to replicate those internal methods in your mock up objects. And call them in the same way the real object would call them. Then you focus your unit test on the public method that relies on that private method you need to test. If these internal methods are calling other objects or doing a lot of work, you may need to refactor your design.

Good luck.

Answer 3

First, there is no general TDD rule that says everything should be an interface. This is coming from a specific style that is not practiced by every TDDer. See http://martinfowler.com/articles/mocksArentStubs.html

Second, you are experiencing the dichotomy of public vs. published. Our team "solved" this problem by introducing a @Published annotation that shows up in the API documentation. Eclipse uses naming conventions, as far as I know. I don't know of a really good solution to the problem, unfortunately.