It is a fairly traditional way of doing it. TDD usually means you kinda know what is going on up front. If you work in a org where the sales guy can make up a

It is a fairly traditional way of doing it. TDD usually means you kinda know what is going on up front. If you work in a org where the sales guy can make up a feature and you need it done yesterday that can be a tough sell that you need time to write tests 'thats what we got QA for'. The refactor at this point is a daunting task. It would even be a decently expensive one. What comes out on the other end is effectively from the end users point of view, the same. I personally like working with a decent QA team. They challenge you to do better. They take a special glee in breaking your code in ways you did not think of. You can also use their test plans to write automated tests. So that way they can go think of more devious ways to break your code. Also sometimes developers can go off the deep end and over do things. It is nice to have a semi neutral third party saying what is important to test or not. Also one thing to keep in mind is many of these integration testing frameworks are basically tedious coding exercises. Especially if you are external API heavy. > it's definitely not a cheap alternative You may have hit on why many orgs like the idea of TDD. It pushes the idea that I have someone who can write code well they can write the tests too. Skipping over the fact that takes time and energy away from other things.