title: TDD: Which methods do you expose for unit testing?
body: <p>There is one aspect of TDD which I never fully understood.</p>
  
  <p>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: <code>push()</code>, <code>pop()</code> and <code>isEmpty()</code>. Anything more than that is over-killing the demand, and allowing the user too much room to mess with your code.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>How do you handle this dilemma of opening public methods for testing vs. a clean and simple API?</p>
  
  <p><strong>Edit:</strong> 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.</p>