Question bank — TDD — Red-Green-Refactor cycle

False — you write one small failing test, make it pass, then repeat. It is a tight interleaved loop, not a big "tests-first, code-later" phase.

False — Red must fail for the right reason (the assertion), not because of a typo or missing import. A test that fails for the wrong reason proves nothing about whether it can catch real bugs.

False — it means the test has no teeth: it cannot distinguish "works" from "broken," so it will never catch a regression. You want it to fail first.

False — early hardcoding is a deliberate move; the next failing test forces generalization. This triangulation is how design grows only as much as tests demand.

False — Refactor changes structure only; observable behavior must stay identical, which is exactly why all tests must remain green throughout.

False — it guarantees the behaviors you tested work and stay working. Untested paths and wrong specifications can still hide bugs; TDD shrinks the risk, it doesn't erase it.

False — "careful" is not verifiable. Without a green test suite you have no automatic proof that behavior was preserved, so a refactor becomes a leap of faith. See Refactoring.

False — keeping it is the whole point: it becomes a permanent regression guard so the bug can never silently return.

False — BDD reframes tests as human-readable behavior specifications (Given/When/Then), often at a higher level. TDD is the underlying red-green-refactor discipline; BDD builds on that idea but shifts vocabulary and audience.

False — coverage only shows which lines ran, not whether meaningful assertions checked them. You can execute a line with zero assertions and score $100\%$ coverage while catching nothing.

False — that is a flaky test. Intermittent failure breaks the whole promise of Red/Green: you can no longer trust a red bar to mean "broken" or a green bar to mean "works," so the loop's feedback signal is poisoned.

The error is the order: code came first, so the test never proved it could fail. That's tests-after, not TDD; the Red step (proving the test has teeth) was skipped.

Wrong reason for Red — an import error is a setup failure, not a genuine assertion failure. You must reach the point where the assertion is what fails.

Red tests during refactor mean behavior changed (or a test is now stale). You must not commit; either restore green or, if the spec truly changed, that's new work needing its own Red step first.

This destroys failure localization — when it fails you can't tell which behavior broke. One assert-worthy behavior per test is the rule (see Unit Testing).

That over-shoots the minimum; you built behavior no failing test demanded. Write the simplest thing that passes the current test and let later tests pull the rest.

The pain is design feedback, not a framework fault. Heavy setup signals tight coupling; refactor for testability, possibly using test doubles to isolate the unit.

A test that touches a real database, network, or file system is no longer a unit test; it's slow and non-deterministic, so it doesn't belong in the fast inner TDD loop. Replace the dependency with a stub or fake for the unit loop, and keep the real-dependency check as a separate, slower integration suite run by Continuous Integration.

Re-running hides the real bug: test ordering dependence. Each test must set up and tear down its own state so it passes in isolation and in any order; otherwise your suite is flaky by construction.

So you prove the test can actually detect the missing behavior. A test that never failed might be asserting nothing and would silently pass forever.

Green's only job is to reach a known-good state fast. Cleanliness is Refactor's job, and triangulation from the next test will force real logic anyway, so you lose nothing.

Because painful-to-test code fails the very first thing you do (write a test), the friction shows up immediately and cheaply, nudging you toward smaller, injectable units aligned with SOLID Principles.

The cost of a defect grows with time-to-detection. A bug caught in the Red step costs seconds; the same bug in production costs orders of magnitude more, so tiny loops keep the detection window minimal.

A tiny test localizes failure to a single behavior, so a red bar tells you exactly what broke. A giant test only tells you "something in here is wrong."

TDD produces a fast, always-green test suite that CI can run on every push, catching regressions the moment they enter shared code rather than days later.

TDD's entire value rests on trusting the red/green signal. A flaky test that sometimes fails for no reason trains you to ignore red bars — so when a real red appears you shrug it off, and the safety net silently rots.

Databases, networks, and clocks are slow and non-deterministic; putting them in your seconds-long loop makes it minutes-long and unreliable, which kills the tight rhythm that makes TDD worth doing.

Then there's nothing new to drive — either the test is redundant, or you're documenting existing behavior (a characterization test), which is a different, deliberate purpose from driving new code.

No — you only refactor on green. With red tests you can't tell whether a change preserved behavior, so refactoring first requires getting back to green.

That's a signal your minimal change wasn't actually minimal or consistent; the failing earlier test is doing its job. Adjust the code so all tests are green before moving on — never leave a passing test broken.

You change the test deliberately in a Red step — a failing test that now encodes the corrected spec — then make code match. The test is the spec, so fixing the spec means editing the test on purpose, not silently.

Duplication and mess accumulate, tests get harder to write, and eventually the design pain slows you down — the discipline only pays off if Refactor is a non-optional third of the loop.

Yes — green only means the checked behaviors hold. Missing tests, weak assertions, or inflated Code Coverage can make a green bar hide real gaps.

Inject the clock or random source as a dependency and pass a fixed fake value in the test (e.g. always return 2024-01-01 or seed 0). That removes the non-determinism so the same test always gives the same red/green result.

Keep a small number of slower integration tests that exercise the real database/network in a separate suite; drive the design with fast, isolated unit tests in the inner loop and run the integration suite less often (typically in Continuous Integration). This is the classic test pyramid: many fast unit tests, few slow integration tests.

Stop and fix or quarantine it immediately — never leave it in the green-required suite. A tolerated flaky test erodes trust in every other test, so it is treated as a bug in its own right, not a nuisance to ignore.