One reason why TDD can be a good idea is the cycle involves actually testing the test cases: if you write the test, run it and see that it fails, then write the code, then run the test again and see that it succeeds, you can have some confidence the test is actually testing something (not necessarily the right thing, but at least something). Wheras if you're writing the test after writing the code and expect that it will succeed the first time you run it, it's quite possible to write a test which doesn't actually test anything and will always succeed. (There are other techniques like mutation testing which may get you a more robust indication that your tests actually depend on the state of your software, but I've rarely seem them used in practice).