title: Is unit testing alone ever a good reason to expose private instance variables via getters?
body: <p>I have a class used for navigating back and forth through a list of ordered pages. The pages are generally but not always accessed sequentially. Sometimes one or more pages may be skipped based on certain rules.</p>
  
  <p>To manage this, I maintain two stacks, forward and backward, to track which pages have previously been visited in either direction.</p>
  
  <p>As far as the functionality of this class is concerned, there is no reason for it to expose these stacks. However, when unit testing the navigation methods, <code>first()</code>, <code>next()</code>, <code>previous()</code> and <code>last()</code>, which all reorganize the stacks and return the appropriate page, I need to check that the stacks are in the right "state" at the end of the process.</p>
  
  <p>For example, calling <code>first()</code> should cause the forward stack to be cleared and every other page that has previously been visited to be pushed into the backward stack.</p>
  
  <p>Is this alone a good enough reason to provide getters for the forward and backward stacks? One reason I am hesitant to do so is that I worry that this also exposes them to (perhaps inadvertent) outside manipulation that might cause the class to malfunction. What if a client clears a stack for example?</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>Some people have suggested that this question is a duplicate of the one posted <a href="https://stackoverflow.com/questions/7075938/making-a-private-method-public-to-unit-test-it-good-idea">here</a>. I think the 2 questions aren't quite the same. The other question discusses the idea of <strong>refactoring a private method to make it public in order to be able to test it</strong>. This question, on the other hand, is specifically about <strong>testing public methods by examining the internal state of the object under tes</strong>t. I think there is a subtle but significant difference there, and the accepted answer clearly shows how to test the very same public methods without examining internal state.</p>