A guided path for TDD
A Guided Path to Test-Driven Development - TDD
I do not recall who introduced me to Test-Driven Development (TDD), but I have always been interested in the testing aspect of software development. I vividly remember reading the iconic book Test-Driven Development By Example by Kent Beck on my commute. Every page was a discovery, and I felt a sense of frustration, as the baby steps conflicted with my confidence that my code would work.
However, given the context of my early career, I did not have the opportunity to explore TDD further. The places I worked at unfortunately cared more about delivering tasks quickly than sacrificing time for testing. I share more about my TDD history in a blog post, but I was astonished by the lack of care for testing among practitioners. My intention here is to share my previous experience with writing tests and resources that I think are helpful. This is not a definitive guide to testing, but rather a structured way to get started.
Table of contents
1. Introduction
- What is testing? - Discover what a test is from the perspective of a practitioner and the different shapes that are out there to distribute the different types of tests from the point of view of TDD
- Should you test? - In this section there is a discussion about testing or not and its benefits are discussed. More specifically on the automation part of it
- A gentle introduction to TDD - TDD is introduced as a methodology and describes its different flavors
- The many types of tests in software testing - Integration? End-to-end? Acceptance? Let’s see how they fit from a testing point of view
- The differences between frontend and backend - Tips that are hidden from practitioners’ point of view writing tests for client and server applications.
2. Changing your mindset
3. Building software with tests X software without tests
4. Frameworks available for testing
- PHPUnit
- Jest
- Jasmine
- Testing library
- Junit
5. Test doubles
- The history
- Mocks, dummies, spies, fakes - testing your code
- Are true mocks evil?
7. Advanced topics
- On one hundred percent code coverage - how to approach coverage and void misusing it
- Test Driven Development anti-patterns
- TDD anti-patterns - The liar, excessive setup, the giant, slow poke
- TDD anti-patterns - The mockery, the inspector, the generous leftovers and the local hero
- TDD anti-patterns - The nitpicker, the secret catcher, the dodger and the Loudmouth
- TDD anti-patterns - The greedy catcher, The sequencer, Hidden dependency and The enumerator
- TDD anti-patterns - The stranger, The operating system evangelist, Success against all odds and The free ride
- TDD anti-patterns - The One, The Peeping Tom, The Flash and The Jumper
7. Strategies for testing
8. Empirical evidence
- How effective is test-driven development?
-
Bissi, W.; Serra Seca Neto, A.G.; Emer, M.C.F.P. The effects of test driven development on internal quality, external quality and productivity: A systematic review. Inf. Softw. Technol. 2016, 74, 45–54
- It examines articles published from 1999 to 2014.
- The analysis shows 76% of studies found TDD significantly boosts internal quality and 88% noted improvements in external quality.
- external quality is defined as:
- Defect Density: This is often evaluated through black box testing, where the number of test cases that pass or fail indicates the stability and reliability of the software.
- User Experience: This includes factors such as usability, performance, and the software’s ability to meet user expectations and requirements effectively.
- external quality is defined as:
- However, it also reveals mixed results for productivity—particularly a drop in industrial settings.
-
Rafique, Y.; Miši´c, V.B. The Effects of Test-Driven Development on External Quality and Productivity: A Meta-Analysis. IEEE Trans. Softw. Eng. 2013, 39, 835–856
- TDD shows a small positive impact on code quality but minimal effect on productivity.
- Industrial studies indicate a greater decline in productivity compared to academic ones.
- Factors like developer experience and task size play significant roles in quality improvement.
-
Benato, G.B.; Vilela, P.R.S. Test-Driven Development: Uma revisão sistemática. Rev. Bras. Comput. Apl. 2021, 13, 75–87
- Test-Driven Development (TDD) results in a reduction in the number of defects found in the most advanced phases of software development. Specifically, it has been found that the use of TDD allows a 50% improvement in the defect rate of functional system tests, as analyzed in a study by Maximilien and Williams (2003).
-
Desai C, Janzen D, Savage K. A survey of evidence for test-driven development in academia. ACM SIGCSE Bulletin. 2008 Jun 1;40(2):97-101
- TDD presents a potential solution to enhance software testing skills among students
- Quality of Code: Most controlled experiments comparing TDD with other testing practices indicate an improvement in code quality. The results show a reduction in defects by approximately 35% to 45%. This is attributed to the practice of writing tests before developing code, which forces programmers to consider functionality and necessary conditions early in the development process, leading to better design decisions
- Student Productivity: The impact of TDD on productivity varied among studies. Some experiments reported significant increases, with productivity improvements ranging from 24.5% to 50%. However, there were also studies that observed minimal or even negative effects on productivity, showing reductions between 5% and 10%
- Increased Confidence and Understanding: Surveys conducted with students indicated that TDD contributes to greater program understanding and confidence in their coding abilities
-
Lui, K.M., Chan, K.C.C. (2004). Test Driven Development and Software Process Improvement in China. In: Eckstein, J., Baumeister, H. (eds) Extreme Programming and Agile Processes in Software Engineering. XP 2004. Lecture Notes in Computer Science, vol 3092. Springer, Berlin, Heidelberg
- Software Quality: TDD has been shown to improve software quality by reducing the number of defects and accelerating defect resolution. Data collected revealed that teams using TDD could fix defects significantly faster than those not using it, producing fewer defects overall. For example, TDD teams fixed 97% of defects within one day versus 73% for non-TDD teams