Better Software - January 2008 - (Page 67) RECOMMENDED TWO OR MORE PLAYERS FOR TDD, running the tests frequently as you work on the system code. Most games have a clear etiquette— instructions for setting up the game and protocol for playing your turn, taking turns, and ending a round of play. TDD is a multi-player “game.” The object of the game is to make sure the code-base always contains working software. The secret to winning is establishing team TAKING TURNS (INTEGRATE) Integrate when your new tests and all pre-existing tests pass. Only one person should integrate at a time. A physical token (like a stuffed toy or a hat) signals who is “it”; you can’t integrate unless you have the token. a real environment using real data. In case you were wondering, that was the sound of a landmine exploding! A passing automated regression test suite confirms code stability and enables iteration and release testing to be more effective and efficient. Proceed with other forms of testing—exploratory, performance, load, security, usability, etc. (See the StickyNotes for more information.) Figure 6: Environments etiquette. TDD benefits will only be as good as the weakest level of commitment and discipline to the team etiquette. You’ve got to play to win, and the team can’t win if you don’t all play. SETTING UP THE GAME (ENVIRONMENTS) A shared, version-controlled code repository contains the completed code and passing tests. Developers have a local snapshot of the repository and a database sandbox. A shared test environment contains a deployed copy of the repository. Analysts, subject-matter experts, and testers use the test environment for investigative and acceptance testing. Again, the first step is to synchronize and merge your local environment with the shared repository. Run the full test suite to verify stability. Perform a checkin with the shared repository, and return the integration token. Check-in should trigger an automated process that builds the code and runs the test suite, as shown in figure 6. BEST-BEFORE DATE Most business systems span multiple years, teams, and projects, as the system progresses through the different phases described below and shown in figure 7. • Greenfield: A project team builds the system from scratch using TDD. The system is deployed into production. • Operations: Code and tests are handed down to the operational support and maintenance team. Ideally the teams use TDD on bug fixes and minor enhancements. However, if team members are not trained in TDD, and if the tests are difficult to maintain the tests will be ignored and will “dry up” (nobody likes hand-me-downs). • Enhancement: A parallel branch of code and tests is handed down to another project team to develop a major enhancement. Ideally this team uses TDD as it builds on the existing code and test base. Now that two teams are working in parallel, we could end up with clashes in the test suite that are tricky to resolve. • Legacy: Yet another parallel branch of code is handed down to yet 67 ENDING A ROUND (DEPLOY) Coding and integration continue until the functional test passes. The completed feature can be deployed to the test environment from the repository. Run the full test suite to verify stability of the build. YOUR TURN (WORKING LOCALLY) Development starts by creating a functional test, which is checked in while still failing. Developers work in parallel on different aspects of the unit tests and system code related to this functional test. The first step is to synchronize your local environment with the shared repository. Run the full test suite to verify stability of the code base. Proceed with PARTS SOLD SEPARATELY Another unfortunate TDD misnomer is “acceptance test,” which refers to business-level automated tests. This term leads teams to believe that if their code is built test first and all “acceptance” and unit tests pass, then the code is implicitly accepted by the customer. They feel little need for investigative testing by experienced testers or subject-matter experts. Ironically, most of these teams will report that their “defect-free” system crashed in www.StickyMinds.com JANUARY/FEBRUARY 2008 BETTER SOFTWARE http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.