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.