unit-testing Unit Testing: Best Practices Good Naming

Example

The importance of good naming, can be best illustrated by some bad examples:

[Test]
Test1() {...} //Cryptic name - absolutely no information 

[Test]
TestFoo() {...} //Name of the function - and where can I find the expected behaviour?

[Test]
TestTFSid567843() {...} //Huh? You want me to lookup the context in the database?

Good tests need goodn names. Good test do not test methods, the test scenarios or requirements.

Good naming also provides information about context and expected behaviour. Ideally, when the test fails on your build machine, you should be able to decide what is wrong, without looking at the test code, or even harder, having the necessity to debug it.

Good naming spares you time for reading code and debugging:

[Test]
public void GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

For beginners it may be helpful to start the test name with EnsureThat_ or similar prefix. Start with an "EnsureThat_" helps to begin thinking about the scenario or requirement, that needs a test:

[Test]
public void EnsureThat_GetOption_WithUnkownOption_ReturnsEmptyString() {...}
[Test]
public void EnsureThat_GetOption_WithUnknownEmptyOption_ReturnsEmptyString() {...}

Naming is important for test fixtures too. Name the test fixture after the class being tested:

[TestFixture]
public class OptionsTests //tests for class Options
{
    ...
}

The final conclusion is:

Good naming leads to good tests which leads to good design in production code.