NUnit and your project

I was out with Slim the other day and we discussed how our current project is using NUnit and what difficulties we were running into with it.  This certainly wasn’t a discussion about how we should be implementing TDD or unit testing nor is that the motivation behind this post.

The way that we’ve built included the unit tests into our solution was to create a project that contains nothing but unit tests.  Our standard “functional” projects are all built with a mix of public, private and protected functions etc.  The unit test project then references each “functional” project, making it’s interfaces available for testing.  Each test in the unit test project calls the public interface from the “functional” projects.  This is model has made it very difficult to test any private or internal functions from the “functional” projects.

What we were thinking would be a good solution is to switch all our privates to protected.  This would allow us to keep the same public interface on our assemblies.  In our unit tests we would create classes that inherit the required class from our “functional” projects.  By doing this we now have access to the protected functions and methods in the inherited class.

The reason we got on this discussion is because I wrote a schwak of code that created line items, but ever function creating these line items was private and only exposed from a public function called CreateLines().  It’s very difficult to create a meaningful unit test when the CreateLines() function could generate close to a hundred separate line items.  Unfortunately this is all in hind site now.  I will be taking this lesson with me though.