Naming Conventions

Naming Conventions

Bad test names are the worst. You see a failing test called "test 1" or "works" and you have no idea what broke. Good test names are like good error messages. They tell you exactly what happened.

Let me give you the patterns that make tests actually readable.

The "should" Pattern

Some teams like to start test names with "should". It reads like a requirement.

describe('calculateDiscount', () => {
  it('should return 10% discount for orders over 100', () => {
    expect(calculateDiscount(150)).toBe(15);
  });

  it('should return 0 for orders under 100', () => {
    expect(calculateDiscount(50)).toBe(0);
  });
});
    

This works but some people find it verbose. "It returns 10% discount" already implies "should".

The "when" Pattern

The when pattern describes the condition. It is great for tests with different scenarios.

describe('divide', () => {
  it('when divisor is zero, throws an error', () => {
    expect(() => divide(10, 0)).toThrow();
  });

  it('when both numbers are positive, returns quotient', () => {
    expect(divide(10, 2)).toBe(5);
  });
});
    

The "it" Pattern

Most common pattern. It describes the behavior directly.

describe('array', () => {
  it('returns the first element', () => {
    expect([1, 2, 3][0]).toBe(1);
  });

  it('returns empty array when no items exist', () => {
    expect([].length).toBe(0);
  });
});
    

Rules for Good Names

Whatever pattern you choose, follow these rules. Be specific. Avoid vague words like "works" or "handles". Describe the input and expected output. When a test fails, the name should tell you what broke without reading the code.

Key Takeaways

• Good test names describe the behavior being tested
• The "should" pattern reads like a requirement
• The "when" pattern describes different scenarios clearly
• The "it" pattern is the most common and concise
• Avoid vague names like "works" or "handles edge case"
• Pick one convention and use it consistently across your project