Test-Driven Development By Example¶

Metadata¶

• Author: [[Kent Beck]]

Highlights¶

Here is the nightmarish scenario for any software designer. You were cruising along happily and successfully with a set of assumptions. Suddenly, everything changed. — location: 202 ^ref-61729

what set of tests, when passed, will demonstrate the presence of code we are confident will compute the report correctly? — location: 314 ^ref-17144

The problem is the dependency between the code and the test—you can't change one without changing the other. Our goal is to be able to write another test that "makes sense" to us, without having to change the code, something that is not possible with the current implementation. — location: 393 ^ref-20811

When I use TDD in practice, I commonly shift between these two modes of implementation. When everything is going smoothly and I know what to type, I put in Obvious Implementation after Obvious Implementation (running the tests each time to ensure that what's obvious to me is still obvious to the computer). As soon as I get an unexpected red bar, I back up, shift to faking implementations, and refactor to the right code. When my confidence returns, I go back to Obvious Implementations. — location: 538 ^ref-38288

However, to review, we Translated a design objection (side effects) into a test case that failed because of the objection Got the code to compile quickly with a stub implementation Made the test work by typing in what seemed to be the right code — location: 543 ^ref-2146