Niềm tin rằng một sự thay đổi sẽ được dễ dàng để làm một cách chính xác làm cho nó ít có khả năng thay đổi sẽ được thực hiện một cách chính xác. - Gerald Weinberg1 Một lập trình viên XP viết một đơn vị kiểm tra để làm rõ ý định của mình trước khi ông làm cho một sự thay đổi. | Chapter 11 Test-Driven Design The belief that a change will be easy to do correctly makes it less likely that the change will be done correctly. - Gerald Weinberg1 An XP programmer writes a unit test to clarify his intentions before he makes a change. We call this test-driven design TDD or test-first programming because an API s design and implementation are guided by its test cases. The programmer writes the test the way he wants the API to work and he implements the API to fulfill the expectations set out by the test. Test-driven design helps us invent testable and usable interfaces. In many ways testability and usability are one in the same. If you can t write a test for an API it ll probably be difficult to use and vice-versa. Test-driven design gives feedback on usability before time is wasted on the implementation of an awkward API. As a bonus the test documents how the API works by example. All of the above are good things and few would argue with them. One obvious concern is that test-driven design might slow down development. It does take time to write tests but by writing the tests first you gain insight into the implementation which speeds development. Debugging the implementation is faster too thanks to immediate and reproducible feedback that only an automated test can provide. Perhaps the greatest time savings from unit testing comes a few months or years after you write the test when you need to extend the API. The 1 Quality Software Management Vol. 1 Systems Thinking Gerald Weinberg Dorset House 1991 p. 236. 83 unit test not only provides you with reliable documentation for how the API works but it also validates the assumptions that went into the design of the API. You can be fairly sure a change didn t break anything if the change passes all the unit tests written before it. Changes that fiddle with fundamental API assumptions cause the costliest defects to debug. A comprehensive unit test suite is probably the most effective defense against such
