Test naming convention consistent

When a test fails, the first signal is the test name in the CI output. A name like "test1" or "works" tells an engineer nothing about what broke or what regression to investigate — they must open the test file, read the code, and reconstruct the intent. ISO 25010:2011 §6.5.5 classifies this as a maintainability defect: diagnostic value is a measurable property of a test suite. Poor naming also correlates with poor test structure — if a developer cannot name a test precisely, they often haven't defined precisely what they're testing.

Adopt the "should [verb] when [condition]" or "returns [result] given [input]" pattern. Update existing tests incrementally — start with the highest-churn files where test names are most frequently read.

// Bad naming: opaque in CI output
describe('auth', () => {
  it('test1', () => { ... })
  it('works', () => { ... })
  it('login check', () => { ... })
})

// Good naming: self-explanatory on failure
describe('authenticateUser', () => {
  it('returns a session token when credentials are valid', async () => { ... })
  it('throws InvalidCredentialsError when password is wrong', async () => { ... })
  it('throws AccountLockedError after 5 failed attempts', async () => { ... })
})

Choose it() or test() consistently — mixing both in the same codebase is a minor but visible inconsistency.