So in search of some wisdom, I read: The art of unit testing (first version).

Its an easy read and contains some useful ideas for helping me come up with a plan for my testing.  I also read a few articles and blogs online and took some inspiration from Phil Haack in his post: Structuring Unit Tests.

I came up with the following guidelines for myself

[title style=”2″]The solution structure[/title]

I have the following solution structure for my application:

Guideline 1 – Tests are placed in separate assemblies from normal code.

This keeps things nice and organized.  I can easily find my tests and they do not clutter my normal code.

Guideline 2 – Separate integration tests from unit tests.

This separates the tests which are quick to run and do not depend on external dependencies, from the tests which are slower to run and might depend on some external dependency like a database or file system.

The idea behind this is that a developer should be eager to run the unit tests because they are easy to run.

[title style=”2″]Structuring the tests[/title]

I use the following guidelines to structure my tests:

Guideline 3 – Try to mimic the application structure in The test project.

This makes it easy to find tests.  This also helps me when I need to figure out where to put new tests.

Guideline 4 – Have 1 test class for each class you want to test.

If I need to write tests for a class called: FileSystemChannel, I will create a class: FileSystemChannelTests (in its own FileSystemChannelTests.cs file), which will contain the tests.

This again makes it easier to find the tests for a specific class, especially if you have something like ReSharper installed (using the Ctrl+Shift+T shortcut).

Guideline 5 – Create nested classes for each member of the class under test.

[alert type=”info”] NOTE: the FileSystemChannelTests class is not marked as a [TestFixture].  This is so that the ReSharper test runner will not mark that class as ‘inconclusive’ when you run the tests.  The reason ReSharper reports the FileSystemChannelTests class is inconclusive is because of the class nesting that is not supported right now by NUnit, but should be in a future release. [/alert]

This helps organise the tests in the FileSystemChannelTests class into sub-categories, one for each member of the class being tested.

If I am testing a GetFileIds() method, I will create a GetFileIdsMethod nested class to indicate what member I am testing and if it is a method or property.

Then inside the GetFileIdsMethod nested class, write a test method for each attribute that the member under test should have.

Guideline 6 – Name nested classes and test methods so they convey what attribute a member should have.

The names of the nested classes and test methods are chosen so they read like English:

FileIdFromStringMethod ReturnsTextFileIdForNormalFileName