Test-driven development ( TDD ) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test and finally refactors the new code to acceptable standards.
Test-driven development is related to the test-first programming concepts of extreme programming.
Requirements
Test-driven development requires developers to create automated unit tests that define code requirements( immediately ) before writing the code itself. The developers should pass the tests and refactor the code. Developers often use testing frameworks, such as xUnit, testNG to create and automatically run sets of test cases.
Test-driven development cycle
a. Add a test.
b. Run all tests and see if the new one fails
c. Write some code to make the test pass. ( Fix functional code )
d. Run the automated tests and see them succeed.
e. Refactor code ( Refactor code without breaking tests )
f. Repeat.
When do refactoring?
When there are some duplication codes.
When the code intention are not very clear.
When you feel the code quality is bad or tend to bad.
Refactoring method
extract class
extract interface
extract method
replace type code with subclasses
replace conditional with polymorphism form template method
introduce explaining variable
replace constructor with factory method
replace inheritance with delegation
Repeat:
Starting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should undo or revert.
Benefits:
a. It enables developers to take small steps when writing software. When a test pass, it means this part of work is done. In traditional development, it is hard to know when the coding is finished.
b. The best and the function code is write by the same person.
c. Helps the developer understand the code generally and correctly. In traditional development it is hard to do so.
d. Avoid over-design.
e. The system can delivered with systematic tests. So it is easy for developers to edit and extend.
f. Everyone is making design.
g. In most of the times the code has a high quality. The results are always visible.
h. Redue the bugs which were caused by the differences between documents and codes.
i. Helps the developer to prioritize the designs. Which one should do immediately, and which one should do in next iteration.
j. Compare with traditional development, TDD can find more bugs.
Disadvantages
a. It's hard to predict what mock will be using in the Unit Test. The developer may have to modify the unit test after finished the functional code.
b. The tests themselves become part of the maintenance overhead of a project. Badly written tests is hard to maintain, and it may cause problems that real failures will be ignored. So the test code should also has a high quality.
c. Focus on test and requirements but not design at the beginning of the development cycle. Although developer can optimize the design druing the refactoring, but it'll add many works, sometimes you have to rewrite all of the codes.
Summary
The test code should be high quality, easy to maintain and easy to extend. Complex test code may increase the costs of maintenance.
TDD focus more on functions and features, less on design at the beginning of the development. So it's better to design the architecture before doing the development
