本文介绍了一种敏捷开发方法——测试驱动开发（TDD），详细解释了TDD的基本步骤及核心原则，并强调了其与传统开发方式的区别。TDD要求先编写测试用例再编写功能代码，并且每次只编写刚好能让测试失败的最小代码量。本文还提到了TDD所需的环境条件，如单元测试框架等。
commend a method of Driven Development : [b] TDD[/b]
[b]1. What is TDD?[/b]
The steps of test first development (TFD) are overviewed in the UML activity diagram of Figure 1. The first step is to quickly add a test, basically just enough code to fail. Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail. You then update your functional code to make it pass the new tests. The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning TFD into TDD).
Figure 1. The Steps of test-first development (TFD).
[img]http://www.agiledata.org/images/tddSteps.jpg[/img]
I like to describe TDD with this simple formula:
TDD = TFD + refactoring.
[u]TDD completely turns traditional development around[/u] .Instead of writing functional code first and then your testing code as an afterthought, if you write it at all, you instead write your test code before your functional code. Furthermore, you do so in very small steps – one test and a small bit of corresponding functional code at a time. A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn’t present. In fact, they refuse to add even a single line of code until a test exists for it. Once the test is in place they then do the work required to ensure that the test suite now passes (your new code may break several existing tests as well as the new one). Once your code works, you then refactor it to ensure that it's remains of high quality. This sounds simple in principle, but when you are first learning to take a TDD approach it proves require great discipline because it is easy to “slip” and write functional code without first writing a new test. One of the advantages of pair programming (Williams and Kessler 2002) is that your pair helps you to stay on track.
An underlying assumption of TDD is that you have a unit-testing framework available to you. Agile software developers often use the xUnit family of open source tools, such as JUnit or VBUnit, although commercial tools are also viable options. Without such tools TDD is virtually impossible. Figure 2 presents a UML state chart diagram for how people typically work with the xUnit tools. This diagram was suggested to me by Keith Ray.
Figure 2. Testing via the xUnit Framework.
[img]http://www.agiledata.org/images/tddStates.jpg[/img]
Kent Beck, who popularized TDD in eXtreme Programming (XP) (Beck 2000), defines two simple rules for TDD (Beck 2003). First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find. Beck explains how these two simple rules generate complex individual and group behavior:
You design organically, with the running code providing feedback between decisions.
You write your own tests because you can't wait 20 times per day for someone else to write them for you.
Your development environment must provide rapid response to small changes (e.g you need a fast compiler and regression test suite).
Your designs must consist of highly cohesive, loosely coupled components (e.g. your design is highly normalized) to make testing easier (this also makes evolution and maintenance of your system easier too).
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:
Run fast (they have short setups, run times, and break downs).
Run in isolation (you should be able to reorder them).
Use data that makes them easy to read and to understand.
Use real data (e.g. copies of production data) when they need to.
Represent one step towards your overall goal.
[b][url=http://www.agiledata.org/essays/tdd.html#TraditionalTesting]2. TDD and Traditional Testing[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#Documentation]3. TDD and Documentation[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#TestDrivenDatabaseDevelopment]4. Test-Driven Database Development[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#TDDAMDD]5. TDD and Agile Model-Driven Development (AMDD)[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#PartingThoughts]6. Why TDD[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#Misconceptions]7. Myths and Misconceptions[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#Summary]8. Summary[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#Tools]9. Tools[/url][/b] ...
... ...
[url=http://www.agiledata.org/essays/tdd.html#Figure1StepsOfTDD]original text[/url]
[b]1. What is TDD?[/b]
The steps of test first development (TFD) are overviewed in the UML activity diagram of Figure 1. The first step is to quickly add a test, basically just enough code to fail. Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail. You then update your functional code to make it pass the new tests. The fourth step is to run your tests again. If they fail you need to update your functional code and retest. Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning TFD into TDD).
Figure 1. The Steps of test-first development (TFD).
[img]http://www.agiledata.org/images/tddSteps.jpg[/img]
I like to describe TDD with this simple formula:
TDD = TFD + refactoring.
[u]TDD completely turns traditional development around[/u] .Instead of writing functional code first and then your testing code as an afterthought, if you write it at all, you instead write your test code before your functional code. Furthermore, you do so in very small steps – one test and a small bit of corresponding functional code at a time. A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn’t present. In fact, they refuse to add even a single line of code until a test exists for it. Once the test is in place they then do the work required to ensure that the test suite now passes (your new code may break several existing tests as well as the new one). Once your code works, you then refactor it to ensure that it's remains of high quality. This sounds simple in principle, but when you are first learning to take a TDD approach it proves require great discipline because it is easy to “slip” and write functional code without first writing a new test. One of the advantages of pair programming (Williams and Kessler 2002) is that your pair helps you to stay on track.
An underlying assumption of TDD is that you have a unit-testing framework available to you. Agile software developers often use the xUnit family of open source tools, such as JUnit or VBUnit, although commercial tools are also viable options. Without such tools TDD is virtually impossible. Figure 2 presents a UML state chart diagram for how people typically work with the xUnit tools. This diagram was suggested to me by Keith Ray.
Figure 2. Testing via the xUnit Framework.
[img]http://www.agiledata.org/images/tddStates.jpg[/img]
Kent Beck, who popularized TDD in eXtreme Programming (XP) (Beck 2000), defines two simple rules for TDD (Beck 2003). First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find. Beck explains how these two simple rules generate complex individual and group behavior:
You design organically, with the running code providing feedback between decisions.
You write your own tests because you can't wait 20 times per day for someone else to write them for you.
Your development environment must provide rapid response to small changes (e.g you need a fast compiler and regression test suite).
Your designs must consist of highly cohesive, loosely coupled components (e.g. your design is highly normalized) to make testing easier (this also makes evolution and maintenance of your system easier too).
For developers, the implication is that they need to learn how to write effective unit tests. Beck’s experience is that good unit tests:
Run fast (they have short setups, run times, and break downs).
Run in isolation (you should be able to reorder them).
Use data that makes them easy to read and to understand.
Use real data (e.g. copies of production data) when they need to.
Represent one step towards your overall goal.
[b][url=http://www.agiledata.org/essays/tdd.html#TraditionalTesting]2. TDD and Traditional Testing[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#Documentation]3. TDD and Documentation[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#TestDrivenDatabaseDevelopment]4. Test-Driven Database Development[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#TDDAMDD]5. TDD and Agile Model-Driven Development (AMDD)[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#PartingThoughts]6. Why TDD[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#Misconceptions]7. Myths and Misconceptions[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#Summary]8. Summary[/url][/b] ...
[b][url=http://www.agiledata.org/essays/tdd.html#Tools]9. Tools[/url][/b] ...
... ...
[url=http://www.agiledata.org/essays/tdd.html#Figure1StepsOfTDD]original text[/url]
扫一扫
905
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
