Testing the Pieces and Their Seams

You know tests are your safety net, and that the critical paths come first. But there is more than one kind of test. One checks a single tiny piece on its own; another checks that two pieces still work where they meet. Which kind you reach for decides where you catch the bug and how fast, and this chapter gets you that difference so you can tell the agent exactly what to protect.

7.2.1A unit test checks one pieceAdd note

A unit test checks one small piece of your code, usually a single function, on its own. You hand it an input, it runs that one piece, and it checks the output matches what you expected. Nothing else runs, no database, no whole app, just the piece.

That isolation is the point. When it fails, it fails fast and names the exact function, not a vague "something broke somewhere."

test("applyDiscount takes 20% off", () => {
  const final = applyDiscount(100, 0.2);
  expect(final).toBe(80);
});

A runner like Vitest runs hundreds of these in a second.

7.2.2An integration test checks the seamsAdd note

An integration test checks that two pieces still work where they meet. The bug is rarely inside one clean function; it hides at the seam, where your code hands off to the database, or where two modules trusted different assumptions.

So you exercise the real seam. Save a record, load it back, and check you got the same thing out, with the actual database running underneath:

test("a saved user loads back the same", async () => {
  await saveUser({ email: "[email protected]" });
  const user = await loadUser("[email protected]");
  expect(user.email).toBe("[email protected]");
});

If saving and loading ever stop agreeing, this turns red. A unit test on either one alone would sail straight past it.

7.2.3Test the logic that mattersAdd note

You do not test every line, and you do not test a function that just hands back a value. You test the logic that would hurt if it were wrong: the pricing math, the discount rule, the check that decides who gets in.

Rule of thumb: if a mistake there would cost money, lose data, or let the wrong person in, it earns a test. If it is ordinary, skip it.

7.2.4Let the agent write themAdd note

You hand-write none of this. You name the behavior to protect; the agent writes the tests and runs them. The judgment is yours: which logic is worth the net, which seam is fragile. Give it that and it fills in the cases you would forget, the zero, the empty input, the one that should throw an error.

This prompt hands your agent the logic to protect:

Act as a senior engineer writing tests for me.
For the logic I name below, write focused unit
tests for the tricky cases: the boundaries, the
zero and the empty input, the case that errors.
Where two pieces meet (a function and the
database, two modules), add one integration test
that exercises the real seam, not a fake. Use my
stack's standard runner. Report each case you
covered and the ones you deliberately skipped.

The logic I want protected:

Do this now: paste the prompt, name the one piece of logic that would hurt most if it broke, and let your agent write the tests that pin it down.