How should you name tests and describe blocks?

Test names are read far more often than they are written: in CI output, in a pull request, and by the next person debugging a failure. A name like works says nothing. A name like returns an empty list when the account has no orders states the contract.

describe("applyDiscount", () => {
  test("returns zero for an empty cart", () => {
    expect(applyDiscount([], 0.2)).toBe(0);
  });

  test("caps the discount at the cart subtotal", () => {
    expect(applyDiscount([{ price: 10 }], 5)).toBe(0);
  });
});

What a good name contains

• The behaviour or subject, not the function name repeated
• The condition or input that makes the case distinct
• The expected outcome in plain language
• No vague words such as works, handles or should be correct
• No reference to internal helpers the reader cannot see

Keep names stable when the implementation changes. A test named after a hook or a state variable will become wrong after a refactor, even if the behaviour is unchanged. Name the externally observable result instead.