  | 1 of 21
 |   |
| | 1 of 21
| |
Test-Driven Development treats unit testing as an integral part of the design and implementation process. Often summarized as “test first, code after”, TDD is actually a recognition that in writing tests, we are
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.
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.
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.
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.
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
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
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
Encourages designing for testability
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
Encourages designing for testability
“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
“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.
“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
“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.
“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.
“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.
“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.
“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.
The very act of trying to write black-box tests becomes itself an exercise in validation of the interface design!
Test-Driven Development (TDD) is the practice of repeatedly:
Write an automated test case for a new desired behavior.
This case must, initially, fail.
Write just enough new code to pass the test.
Refactor the code to make it acceptable quality.
This ties in very nicely with some of our previous discussion of incremental development. In particular, compare to the way we break stories into tasks.
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.
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).
There remains, through most of the project, a base set of red tests that we never quite pass.
My stereotypical division of a story into tasks is typically
Compare this to the steps of TDD, above, and you can see that they are compatible.
Story: As a spreadsheet designer, I would like to write expressions involving square roots
Create/modify the API to describe a new desired behavior.
Added SquareRootOp class as a subclass of Expression.
In other cases, we might not need a new class, but might need to modify the interface of an existing one (e.g., by adding functions)
task 1, starting about 2:00
Note that the new API is entirely stubs. We aren’t implementing yet, just making necessary changes to the API.
Write the unit tests.
Added unit tests for mutators of SquareRootOp: constructor, clone (two overloaded functions)
Implement the new behavior.
The “easy” part.
Integrate and commit changes.
More on this later when we cover version control & integration testing.
| | 1 of 21
| |