What Testing Gives You

The problem without tests

You change a database query. The endpoint returns the right data — you checked with curl. You deploy. An hour later, a client reports that the pagination is broken. Your change accidentally removed the OFFSET calculation.

Without tests, you find bugs after deployment — when users are affected, when the damage is done.

What tests do

A test is code that calls your code and checks the result. If the result is wrong, the test fails. You see the failure before deploying, before any user is affected.

import { expect, test } from "vitest";
import { formatBookV2 } from "../src/v2/transformers.js";

test("formatBookV2 includes nested author", () => {
  const row = {
    id: "book-1",
    title: "Kindred",
    genre: "sci-fi",
    author_id: "author-3",
    author_name: "Octavia Butler",
    avg_rating: 4.5,
    review_count: 2,
    description: null,
    created_at: "2024-01-15",
  };

  const result = formatBookV2(row);

  expect(result.author).toEqual({ id: "author-3", name: "Octavia Butler" });
  expect(result.ratings).toEqual({ average: 4.5, count: 2 });
});

If someone changes formatBookV2 and breaks the author nesting, this test fails immediately — before the code leaves the developer’s machine.

Confidence to change

The biggest benefit of tests is not catching bugs today — it is confidence to change code tomorrow. Without tests, every change is risky: “Did I break something?” With tests, you change the code, run the tests, and know immediately whether anything broke.

This confidence compounds. More tests → more confidence → faster changes → better API.

What to test

Happy paths: The normal case. Valid input, successful response, correct data.

Error paths: Invalid input, missing resources, authentication failures. Do they return the right status code and error message?

Edge cases: Empty strings, zero quantities, very long inputs, special characters. Does the API handle them?

Business rules: “Users cannot review their own books.” “Admins can delete any book.” Do the rules hold?

What NOT to test

The framework. You do not need to test that Hectoday HTTP routes requests or that Response.json() produces JSON. The framework is already tested.

The database engine. You do not need to test that SQLite can INSERT and SELECT. You test that your queries return the right data.

Third-party libraries. You do not need to test that Zod validates strings. You test that your schemas accept valid input and reject invalid input for your specific fields.

Test your code. Not their code.

Exercises

Exercise 1: Think about the last bug you encountered. Would a test have caught it? What would the test look like?

Exercise 2: List five things in the book catalog API that should be tested: happy paths, error paths, and edge cases.

Exercise 3: List three things that do NOT need tests (framework behavior, library internals).