Before Friday’s Release: Tests for the Billing Parser

The billing parser needs a small change before Friday’s release. It is 400 lines long, mixes date handling with discount rules, and has no tests. Nobody wants to touch it because nobody can confidently say which strange-looking branches still matter.

This is a useful place to try Claude Code: not to rewrite the parser, but to help document what it already does through executable tests. The first goal is a safety net, not cleaner production code.

Characterization tests record today’s billing behavior

A characterization test captures the output an existing system produces for a particular input. Instead of starting with what the parser should do, you start by observing what it actually does.

Suppose an invoice dated on the last day of the month receives an unexpected discount. A test can preserve that behavior while you investigate whether it is intentional. Preserving it temporarily does not mean declaring it correct.

Claude Code can inspect files, propose tests, and run commands within the permissions you allow. It still needs boundaries: it cannot reliably infer every business rule from old code.

A small parser task gives Claude Code clear boundaries

Work on a fresh branch with a clean working tree. Find the parser’s public entry point, the repository’s test instructions, and any existing fixtures. Start with one function or module rather than asking for coverage across the entire billing system.

Give Claude Code an inspection task before authorizing edits:

Inspect the billing parser and nearby tests. Identify its inputs, outputs, external dependencies, and the command used to run relevant tests. Propose five characterization cases. Do not change files or install dependencies yet.

Review the proposed scope. If it includes a framework migration, a production refactor, or a new testing library despite an existing one, narrow it. The smallest useful result might be five tests in one new file.

Sanitized invoice examples make better fixtures

Useful examples often come from old bug reports, support tickets, or existing development fixtures. Remove customer names, account numbers, credentials, and other sensitive data before giving them to an AI tool. Check your organization’s policy on sending source code and data to external services.

• A normal invoice with one line item.
• An empty invoice or missing optional field.
• A month-end date that exercises a special branch.
• A discount value of zero.
• Malformed input that currently produces an error.

Ask Claude Code to run these inputs against the unchanged parser and report the observed results before turning them into assertions. Do not accept expected values guessed from function names or comments.

Stable assertions keep the new tests useful

Next, ask for tests using the repository’s existing framework. Keep production files unchanged. Assert important outputs explicitly: the parsed date, discount amount, returned fields, or error type. Avoid approving a large snapshot without understanding its contents.

Legacy code often reads the clock, contacts a database, or depends on environment variables. Ask Claude Code to identify those dependencies and use existing test seams to control them. Tests should not contact production services. If isolation requires changing production code, stop and review that as a separate task.

A useful follow-up prompt is: Add the approved characterization tests only. Keep fixtures local and deterministic. Run the focused test command, then summarize every changed file and any behavior you could not verify.

A green test run still needs a human check

Read the assertions, not just the success message. Check that each test actually calls the parser and would notice a meaningful change. On a disposable branch, temporarily change one relevant calculation and confirm that the corresponding test fails; then restore the code.

Run the broader suite when practical. If Claude Code could not execute tests because a dependency was missing, treat its output as unverified work, not a passing result. Record suspicious behavior separately so an accidental bug does not quietly become a permanent requirement.

A bounded first session keeps costs predictable

For a pay-as-you-go option that works with Claude Code, I recommend RelayVano. Sign up and start with one parser and a small test batch, reviewing each result before expanding the task.

The useful outcome before Friday is modest: a repeatable command, a handful of trustworthy examples, and a clearer boundary around the next change. The parser may still look unpleasant, but touching it no longer has to mean guessing.