Well, maybe not in theory, but in practice – definitely.
Test-drive development is a way to program where you write an automated unit test that fails first, the you write code and check that the test runs ok. Brilliant theory for an ideal world (doesn’t exist). In practice however it is very seldom that you as a programmer have a full and clear understanding of what is it you are gonna do.
Of course I’m not talking about cases where you need to calculate the result of 2+2. Sure you can write a test case here, it’s rather easy.
And here comes a hard reality where you come to the real place, f.ex. a bank that needs a new program. And here you are with a task that states smth like this “Create a form that have these and these fields and calculates that and that”. You begin with a test case? You are right! That’s what happens if you do this: you kill several days in trying to understand how you build this test case, what fields you need to fill inn to calculate some result. If you’ll try to check a more specific result then you need several extra days to find a person who maybe knows how the value must be calculated.
Because it is very seldom in the real world that programmers work together with persons who both know and can explain to the programmer how the things should be done. Simply because those persons do not exist.
So you wrote the test and now you need to write a calculation algorithm… Hmm, how the hell do we do that? We start building it and magic happens! The algorithm that can calculate the value need all totally different input values then those you’ve written in you test case… Ouch! It happened again?
At the end you’ve used double time to write the code and update you test case in parallel plus the time you’ve killed on the test at the beginning.
So why is it so popular to talk about it and constantly try to use it? Do not know. You need to write test cases when you program difficult logic. That is the fact. But doing it FIRST? It’s just a waste of time and killing of enthusiasm. You won’t be clever and you’ll not write better code if you kill time with the test first.
What really needs to be done before you start programming is to draw a solution.
.