Obscure Test.

You read a test and still can't answer three questions: what is the setup, what is being exercised, and what is the expected result? The cause/effect chain is hidden. Meszaros groups the causes into "too much information" and "too little information." Common tells:

• Eager Test — one test method verifies many unrelated behaviors, so no single intent is clear.
• Mystery Guest — the fixture or expected values live outside the test (a file, a shared DB record, a fixture loaded by name), so you can't see why the assertion should pass.
• General Fixture — a big shared beforeEach/factory builds far more than this test needs; the few relevant fields are lost in noise.
• Irrelevant Information — pages of setup data or a giant snapshot where only one or two fields actually matter.
• Hard-Coded Test Data — magic literals (42, "a3f9-...", userId=7) with no named meaning, repeated across setup and assertions.
• Indirect Testing — the test pokes the system under test through several other objects, obscuring what is really under test.

// Obscure: Eager + Mystery Guest + Irrelevant Information
test('user', async () => {
  const data = loadFixture('users.json');        // mystery guest: values live in a file
  const svc = new UserService(data, cfg, clock); // general fixture: most of this is unused
  const u = await svc.create({ ...data[0], roles: ['a','b'], flags: 0x1f });

  expect(u.id).toBeDefined();
  expect(u.email).toContain('@');
  expect(await svc.count()).toBe(data.length + 1); // why this number? answer is in the file
  expect(await svc.login(u.email, 'p@ss')).toBe(true); // unrelated second behavior
});

Here you can't tell what the test proves without opening users.json, and it actually checks creation and login at once.

Why it happens

• Tests grow by accretion: a developer adds "one more assertion" to an existing test instead of writing a new one, producing an Eager Test.
• Sharing setup feels efficient, so a single broad fixture or beforeEach is reused everywhere (General Fixture), and external files/DB seeds get loaded by name (Mystery Guest).
• Copy-pasting realistic-looking data drags in dozens of irrelevant fields and magic numbers.
• Over-mocking or going through many collaborators turns a unit test into Indirect Testing.

Why it hurts

• Readability: a test is documentation of intended behavior. If the reader can't reconstruct Setup → Exercise → Verify, that documentation value is lost.
• Maintainability: when an obscure test fails you don't know which behavior broke or whether the test or the code is wrong, so changes are slow and risky.
• Reliability: Mystery Guest and General Fixture couple the test to external/ shared state, causing flaky or order-dependent failures (and breaking the "fresh, deterministic" property of a good unit test).
• False confidence: Eager Tests mask coverage — a failure early in the method short-circuits the later checks, so behaviors you think are tested may never run. And as Meszaros notes, coding errors are easier to hide in an obscure test, producing Buggy Tests that pass for the wrong reasons.

Make every test tell a self-contained story whose intent is visible in the test body.

1. Verify one condition per test. Split an Eager Test into focused tests, each named for the behavior it checks. This also fixes coverage masking.
2. Inline the relevant fixture (kill the Mystery Guest). Construct the data the test depends on in the test, or via an explicit, named Creation/Builder method — don't load anonymous files or shared DB rows.
3. Use a Minimal / Fresh Fixture. Build only what this test needs; replace a broad shared beforeEach with a builder that defaults the noise and lets each test set only the field under test.
4. Name your data. Replace magic literals with intention-revealing constants/variables so the assertion explains itself.
5. Assert on meaning, not on everything. Prefer targeted assertions over a giant snapshot; if you snapshot, keep it small and reviewable so the relevant facts aren't drowned in irrelevant output.
6. Hide mechanics, not intent. Push incidental wiring into well-named Test Utility/helper methods so the test body reads as setup → action → expectation.

// Before (obscure)
test('user', async () => {
  const data = loadFixture('users.json');
  const svc = new UserService(data, cfg, clock);
  const u = await svc.create({ ...data[0], roles: ['a','b'], flags: 0x1f });
  expect(await svc.count()).toBe(data.length + 1);
});

// After: one intent, fixture inline, named data
test('create() persists a new user', async () => {
  const svc = userServiceWith([]);                 // minimal, fresh fixture
  const newUser = aUser({ email: 'ada@example.com' }); // builder defaults the noise

  const created = await svc.create(newUser);

  expect(created.email).toBe('ada@example.com');
  expect(await svc.count()).toBe(1);               // self-explanatory, no external file
});

Aim for the AAA (Arrange-Act-Assert) shape: a reader should grasp the scenario without leaving the test method.