In this lesson, you will learn how to craft descriptive C# test names that turn your test runner output into a living documentation of your system’s requirements.
When a test fails at 2:00 AM in your CI pipeline, you shouldn't have to open the source code to understand what went wrong. Vague names like Calculate_Test or SubmitOrder_Validation provide no context on the expected behavior or the specific edge case being tested.
The Behavioral Naming Strategy
An effective test name should follow a consistent pattern that communicates three things: What is being tested, Under what conditions, and What the expected outcome is. A popular and highly readable convention is the MethodName_Scenario_ExpectedBehavior pattern.
Consider an order processing service. Instead of a generic name, use the structure to document intent:
[Fact]
public void ProcessOrder_WhenInventoryIsInsufficient_ReturnsInsufficientStockResult()
{
// Arrange, Act, Assert...
}
By structuring the name this way:
- MethodName (
ProcessOrder): Clearly maps the test to the target functionality. - Scenario (
WhenInventoryIsInsufficient): Describes the specific state or input being evaluated. - ExpectedBehavior (
ReturnsInsufficientStockResult): States the outcome, making it obvious whether the failure is a logic error or a contract violation.
Why This Matters
As your system grows, your test suite becomes your most reliable technical documentation. When you use this naming convention, your test report acts as a "specification document" that describes how the system behaves under pressure. If a requirement changes, the test name tells you exactly which scenario is affected. If a test fails, the name tells you exactly which requirement was violated, saving you from navigating through layers of test logic to identify the root cause.
Avoid using "Should" in your names (e.g., ShouldReturnError). The test is a statement of fact, not a suggestion. Stick to the state-action-result triplet to keep your intent unambiguous.
Key Takeaway: A test name should be a self-documenting sentence that describes the scenario and the outcome, allowing you to identify the cause of a failure without ever opening the test code.