TDD: Which methods do you expose for unit testing?

Question

There is one aspect of TDD which I never fully understood.

Suppose somebody asked you to implement a simple Stack object. If you've done your design properly, you will come to a very minimal and clean API. Suppose: push(), pop() and isEmpty(). Anything more than that is over-killing the demand, and allowing the user too much room to mess with your code.

So now let's suppose you want to unit test your code. How do you go about doing this if all your public methods are just the three shown above? Those methods will take your testing only so far.

So either you add private methods, which do not help you at all since they are not visible to your unit test case. Or you make those methods public and there goes your minimalistic API which you worked on so hard. Now the user is going to mess with your Stack and the bugs will be sure to come.

How do you handle this dilemma of opening public methods for testing vs. a clean and simple API?

Edit: just to point in the right direction, It would be nice to get technical pointers (such as "use this hack to expose private methods", etc...) but I am much more intrested in more generic answers as to what of the two concepts is more important, and how you approach this subject.

Answer 1

1. test the features; this usually means testing the public interface - for should not all features be accessible via the public interface? if they aren't, then they aren't features! There may be exceptions to this, but i can't think of any.

2. test the public interface; any methods that are not called directly or indirectly from the public interface are not necessary. Not only do they not need to be tested, they do not need to exist at all.

Answer 2

You should take a look at that question : do you test private method?.

To not break the encapsulation, I find that the private method is huge or complex or important enough to require its own tests, I just put it in another class and make it public there (Method Object). Then I can easily test the previously-private-but-now-public method that now lives on it's own class.