Test-Driven Development and Refactoring

The two most popular XP practices that seem to be adopted by various teams at Microsoft are test-driven development (TDD) and refactoring. The developers I have spoken to who have used the TDD technique swear they would never go back to the traditional "write first, test later" process. They say that by writing the tests up front, they have fewer bugs in their code when they are close to shipping. The only difference I see that they do from what is prescribed by Kent Beck is that the Microsoft testers write their tests at the same time they write their production code, not before they write their production code.

Refactoring is the process of rewriting written material to improve its readability or structure, with the explicit purpose of keeping its meaning or behavior.

In software engineering, the term refactoring is often used to describe modifying source code without changing its external behavior. It is sometimes informally referred to as "cleaning it up." Refactoring is often practiced as part of the software development cycle: Developers alternate between adding new tests and functionality and refactoring the code to improve its internal consistency and clarity. Testing ensures that refactoring does not change the behavior of the code.

Refactoring is the part of code maintenance that doesn't fix bugs or add new functionality. Rather, it is designed to improve the understandability of the code or change its structure and design to make it easier for human maintenance in the future. In particular, adding new behavior to a program might be difficult with the program's given structure, so a developer might refactor it first to make it easy and then add the new behavior.

Refactoring has been around Microsoft for years. I know when I was in the NT group in 1991, developers were refactoring and optimizing their code as needed or as a general practice, and this was in the early days of the product when the code was just being written.

The following is an explanation taken from http://encyclopedia.laborlawtalk.com/Extreme_programming:

Test-driven development (TDD) is a programming technique heavily emphasized in extreme programming. Essentially, the technique involves writing your tests first [and] then implementing the code to make them pass. The goal of TDD is to achieve rapid feedback and implement the "illustrate the main line" approach to constructing a program.

1.	Write the test It first begins with writing a test. In order to write a test, the specification and requirements must be clearly understood.
2.	Write the code The next step is to make the test pass by writing the code. This step forces the programmer to take the perspective of a client by seeing the code through its interfaces. This is the design-driven part of TDD.
3.	Run the automated tests The next step is to run the automated test cases and observe if they pass or fail. If they pass, the programmer can be guaranteed that the code meets the test cases written. If there are failures, the code did not meet the test cases.
4.	Refactor The final step is the refactoring step, and any code clean-up necessary will occur here. The test cases are then re-run and observed.
5.	Repeat The cycle will then repeat itself and start with either adding additional functionality or fixing any errors.

You can go about using TDD in various ways. The most common one is based on KISS (keep it simple, stupid) or YAGNI (you ain't gonna need it). This style focuses on writing code any way necessary to pass the tests. Design and proper principles are cast aside in the name of simplicity and speed. Therefore, you can violate any rule as long as the tests will pass. This can be unsettling for many at first, but it allows the programmer to focus only on what is important. However, the programmer pays a higher price in the refactoring step of the cycle because the code must be cleaned up to a reasonable level at this point before the cycle can restart.