title: Unit testing private code
body: <p>I am currently involved in developing with C# - Here is some background:
  We implement MVP with our client application and we have a cyclomatic rule which states that no method should have a cyclomatic complexity greater than 5.
  This leads to a lot of small private methods which are generally responsible for one thing.</p>
  <p>My question is about unit testing a class:</p>
  <p>Testing the private implementation through the public methods is all fine... I don't have a problem implementing this.</p>
  <p>But... what about the following cases:</p>
  <blockquote>
  <p><strong>Example 1.</strong> Handle the result of an async data retrival request (The callback method shouldn't be public purely for testing)</p>
  <p><strong>Example 2.</strong> An event handler which does an operation (such as update a View label's text - silly example I know...)</p>
  <p><strong>Example 3.</strong> You are using a third party framework which allows you to extend by overriding protected virtual methods (the path from the public methods to these virtual methods are generally treated as black box programming and will have all sorts of dependancies that the framework provides that you don't want to know about)</p>
  </blockquote>
  <p>The examples above don't appear to me to be the result of poor design.
  They also do not appear be be candidates for moving to a seperate class for testing in isolation as such methods will lose their context.</p>
  <p>Doesn anyone have any thoughts about this?</p>
  <p>Cheers,
  Jason</p>
  <p><strong>EDIT:</strong>
  I don't think I was clear enough in my original question - I can test private methods using accessors and mock out calls/ methods using TypeMock. That isn't the problem. The problem is testing things which don't need to be public, or can't be public.</p>
  <p>I don't want to make code public for the sake of testing as it can introduce security loopholes (only publishing an interface to hide this is not an option because anyone can just cast the object back to its original type and get access to stuff I wouldn't want them to)</p>
  <p>Code that gets refactored out to another class for testing is fine - but can lose context. I've always thought it bad practice to have 'helper' classes which can contain a pot of code with no specific context - (thinking SRP here). I really don't think this works for event handlers either.</p>
  <p>I am happy to be proven wrong - I just am unsure how to test this functionality! I have always been of the mind that if it can break or be changed - test it.</p>
  <p>Cheers, Jason</p>