Attended 2 days TDD course in last Dec. and started to use it in my project from Jan. These are some lessons learned from my TDD practices so far:
1. For any change into the code behavior, must think and write the test first (of course, this is the core principle of TDD);
2. In an ideal way, the TDD can totally replace low level design. But according to the result of a survey for TDD developers, most of new TDD developers found it was really hard to write effective test case directly without any low level design. As a trade off, developer can document a simplified low level design before coding test case. (The low level design should not be too detail, Simple Design is one of practices in eXtreme Programming, which is one part of Agile)
3. If developer write low level design first before coding test case, list out needed TDD test cases in the design document. Two benefits:
a. Enforce developer to think about how to test it when he think about the design;
b. Make sure the developer will not forget any test when he is coding.
4. Test case code and running result should also be reviewed during code review activity.
5. Unit test cases must be frequently executed to ensure all tests can be passed at the end of every day (it's better to adopt Continuous Integration if possible, CC can automatically run all test cases periodically and generate feedback);
6. Isolate the test data within one test class as much as possible, in order to make sure changes in one test will not impact others, and all tests can be re-run easily by another one; and the developer must make sure the test case running should not be impacted by local environment configuration or data.
7. Feel comfortable only when test case is written for function or business scenario, not for java class or method. You know, actually TDD is a business driven design/development approach.
More to be added...
1. For any change into the code behavior, must think and write the test first (of course, this is the core principle of TDD);
2. In an ideal way, the TDD can totally replace low level design. But according to the result of a survey for TDD developers, most of new TDD developers found it was really hard to write effective test case directly without any low level design. As a trade off, developer can document a simplified low level design before coding test case. (The low level design should not be too detail, Simple Design is one of practices in eXtreme Programming, which is one part of Agile)
3. If developer write low level design first before coding test case, list out needed TDD test cases in the design document. Two benefits:
a. Enforce developer to think about how to test it when he think about the design;
b. Make sure the developer will not forget any test when he is coding.
4. Test case code and running result should also be reviewed during code review activity.
5. Unit test cases must be frequently executed to ensure all tests can be passed at the end of every day (it's better to adopt Continuous Integration if possible, CC can automatically run all test cases periodically and generate feedback);
6. Isolate the test data within one test class as much as possible, in order to make sure changes in one test will not impact others, and all tests can be re-run easily by another one; and the developer must make sure the test case running should not be impacted by local environment configuration or data.
7. Feel comfortable only when test case is written for function or business scenario, not for java class or method. You know, actually TDD is a business driven design/development approach.
More to be added...
No comments:
Post a Comment