Red, green, refactor
Writing the test before the code sounds backwards, but it's how you build software that clients can trust and developers can evolve with confidence.
Building software with precision and confidence. Test-Driven Development ensures every component is verified, leading to robust, maintainable, and high-quality applications.
In the ever-evolving landscape of software development, the quest for quality, reliability, and maintainability is paramount. Test-Driven Development (TDD) isn't just a methodology; it's a philosophy that shapes how we approach building software, ensuring that every line of code is purposeful, testable, and contributes to a robust final product. As I've mentioned, "I'm great at figuring out what a project actually needs, mapping it out and helping the client get there." TDD is a critical part of that "mapping out" process, ensuring we build the right thing and build it right.
Test-Driven Development is a software development process where developers write tests before writing the actual code. The cycle is simple yet profound:
This iterative process ensures that code is always written with testability in mind and that there's a comprehensive suite of tests verifying the application's behavior. "It's about finding the right fit," and TDD helps ensure that fit from the ground up by clearly defining expected outcomes before development begins.
Adopting TDD offers significant advantages, translating into higher quality software and more efficient development:
As I've noted in my approach to project planning, "User stories provide an invaluable and effective tool for properly planning, scoping, communicating, and managing requirements... Automated Testing: Stories and criteria form the basis for writing automated tests (unit tests, integration tests, behavior-driven development tests) that verify functionality continuously." TDD is the practical application of this principle at the code level.
The concept here demonstrates a workflow where unit tests are written for individual components. It highlights how dependencies are "mocked" to ensure tests are isolated and focus only on the unit under test. External services, for example, are prime candidates for mocking, as we test our interaction with them, not the external service itself. This is crucial for reliable and fast-running unit tests.
In my development workflow, TDD is a guiding principle. "Tools like ChatGPT and Claude help me quickly scaffold and test ideas, especially in TDD workflows." This AI-assisted approach can "bootstrap suites, then [I] iterate manually to keep them reliable." The aim isn't to replace developer insight but to augment it, making the process of creating comprehensive test coverage more fluid and efficient. Even on challenging projects, like a UK council Laravel app I worked on - I've "'bandaid‑patched' priority features with PHPUnit tests on an unstructured codebase when no budget for a refactor," demonstrating the adaptability of testing principles.
2026 update This is exactly where TDD earns its keep in the age of AI coding agents. When an agent can generate a whole feature in seconds, a red-green test suite becomes the guardrail that tells you whether the generated code actually does what you asked — write (or agree) the failing test first, then let the agent make it pass. The test is the spec the agent is held to, and it's what stops "looks plausible" from shipping as "works".
While TDD often starts with unit tests, its principles extend to higher levels of testing. Functional tests verify that different parts of the system work together correctly, often simulating user workflows. Acceptance tests, typically defined from user stories, confirm that the software meets the business requirements. "Acceptance criteria define 'Just good enough'. Once you know what needs to be done, you can do that, and then no more." This ensures development effort is focused and delivers what's truly valuable.
The idea of an "Automated User Journey Tester" illustrates how functional tests ensure the frontend behaves as expected. By simulating user interactions and verifying outcomes, these tests are crucial for maintaining a high-quality user experience, especially as applications grow and evolve.
2026 update The tools have moved on since this was written. For JavaScript, Vitest has largely become the default over Jest — same familiar API, far faster, first-class TypeScript and ESM support. For end-to-end and functional flows, Playwright is now the go-to. And on the Laravel side, fresh applications ship with Pest as the default test runner (it sits on top of PHPUnit, so everything here still applies — Pest just gives you a cleaner, more expressive syntax).
My experience across numerous projects, from a luxury furniture e-commerce site to internal data management tools and complex API integrations has consistently shown that a disciplined approach to testing, particularly TDD, is a hallmark of high-quality software. It's about building systems that clients can trust and developers can evolve with confidence. Embracing TDD is about fostering a development culture that prioritizes quality, clarity, and long-term maintainability.
The primary goal of TDD is to write clean code that works. By writing tests before the actual code, developers are forced to think about the requirements and design of a feature more thoroughly, leading to simpler, more focused code and a comprehensive suite of automated tests.
No, TDD principles can be applied to various types of software development, including frontend development (with tools like Jest, Cypress, or Playwright for testing UI components and user interactions) and even infrastructure code. The core cycle of Red-Green-Refactor is adaptable.
Initially, TDD might seem to slow down development because you're writing tests first. However, in the long run, it often speeds up the overall project by reducing debugging time, making refactoring safer and faster, and improving code quality, which leads to fewer bugs and less rework later on.
Yes, TDD techniques can be applied to existing projects, though it can be more challenging. A common approach is to write tests for new features or when refactoring existing code. For legacy code without tests, you might start by writing characterization tests to understand existing behavior before making changes.
Mocks are simulated objects that mimic the behavior of real dependencies (like databases, external APIs, or other services) in a controlled way. They are used in unit testing to isolate the code being tested, making tests faster, more reliable, and independent of external systems. This allows you to test a unit of code without worrying if, for example, a third-party API is down.
All articlesI help content-rich organisations understand their data and pull it back into one place. Tell me what specific problems you're having and I'll be happy to talk solutions with you.
Tell me what specific problems you’re having and I’ll be happy to talk solutions with you.