Test Driven Development
m (Reverted edits by Ebybymic (Talk); changed back to last version by Douglas Wall) |
|||
| (7 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| + | "''The goal is clean code that works.''" Ron Jeffries.<br> | ||
Test Driven Development (TDD) is a modern practice of agile coding development. [[Kent Beck]] is an important proponent of this theory. It supports and forwards the idea of [[Red green refactor]] and that all coding developments should occur to pass a test. Not until a test breaks are changes allowed to the coding structure. | Test Driven Development (TDD) is a modern practice of agile coding development. [[Kent Beck]] is an important proponent of this theory. It supports and forwards the idea of [[Red green refactor]] and that all coding developments should occur to pass a test. Not until a test breaks are changes allowed to the coding structure. | ||
== Red-Green-Refactor == | == Red-Green-Refactor == | ||
| − | Red-Green-Refactor is the cycle that you should go through while doing Test Driven Development. James Shore includes an extra step in this cycle; Think | + | Red-Green-Refactor is the cycle that you should go through while doing Test Driven Development. James Shore includes an extra step in this cycle; Think [http://jamesshore.com/Blog/Red-Green-Refactor.html]. |
| − | # Think: Decide what should be added next to move your code closer toward completion. This step can take a long time for beginners; take as long as you like. | + | # '''Think:''' Decide what should be added next to move your code closer toward completion. This step can take a long time for beginners; take as long as you like. |
| − | # Red: Write test code, typically no more than 5 lines. Run the tests and watch them fail. This step should usually take about 30 seconds. | + | # '''Red:''' Write test code, typically no more than 5 lines. Run the tests and watch them fail. This step should usually take about 30 seconds. |
| − | # Green: Write production code, again typically no more than 5 lines. Don't worry about the quality of your code; just make it work. In some cases you will even be able to hard code the answer. This step should also only take about 30 seconds. | + | # '''Green:''' Write production code, again typically no more than 5 lines. Don't worry about the quality of your code; just make it work. In some cases you will even be able to hard code the answer. This step should also only take about 30 seconds. |
| − | # Refactor: Now that your tests are passing you can freely improve the code as you see fit, so long as the tests continue to pass. Take another look at your code, and look for duplication and other [[Code | + | # '''Refactor:''' Now that your tests are passing you can freely improve the code as you see fit, so long as the tests continue to pass. Take another look at your code, and look for duplication and other [[Code smells]]. If there is something that you're not sure how to fix don't panic. You can go through the cycle a few more times and come back to it. Run the tests again after every little change to ensure they still pass. |
Repeat this cycle. You'll often be able to do dozens of cycles per hour. Typically you will go through a few cycles very quickly, and then slow down as you spend more time refactoring. Then you'll speed up again when you begin on a new area. It is not uncommon to go through 20-40 cycles per hour. | Repeat this cycle. You'll often be able to do dozens of cycles per hour. Typically you will go through a few cycles very quickly, and then slow down as you spend more time refactoring. Then you'll speed up again when you begin on a new area. It is not uncommon to go through 20-40 cycles per hour. | ||
== Why It Works == | == Why It Works == | ||
| + | |||
| + | There are two main reasons why TDD works. | ||
| + | |||
| + | === Baby Steps === | ||
| + | |||
| + | When doing TDD you're always working in very small steps, constantly thinking about what you expect the program to do and testing this. This means that you detect errors much earlier. Any mistake you make is caused by a change to only a few lines of code, so you know exactly where the error occurred. Finding mistakes, not fixing them, is typically the most expensive part of programming. | ||
| + | |||
| + | === Design Focus === | ||
| + | |||
| + | When doing TDD you're always thinking about the design; often without actually realising it. When you're thinking about what to add next you are designing the interface to the program. When you are refactoring you are improving the design of the code. In general you are forced to think about the program from the point of view of the client. | ||
== See Also == | == See Also == | ||
* [[Kent Beck 2003]] | * [[Kent Beck 2003]] | ||
* [[Refactoring]] | * [[Refactoring]] | ||
Latest revision as of 03:22, 25 November 2010
"The goal is clean code that works." Ron Jeffries.
Test Driven Development (TDD) is a modern practice of agile coding development. Kent Beck is an important proponent of this theory. It supports and forwards the idea of Red green refactor and that all coding developments should occur to pass a test. Not until a test breaks are changes allowed to the coding structure.
Contents |
Red-Green-Refactor
Red-Green-Refactor is the cycle that you should go through while doing Test Driven Development. James Shore includes an extra step in this cycle; Think [1].
- Think: Decide what should be added next to move your code closer toward completion. This step can take a long time for beginners; take as long as you like.
- Red: Write test code, typically no more than 5 lines. Run the tests and watch them fail. This step should usually take about 30 seconds.
- Green: Write production code, again typically no more than 5 lines. Don't worry about the quality of your code; just make it work. In some cases you will even be able to hard code the answer. This step should also only take about 30 seconds.
- Refactor: Now that your tests are passing you can freely improve the code as you see fit, so long as the tests continue to pass. Take another look at your code, and look for duplication and other Code smells. If there is something that you're not sure how to fix don't panic. You can go through the cycle a few more times and come back to it. Run the tests again after every little change to ensure they still pass.
Repeat this cycle. You'll often be able to do dozens of cycles per hour. Typically you will go through a few cycles very quickly, and then slow down as you spend more time refactoring. Then you'll speed up again when you begin on a new area. It is not uncommon to go through 20-40 cycles per hour.
Why It Works
There are two main reasons why TDD works.
Baby Steps
When doing TDD you're always working in very small steps, constantly thinking about what you expect the program to do and testing this. This means that you detect errors much earlier. Any mistake you make is caused by a change to only a few lines of code, so you know exactly where the error occurred. Finding mistakes, not fixing them, is typically the most expensive part of programming.
Design Focus
When doing TDD you're always thinking about the design; often without actually realising it. When you're thinking about what to add next you are designing the interface to the program. When you are refactoring you are improving the design of the code. In general you are forced to think about the program from the point of view of the client.
