테스트 주도 개발

Definitions

Awareness and control:

TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap. “What if I do a paper design for a week, then test-drive the code? Is that TDD?” Sure, it’s TDD. You were aware of the gap between decision and feedback, and you controlled the gap deliberately. —Preface, Test-driven development: by example

The general TDD cycle

The general TDD cycle goes as follow:

  • Step 1. Quickly add a test.
  • Step 2. Run all tests and see the new one fail.
  • Step 3. Make a little change.
  • Step 4. Run all tests and see them all succeed.
  • Step 5. Refactor to remove duplication.

See also

Complex behavior emerged from simple rules

In Test-Driven Development, we

  • Write new code only if an automated test has failed
  • Eliminate duplication

These are two simple rules, but they generate complex individual and group behavior with technical implications such as the following.

  • We must design organically, with running code providing feedback between decisions.
  • We must write our own tests, because we can’t wait 20 times per day for someone else to write a test.
  • Our development environment must provide rapid response to small changes.
  • Our designs must consist of many highly cohesive, loosely coupled components, just to make testing easy.

—Preface, Test-driven development: by example

Exceptions

There are always exceptions :)

Whoa! Code without a test? Can you do that? We could certainly have written a test for toString() before we coded it. However,

  • We are about to see the results on the screen.
  • Because toString() is used only for debug output, the risk of it failing is low.
  • We already have a red bar, and we’d prefer not to write a test when we have a red bar.

Exception noted.

—Chapter 10, Test-driven development: by example

Name

What’s with the name?

  • Development: The old “phasist” way of thinking about software development is weakened because feedback between decisions is difficult if they are separated in time. Development in this sense means a complex dance of analysis, logical design, physical design, implementation, testing, review, integration, and deployment.
  • Driven: I used to call TDD “test-first programming.” However, the opposite of “first” is “last,” and lots of people test after they have programmed. There is a naming rule that the opposite of a name should be at least vaguely unsatisfactory. (Part of the appeal of structured programming is that no one wants to be unstructured.) If you don’t drive development with tests, what do you drive it with? Speculation? Specifications? (Ever notice that those two words come from the same root?)
  • Test: Automated, reified, concrete tests. Push a button and they run. One of the ironies of TDD is that it isn’t a testing technique (the Cunningham Koan). It’s an analysis technique, a design technique, really a technique for structuring all the activities of development.

—Chapter 32, Test-driven development: by example

Articles

2024 © ak