I have been using TDD since before it was even called that. The practice was called test-first at the time and I learnt to do it with ComUnit against VB6 code. I suspect that there aren't many people who can put down more than a decade of of TDD on their CV. Probably due to this, I employ somewhat idiosyncratic practices, such as a distinct interface focus (both the default interface and those additionally implemented). Accordingly, I have a fairly well elaborated naming convention for my unit tests in order to make test scenario coverage more rigorous and visible.
The overall convention is
public void memberKind_parameterType_parameterType_whenScenarioInfo()
Member Kinds (when default or implicit interface implementation)
- Generic Methods:
Member Kinds (when explicit interface implementation)
- Type definition assertions:
- Assert deserialization:
- Assert serialization:
- Null types:
- Empty string:
- Invalid string:
- Specific values:
Used to disambiguate two or more tests which otherwise have the same name, e.g.
Cavity has almost complete test coverage so there are plenty of examples. Here are some:
So obvious that I forgot to mention it, but worth putting on the record: each class should have exactly one test class, i.e.
Example.Facts.cs (if xUnit) or
Example.Tests.cs (if NUnit, MSTest, etc.). The period in Example.Facts or Example.Tests is to force the same sort order of units and tests in the Visual Studio solution explorer tree view. I use a pair of templates to assist me (installer available in downloads).