Write Tests

Write a focused, high-value test suite for the target supplied in $ARGUMENTS. The target may be a file path (e.g. src/lib/parse.ts), a specific function or method (e.g. parseConfig), or a class. If $ARGUMENTS is empty, ask which file or function to cover before continuing.

Understand the Target

Before writing any tests, build an accurate mental model of what you are testing.

1. Read the target identified by $ARGUMENTS and its direct dependencies.
2. Identify every public entry point: exported functions, methods, and class constructors.
3. For each entry point, note inputs, outputs, side effects (I/O, mutations, network, time), and thrown errors.
4. Detect the existing test framework and conventions instead of inventing your own. Check for jest, vitest, mocha, pytest, go test, etc. in the manifest and look at a neighboring *.test.* / *_test.* file for style.

Plan the Cases

Enumerate cases before coding so coverage is deliberate, not accidental. Aim for the following categories for each entry point.

Happy path

The expected, well-formed inputs that represent normal usage. Assert on the concrete return value and any intended side effects.

Edge cases

Boundary and unusual-but-valid inputs, for example:

• Empty inputs: "", [], {}, 0, null/None, undefined.
• Boundaries: min/max values, off-by-one limits, single-element vs. many-element collections.
• Unicode, whitespace, very long strings, and duplicate or out-of-order data.

Error cases

Invalid inputs and failure modes. Assert that the right error type is raised or the documented error result is returned — do not just assert that "something" throws.

// Assert the specific failure, not a generic one.
expect(() => parseConfig("{ bad json")).toThrow(SyntaxError);

Write the Tests

Produce the suite following these rules.

• Give each test a descriptive name that states the scenario and expected outcome (e.g. returns 0 for an empty list).
• Keep tests independent and deterministic. No shared mutable state and no reliance on execution order.
• Use the Arrange–Act–Assert shape; keep each test focused on one behavior.
• Mock only true external boundaries (network, filesystem, clock, randomness). Do not mock the unit under test.
• Pin nondeterminism: seed RNG and freeze time so runs are reproducible.

import { describe, it, expect } from "vitest";
import { slugify } from "./slugify";
 
describe("slugify", () => {
  it("lowercases and hyphenates a normal title", () => {
    expect(slugify("Hello World")).toBe("hello-world");
  });
 
  it("collapses repeated separators", () => {
    expect(slugify("a  --  b")).toBe("a-b");
  });
 
  it("returns an empty string for input with no word characters", () => {
    expect(slugify("!!!")).toBe("");
  });
});

Verify and Report

1. Run the test suite using the project's test command and confirm every new test passes.
2. If a test fails, decide whether it revealed a real bug in the target or a flaw in the test, then fix the appropriate side — do not weaken an assertion just to make it pass.
3. Report a short summary: the entry points covered, the case categories included, and any behavior that looks like a genuine bug.