TDD and requirements

Someone challenged me on the effectiveness of TDD when it’s not clear what we got to build yet. How can you practice it if there are no clear requirements to guide writing those tests first?

I think the answer here is very contextual. In a feature factory the requirements are handed-off to devs, and they are (we hope) well defined. Starting with tests is easier here.

In a truly agile organisation, you don’t usually start with requirements, but with a problem to solve. And there could be multiple solutions to a problem. We then don’t just choose one and go all-in, but we try to design an iterative learning process made of conversations, experiments and feedback.

TDD is about design after all, not testing. So does it make sense to design for maintainability if we’re not sure what behavior will stick around?

I don’t have a good answer here yet, but a possible approach could be to commit to make something better only when it meets our pre-defined goals, because that means it’ll stick around and we want to design it well.

Of course, we need to deliberately decide to refactor asap, and not give up to external pressure to rush to the next thing.

What do you think?