Test Driven Development
From CSSEMediaWiki
(Difference between revisions)
m (→See Also) |
|||
| Line 1: | Line 1: | ||
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 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. | ||
| + | # 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 == | ||
== See Also == | == See Also == | ||
* [[Kent Beck 2003]] | * [[Kent Beck 2003]] | ||
* [[Refactoring]] | * [[Refactoring]] | ||
Revision as of 09:06, 22 August 2009
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 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.
