Writing standards for unit testing

Question

I plan to introduce a set of standards for writing unit tests into my team. But what to include?

These two posts (Unit test naming best practices and Best practices for file system dependencies in unit/integration tests) have given me some food for thought already.

Other domains that should be covered in my standards should be how test classes are set up and how to organize them. For example if you have class called OrderLineProcessor there should be a test class called OrderLineProcessorTest. If there's a method called Process() on that class then there should be a test called ProcessTest (maybe more to test different states).

Any other things to include?

Does your company have standards for unit testing?

EDIT: I'm using Visual Studio Team System 2008 and I develop in C#.Net

Answer 1

Have a look at Michael Feathers on what is a unit test (or what makes unit tests bad unit tests)

Have a look at the idea of "Arrange, Act, Assert", i.e. the idea that a test does only three things, in a fixed order:

• Arrange any input data and processing classes needed for the test
• Perform the action under test
• Test the results with one or more asserts. Yes, it can be more than one assert, so long as they all work to test the action that was performed.

Have a Look at Behaviour Driven Development for a way to align test cases with requirements.

Also, my opinion of standard documents today is that you shouldn't write them unless you have to - there are lots of resources available already written. Link to them rather than rehashing their content. Provide a reading list for developers who want to know more.

Answer 2

You should probably take a look at the "Pragmatic Unit Testing" series. This is the C# version but there is another for Java.

With respect to your spec, I would not go overboard. You have a very good start there - the naming conventions are very important. We also require that the directory structure match the original project. Coverage also needs to extend to boundary cases and illegal values (checking for exceptions). This is obvious but your spec is the place to write it down for that argument that you'll inevitably have in the future with the guy who doesn't want to test for someone passing an illegal value. But don't make the spec more than a few pages or no one will use it for a task that is so context-dependent.

Update: I disagree with Mr. Potato Head about only one assert per Unit Test. It sounds quite fine in theory but, in practice, it leads to either loads of mostly redundant tests or people doing tons of work in setup and tear-down that itself should be tested.