Extreme Programming (XP) introduced us with multiple central techniques like pair-programming, small releases, incremental planning, continuous integration and many more. One of the key techniques of XP is test-first programming! The whole process from a small design, incremental code and continuous testing is known as Test Driven Development (TDD).
The test-first programming constitutes of the following four steps in loop until the functionality is implemented:
- Figure out the high-level scope
- Start with a unit test for a smallest increment for the new “unimplemented” functionality.
- Run the unit test. If the test passes, go to step 1 and continue with the unimplemented functionalities. If the test fails, go to step 4.
- Fix the unit test and go to step 3.
The test-first approach forces the developer to think about:
- Testable code
- Unit testing
- Automate test execution
- Reduce regressions
The broad goals of test-first approach include:
- Software agility i.e. develop programs that are more capable of accepting changes
- To program faster
- To increase confidence of developer and the customer
- To increase code quality by reducing defect rates
- To reduce code debt
Matthias M. Muller and Oliver Hagner from University of Karlsruhe, Germany, wanted to validate if there are any advantages or disadvantages for a single programmer when switching from the traditional development process to test-first . They conducted an experiment for CS students who have taken XP course before and had moderate programming background. The main goals of the experiment were to compare the effectiveness of test-first programming over control group (CG) which is traditional programming with testing followed by coding using the three focus areas:
- Programming efficiency
- Code reliability
- Program understanding measured as proper reuse of existing methods.
The experiment data led to the following observations:
- Program efficiency: If the developer switches from traditional development to test-first programming, he does not program faster necessarily and does not arrive at the solution faster.
- Code reliability: Test-first pays off slightly in terms of increased reliability but not considerable enough to consider it as a definite improvement.
- Program understanding (code reuse): The experiment clearly showed that test-first programming allows to reuse existing methods faster correctly. The main reason was the ongoing test strategy of the test-first. It was easier to identify the test cases that’s failing and fixing the method or interface related to test case correctly.
However the experiment is done in a controlled environment and the findings could not be generalized. But what do you think about the results of the experiment? What’s your experience with using test-first or Test Driven Development (TDD) approach? Looking forward to hear your views.
1. Müller, M. and O. Hagner (2002). “Experiment about test-first programming.” Software, IEE Proceedings 149(5): 131-136.
2. Image source: On measuring code coverage http://securesoftwaredev.com/2012/10/15/on-measuring-code-coverage/