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. Covered in detail in Verbose Test.
• Hard-Coded Test Data — magic literals (42, "a3f9-...", userId=7) with no named meaning, repeated across setup and assertions. See Magic Number Test.
• 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.

There is no single fix for an Obscure Test, because "obscure" is a symptom with several causes. Diagnose first, then apply the cure for the cause you found — each has its own article with the detailed refactorings.

1. Do a cold read. Ask someone who hasn't seen the code to state, from the test body alone, the setup, the action, and the expected result. Wherever they have to open another file or guess, you have found the cause.
2. Several unrelated behaviors in one test? That is an Eager Test: split it into focused tests, each named for the behavior it checks. This also stops an early failure from hiding the later checks.
3. Expected values justified by an external file, seed, or shared record? That is a Mystery Guest: bring the data the assertion depends on into the test.
4. A broad shared beforeEach builds far more than this test needs? That is a General Fixture: switch to a minimal, fresh fixture per test.
5. Pages of irrelevant setup or field-by-field assertions? That is a Verbose Test: hide the noise behind Creation Methods and builders and compare against an expected object — the mechanics are covered there.
6. Unexplained literals? See Magic Number Test: name the values so the assertion explains itself.
7. The system under test is reached through several other objects (Indirect Testing)? Test it through its own interface, or extract the logic so it can be tested directly.

// 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: '[email protected]' }); // builder defaults the noise

  const created = await svc.create(newUser);

  expect(created.email).toBe('[email protected]');
  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.