Learning Test-Driven Development

Foreword

Throughout my 30-year career as a computer science and software engineering educator, especially since my brief stint in industry in 2001, few other techniques have shaped and pervaded my teaching (and research) as much as automated unit testing, the general approach that test-driven development (TDD) operationalizes into a specific, yet widely applicable technique. 

I still remember catching on to TDD in a concrete sense, almost as a side effect, after adopting Martin Fowler’s 2003 text, UML Distilled (3rd edition), as a UML reference for my object-oriented development course. There, Martin discusses three key practices that are usually found in successful iterative development processes: automated regression tests, refactoring, and continuous integration. This concise description strongly resonated with me, and I’ve always enjoyed convincing my students to have more fun by writing additional code to test the rest of their code and receiving instant feedback in the form of colorful test results.

My other aha moment came almost a decade later, around 2012, when I started to listen to some Software Engineering Radio podcasts about software architecture. I was reading up on some of the references mentioned in the podcasts and came across a brief subsection entitled “Serendipitous Architecture” in “Uncle Bob” Robert C. Martin’s book Agile Software Development: Principles, Patterns, and Practices, which discussed how focusing on making one’s code testable almost automatically ...