Unit Testing Internal Types (2)

It works!

In a previous article, I discussed unit testing internal classes which are typically instantiated using Reflection and are accessed via a Facade.

Learnings: When TestDriven.NET runs NUnit tests through the IDE, configuration values seem to be pulled from testassembly.dll.config.temp, while the specified configuration file is used if run through the NUnit GUI.

These files would have to be replaced with our custom content, to test the internal component, through the Facade.

Anyway, I scrapped together a helper class that would handle copying of the configuration content (overloads for config content as a string and alternatively, a source config file). The [TestFixtureTearDown] method is used to restore the original configuration, while individual [Test]s can use the helper to copy the relevant config file for running.

I'm glad that it worked, but given that it's a hacked together solution, could stop working with any forthcoming release of NUnit (e.g. if config files are locked for the duration of execution etc.).

Steven Cohn (in his blog) made good sense about not modifying the 'System Under Test', in order to test it. The only thing I've got to say about 'pragmatic unit testing' is, given all the restrictions in testing internal types, the most pragmatic thing would be to stop unit testing... :P

You'd think I'd be happy at having solved the problem (hack or otherwise), but strangely, jumping through hoops does sweet nothing for the temper! ;-)

Unit Testing Internal Types

Problem: .NET classes of 'internal' visibility to be unit tested (in this case, using NUnit).

Complication: These classes are part of a 'provider' model (pluggable components instantiated via a Factory Method implementation, based on configuration settings). Access to the functionality to be tested would be via a Facade class, which looks up configuration and instantiates the relevant type using Reflection.

Known Solutions:

• Use of Friend assemblies - however, to maintain security (ensuring only our Unit Test assembly invokes the internal types) we would need to strong name our assembly under test. This has a cascading effect, as all its references then need to be strong named. Not an option, when you consider that we might have a reference on an external vendor's component somewhere down the dependency chain.
• Writing the Unit Tests in the same assembly - which clutters up the codebase goodstyle.
• Write Reflection based wrappers (a la VSTS) - which the Professional edition of VS2005 does not have.

Yet another solution?

I'm sure there is a downside to the following approach, which I'm going to find out about the hard way - but till then:

The complication states that the required values need to be pulled from configuration. What price placing the default configuration file in the execution path during the method marked with [TestFixtureSetUp], to be overwritten at the beginning of the individual [Test] method by a separate configuration file containing the relevant settings, methinks... all this is very much guesswork, depending on NUnit allowing the configuration file to be overwritten.

I'm thinking a feature in NUnit like the VSTS [DeploymentItem] attribute would have been very helpful in this scenario...

Will blog about whether this works... if it works!

And about time too!

Continuous Deprioritization: the reason why I never got around to running a blog thus far. After deliberating and procrastinating for a couple of years, I finally got around to starting up this blog.

And just like *that*, the words run dry!