Usually when talking about coding standards we refer to the code of the program itself, but what about the unit tests? Are there certain coding standards guidelines that are unique to unit tests? What are they?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
Off the top of my head, I can think of three differences in coding style for test code.
In naming test methods, I follow the pattern of
Inside the test, it is customary to follow the following spacing pattern:
Some insist on only one assertion per test, but this is far from universal.
The DRY (Don't Repeat Yourself) is less of a consideration in test code than in production code. While some repeated code should be placed in a setUp method or a testUtils class, striving for zero repetition in test code will lead to tightly coupled and inflexible tests, which discourages refactoring.
Roy Osherove recommends the following pattern for naming your tests:
The main thing is to remember that unit tests are essentially mini-specifications. This means that the emphasis must always be on readability.
Firstly, this means that names must clearly communicate what is under test and what is being asserted.
Secondly though, which is sometimes forgotten, is that as specifications they should be doing just that - specifying behaviour. That is, unit tests should not contain logic - or potentially they fall into the trap of repeating the program's functionality rather than testing it.
Sometimes the tests will involve objects which are complex to set up, you should strive to keep this set up logic separate from your tests using something like an object mother or a test data builder.
I'll just round off with a few book recommendations:
xUnit Test Patterns: Refactoring Test Code: Excellent book, some say it's a bit dry but I don't think so. Goes into a lot of detail about lots of different ways of organising tests and how to keep them maintainable. Relevant if you're using something like NUnit etc.
The Art of Unit Testing: With Examples in .Net: The best book on the nitty-gritty of writing and maintaining tests. Despite being really new I find the mocking sections a little dated already as AAA syntax is now pretty standard rather than just another way of doing it.
Growing Object-Oriented Software, Guided by Tests: This book is just amazing! By far the best unit testing book and the only advanced one which puts unit testing as a first class citizen in the design process. Was reading this when it was a public beta and been recommending since. Excellent real-worldish worked example used throughout the book. Would recommend reading Roy's book first though.
Don't put logic in your unit tests. For example, let's say you're testing an add method, you could have something like this:
In this particular case, you're likely repeating the same logic as what's in the test, so you're essentially testing "1 + 1 == 1 + 1", rather than "1 + 1 == 2", which is the "real" test. So what you would really want your test code to look like is:
This blog post provides a pretty thorough summary of guidelines to follow for unit testing:
Tell me what you think.
Somewhat similar to what Farmboy has already mentioned, My method name format
Long, descriptive method names. Remember, test methods are never called from code (they're called by the unit test runner that discovers and calls them via reflection), so it's OK to go crazy and have method names 50-80 characters long. Specific naming convention (camel-case, underscores, "should", "must", "when", "given", etc.) is not really important as long as the name answers three questions:
Test methods should be short.
Test methods should have a simple, linear structure. No if or loop constructs.
Test methods should follow the "arrange-act-assert" pattern.
Each test should test one thing. This usually means one assert per test. A test like
Avoid random data or things like 'DateTime.Now'
Ensure that all test fixture members are returned to their original state at the end of the test (e.g. using a teardown)
Even if you remove duplication ruthlessly in your production code, code duplication in test fixtures is a much smaller concern.