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

Answer 1

Make sure to include what is not an unit tests. See: What not to test when it comes to Unit Testing?

Include a guideline so integration tests are clearly identified and can be run separately from unit tests. This is important, because you can end with a set of "unit" tests that are really slow if the unit tests are mixed with other types of tests.

Check this for more info on it: How can I improve my junit tests ... specially the second update.

Answer 2

Another item you can put in your standards is to try and keep your unit test size small. That is the actuall test methods themselves. Unless you are doing a full integration unit test there usually is no need for large unit tests, like say more than 100 lines. I'll give you that much in case you have a lot of setup to get to your one test. However if you do you should maybe refactor it.

People also talk about refactoring there code make sure people realize that unit tests is code too. So refactor, refactor, refactor.

I find the biggest problem in the uses I have seen is that people do not tend to recognize that you want to keep your unit tests light and agile. You don't want a monolithic beast for your tests after all. With that in mind if you have a method you are trying to test you should not test every possible path in one unit test. You should have multiple unit tests to account for every possible path through the method.

Yes if you are doing your unit tests correctly you should on average have more lines of unit test code than your application. While this sounds like a lot of work it will save you alot of time in the end when comes time for the inevitable business requirement change.

Answer 3

I've found that most testing conventions can be enforced through the use of a standard base class for all your tests. Forcing the tester to override methods so that they all have the same name.

I also advocate the Arrange-Act-Assert (AAA) style of testing as you can then generate fairly useful documentation from your tests. It also forces you to consider what behaviour you are expecting due to the naming style.

Answer 4

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 5

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.

Answer 6

I use nearly plain English for my unit test function names. Helps to define what they do exactly:

TEST( TestThatVariableFooDoesNotOverflowWhenCalledRecursively )
{
/* do test */
}  

I use C++ but the naming convention can be used anywhere.