This chapter is from the book
This chapter is from the book
This chapter is from the book
Testing
XP has added a new twist to testing: rather than test after development, XP developers write the test before coding. Developers write unit tests that test each method and every thing that could possibly break. When they've written all their tests for that component, they write only enough code to pass the test. Writing tests such as this gives us a complete suite of tests for our system and we write the simplest thing that could possibly work. Work on the class continues until it passes all the tests in the suite. At this point the code is checked into the development team's source code control repository.
Testing in this committed way gives developers confidence in their code, and is the basis for refactoring. Refactoring without a test suite results in tentative development because we're never quite sure what will break if we refine untested code. In fact, refactoring without a test suite is fairly risky business and the old adage "if it ain't broke don't fix" is true. This means you will be stuck with the code you deployed because changing for the sake of improvement is a hard sell to both developers and customers.
The tests we've written will be added to our automated test harness or framework. Using an automated test harness enables us to run tests continuously as integrations occur. Doing this also gives you the flexibility to run after hours and stress tests. With automation, both business and technical teams get constant feedback on the state of the system with solid, real metrics.
Testing is good—we know that, but how do we get developers to write tests? XP developers work in pairs and use automated test frameworks such as Junit and VBUnit to write unit tests. Sharing the testing task and the use of tools lessens the chore of test writing. We'll learn how to use these tools in Hour 14, "Unit Testing with Java Tools" and Hour 15, "Unit Testing with Microsoft Tools."