Test Driven Development or TDD is often defined as writing tests first. This approach is certainly effective at driving simple designs, which yield fewer defects; however, in practice, I’ve rarely seen test first development stick. In fact, I often run into teams who attempted to jump head first into test first TDD and eventually threw their hands up in frustration when either schedules became tight or they ran into scenarios difficult to test. Worse, if management doesn’t fully understand the practice, it’s surely to be sidelined in the face of scheduling pressures.

I prefer to stipulate that a TDD process stresses testing all non-trivial code– whether you test it first or after you’ve written some code doesn’t really matter. As I’ve seen, the results are the same. Code written with testing in mind almost always is simple (and consequently, easier to maintain). Code quality wise too, both processes are similar.

Teams new to developer testing should ensure they can walk (i.e. write tests for non-trivial logic) before attempting to sprint (i.e. write tests first). Once the team is comfortable writing tests and understands how to test difficult scenarios like dealing with databases, etc, then perhaps a test first stipulation can stick. But by then, a developer testing process has most likely already stuck.