1 Test-First Development

With our new knowledge of unit-testing frameworks, ideally, we have made it easier to write self-checking unit tests than to write the actual code to be tested.

• We encourage an approach of writing the tests before writing the code.

1.1 Debugging: How Can You Fix What You Can’t See?

The test-first philosophy is easiest to understand in a maintenance/debugging context.

• Before attempting to debug, write a test that reproduces the failure.

• How else will you know when you’ve fixed it?

• From a practical point of view, debugging generally involves running the buggy input, over and over, while you add debugging output or step through with a debugger.

  • You want that to be as easy as possible.
  • Doing this at the unit level, instead of in the context of the entire system, is often a dramatically better use of your time and effort.

1.2 Test-Writing as a Design Activity

Every few years, software designers rediscover the principle of writing tests before implementing code.

Agile and TDD (Test-Driven Development) are just the latest in this long chain.

• Writing tests while “fresh” yields better tests than when they are done as an afterthought.

• Thinking about boundary and special values tests helps clarify the software design

  • Reduces the number of eventual faults actually introduced

• Encourages designing for testability

  • Making sure that the interface provides the “hooks” you need to do testing in the first place.

1.2.1 Tests are Examples

“If it’s hard to write a test, it’s a signal that you have a design problem, not a testing problem. Loosely coupled, highly cohesive code is easy to test.” – Kent Beck

• In writing a test, you are actually writing sample code of how the unit’s interface can be used.

  • Valuable as documentation

• It’s very common when writing tests to discover that the interface is incorrect or inadequate.

  • Interface may not have parameters to supply needed data, or may have the wrong parameters.
  • Functions may be missing that would manipulate the ADT state.
  • Functions may be missing that owuld allow us to examine the ADT state to see the effects of a manipulation

• The very act of trying to write black-box tests becomes itself an exercise in validation of the interface design!

2 Test-Driven Development

Test-Driven Development (TDD) is the practice of repeatedly:

1. Write an automated test case for a new desired behavior.

   • This case must, initially, fail.

2. Write just enough new code to pass the test.

3. Refactor the code to make it acceptable quality.

2.1 The Cycle of Unit Test Failures

Here you can see a plot of test cases on the vertical axis versus time (actually, commits to the version control system) on the horizontal axis during a project on which I practiced TDD.

Tests passed are shown in blue and failed tests are shown in red.

Notice the repeated pattern:

• There are multiple sudden rises in the number of tests failed.

  • These are matched by a simultaneous and equal increase in the total number of tests. So what we are seeing is the additon of new tests that we, initially, fail.
  • That’s because in TDD we write tests first for code that we have not yet developed. Naturally, we fail those tests.

• Each such rise is followed by an eventual decrease in the number of failed tests while the total number of tests stays constant (so the blue area grows).

  • That’s because, after developing the new tests, we started working on implementing the new funcitonality, eventually passing most of those new tests.

• There remains, through most of the project, a base set of red tests that we never quite pass.

  • That’s because I am often adding both unit and integration tests.
  • Unit tests will test our modified ADT(s) in isolation from the rest of the system. They can be passed as soon as we finish the ADT modifications.
  • Integration tests test the modified ADT(s) together with other portions of the system. We can’t pass these until later in the project when those other portions of hte system have actually been implemented.
    • You can see, near the end of the project time, that the “stubborn” base of failed tests is finally starting to decrease.

3 TDD during Incremental Development

My stereotypical division of a story into tasks is typically

1. Create/modify the API to describe a new desired behavior.
2. Write the unit tests.
3. Implement the new behavior.
4. Integrate and commit changes.

Compare this to the steps of TDD, above, and you can see that they are compatible.

3.1 Case Study: TDD of a Spreadsheet Story