Turning a Red Test Suite Green

The test suite is the spec, not an obstacle

In this round's most literal form, you're handed a repository where some tests already pass (the working features) and some fail (the feature you're meant to implement, or the bug you're meant to fix) — and the win condition is explicit and mechanical: get the suite green. This is, functionally, exactly the shape of every Exercism exercise ever written (stub code plus a failing test suite you make pass), which makes Exercism's practice exercises unusually good, low-cost preparation for this specific format — the skill of reading a test file as a precise specification and working backward to an implementation transfers directly.

Read every failing test in full before writing any implementation code. Each one is a concrete input/output pair the interviewer (or the take-home's grading harness) has decided matters — treat the full set of them as the actual requirements document, more precise and less ambiguous than any prose description would be.

Work test-by-test, not feature-at-once

Under time pressure, the instinct is to read all the failing tests, form a mental model of "the whole feature," and try to implement all of it in one pass. This usually backfires: partial implementations that don't compile or don't run leave you with zero passing tests and no partial credit, and a single subtle misunderstanding early on compounds across everything you build on top of it. The steadier approach:

1. Pick the simplest failing test first — not necessarily the first one in the file, the one requiring the least implementation to satisfy.
2. Write the smallest implementation that makes it pass, even if you know it's incomplete for the harder cases coming next.
3. Rerun the full suite. Confirm that test now passes and nothing else regressed.
4. Move to the next-simplest failing test, and extend the implementation just enough to satisfy it too — refactoring the existing implementation as needed, now that you have more real cases to generalize from.

This is the same red-green-refactor rhythm the TDD Mechanics subtopic covers for writing tests from scratch, applied instead to a suite that's handed to you already written — you're just skipping the "write the test" step, which is normally the hardest part.

The trap this format sets on purpose: overfitting to visible tests

Some rounds and take-home graders deliberately run a hidden test suite in addition to the visible one — Shopify's CodeSubmit-based assessment explicitly grades on "all hidden tests pass," not just the ones you can see. This changes the right strategy in one specific way: don't write implementation code that only handles the exact cases the visible tests enumerate (hardcoding a returned value that happens to match, special-casing a specific input) — implement the actual general behavior the visible tests are sampling, inferred from what they collectively imply about intent. A quick self-check that catches most overfitting: for each test, ask "if the input were slightly different — one more item, a boundary value, an empty case — would my implementation still be correct, or does it just happen to match this exact input?" If you're not sure, that's a sign you special-cased rather than generalized.

Don't let "make it green" replace "make it correct"

A green suite is necessary but not sufficient — a visible suite is rarely exhaustive, and a reviewer (human or automated) is very likely also reading the code, not just the test output. Once every visible test passes, spend remaining time on the things a passing suite doesn't verify: obvious edge cases the tests didn't cover (empty input, a boundary value, a duplicate), and whether your implementation is legible to someone reading it without the tests open beside it. Saying out loud "the suite's green, but let me check a couple of edge cases the tests didn't explicitly cover" is a strong, low-cost signal that you understand the suite is a sample of correctness, not a definition of it.