UNIT TESTING IN EXTREME PROGRAMMING

3.7 UNIT TESTING IN EXTREME PROGRAMMING

A TDD approach to code development is used in the XP methodology [22, 23]. The key aspect of the TDD approach is that a programmer writes low-level tests before writing production code. This is referred to as test first [24] in software develop- ment. Writing test-driven units is an important concept in the XP methodology. In XP, a few unit tests are coded first, then a simple, partial system is implemented to pass the tests. Then, one more new unit test is created, and additional code is writ- ten to pass the new test, but not more, until a new unit test is created. The process is continued until nothing is left to test. The process is illustrated in Figure 3.3 and outlined below:

Step 1: Pick a requirement, that is, a story. Step 2: Write a test case that will verify a small part of the story and assign a

fail verdict to it. Step 3: Write the code that implements a particular part of the story to pass the

test. Step 4: Execute all tests.

72 CHAPTER 3 UNIT TESTING

Story

Understand

Add a single test

Add code for the test

Execute all tests Fail

Pass

Rework on code

Story complete

Next story

Figure 3.3 Test-first process in XP. (From ref. 24. © 2005 IEEE.)

Step 5: Rework the code, and test the code until all tests pass. Step 6: Repeat steps 2–5 until the story is fully implemented.

The simple cycle in Figure 3.3 shows that, at the beginning of each cycle, the intention is for all tests to pass except the newly added test case. The new test case is introduced to drive the new code development. At the end of the cycle, the programmer executes all the unit tests, ensuring that each one passes and, hence, the planned task of the code still works. A TDD developer must follow the three laws proposed by Robert C. Martin [25]:

• One may not write production code unless the first failing unit test is written.

• One may not write more of a unit test than is sufficient to fail. • One may not write more production code than is sufficient to make the

failing unit test pass. These three laws ensure that one must write a portion of a unit test that fails

and then write just enough production code to make that unit test pass. The goal of these three laws is not to follow them strictly—it is to decrease the interval between writing unit tests and production code.

Creating unit tests helps a developer focus on what needs to be done. Require- ments, that is, user stories, are nailed down firmly by unit tests. Unit tests are released into the code repository along with the code they test. Code without unit tests may not be released. If a unit test is discovered to be missing, it must be cre- ated immediately. Creating unit tests independently before coding sets up checks and balances and improves the chances of getting the system right the first time.

73 Unit tests provide a safety net of regression tests and validation tests so that XP

3.8 JUNIT: FRAMEWORK FOR UNIT TESTING

programmers can refactor and integrate effectively. In XP, the code is being developed by two programmers working together side by side. The concept is called pair programming. The two programmers sit side by side in front of the monitor. One person develops the code tactically and the other one inspects it methodically by keeping in mind the story they are implementing. It is similar to the two-person inspection strategy proposed by Bisant and Lyle [26]. Code inspection is carried out by an author–examiner pair in discrete steps, examining a small part of the implementation of the story in isolation, which is key to the success of the code review process.