TDD When You Don’t Know What to Build
How do you test what hasn’t been built… when you don’t even know what you're building? What if the only thing we know is the problem, not the solution?
Hello, developers! 🚀
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!5t
Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!
As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇
Now, let's dive into today's micro-topic!
In short
🧪 Test-Driven Development (TDD) thrives when feature requirements are clearly defined. In traditional workflows, TDD helps validate known behaviors and ensures safe implementation. But in product-first teams—where solutions are still being explored—this rigid use of TDD might seem limiting or even counterproductive.
🧠 The mindset shift is viewing TDD not just as a tool for testing, but as a tool for design. In exploratory phases, tests help define interfaces, clarify intentions, and provoke team conversations. Even if a feature is discarded, the process improves decision-making and understanding.
🔧 However, using rigorous test suites too early can slow progress or lead to flawed designs. Instead, use lightweight prototype tests during experimentation. These “throwaway” tests act like scaffolding, helping teams learn quickly. Once a promising solution emerges, transition to robust tests and refactor deliberately.
📈 TDD then becomes a two-phase process: sketch with loose tests while exploring, commit to strong design and thorough testing once the idea proves viable. This approach preserves TDD’s value—even when outcomes are uncertain—by aligning test depth with learning stage.
Tell people what you do, and listen what they do
Test-Driven Development shines when requirements are clear—but what happens when they aren’t? What if the only thing we know is the problem, not the solution?
In a traditional setup (aka feature factory mode), developers receive well-formed specs: input goes in, output goes out, write a test, write the code, move on. TDD works great here. It helps validate behavior early and guides implementation safely. But in product-first teams—where you're exploring solutions, not shipping pre-decided features—TDD may feel like a mismatch.
So, should you still use TDD when the future of the feature is uncertain? Yes!
TDD isn’t not just about verification. It’s also about design. Tests aren’t just checks—writing them drives the process of shaping the interface and clarifying intent. Even if the feature gets thrown away tomorrow, you’re using TDD to force conversations and make better decisions today.
During experiments, where you are really just investigating around, you can use looser, throwaway tests. Think of them as learning scaffolding. They help you converge on a direction. Once you hit a promising result—something that meets a user goal or passes an experiment threshold—you know what’s going to stick. That’s when you harden tests and refactor for maintainability.
The key is committing to revisit the code that survives exploration. Refactor mercilessly as soon as an idea proves valuable. That means overcoming the temptation (or pressure) to skip cleanup and jump to the next thing. No design upfront doesn’t mean no design at all—it means deferring intentional design until you’re confident the code has a future.
TDD in this context becomes two-phase: sketch lightly during the explore mode, then shift to deliberate design once you know a feature is here to stay. The test-first cycle remains—but the kind of test and depth of assertion adapt to the stage of learning. TDD is a powerfuul tool—even when the path is unclear—and you should use it to guide throught, not just to verify code.
Until next time—happy coding! 🤓👩💻👨💻