Most pro-TDD articles I read take the perspective that people who don't agree with it just haven't tried it, or don't understand it enough yet, or things along those lines.
I'm curious to hear back from anyone who has bought into TDD full-bore and recognized all the benefits, but has instead decided to go back to test-last development (write the features, and then write tests purely for code coverage). If so, why?
I'm not one of the people you're looking for, but like so many things, a flexible mix based on the character of the work at hand is usually most effective. Sometimes (sometimes) you doodle to think, sometimes you code to think: how do you write a failing test for doodling?
FWIW I was writing what were effectively unit tests, and doing them essentially first or all but first, in the late eighties before (I think) TDD even had letters, but it didn't rule my life. I was chastised for being too new and not good enough to carve the whole monolith at one sitting. I did what I needed to anyway.
Resource Acquisition is Initialization, so just wait for current trends to go out of scope and you'll enjoy automatic, orderly and all but guaranteed destruction of kulaks and unfoobers.
Well I've had projects where I've written a lot of tests before really having the overall design right (without realizing it of course) and ended up wishing I'd waited a bit before writing the tests, because I had to redo a lot of them and it slowed down the process. Of course if you just do things right from the start this won't happen, but I often don't.
The original paper on Mathematics was able to appeal to a long history where mathematical advances led to new discoveries in science, particularly physics. This blog post simply borrows the phrase while failing to demonstrate any sort of effectiveness for TDD. How long must we endure programming cults with no science behind them?
> How long must we endure programming cults with no science behind them?
Until someone invents a cost-effective way to do science on programming techniques. I'm not holding my breath, because we're talking about workplace habits, communication through code, and team dynamics, which is an altogether different beast than mathematics or physics.
I'm doing a lot of that (UI testing) in my Let's Code Test-Driven JavaScript series (http://www.letscodejavascript.com, starting with episode 41). My next Lessons Learned video (#10, coming out this Friday) covers the underlying theory. There's a free trial if you want to check it out.
If you're more into Java, or then I also do a lot of test-driving of a Swing GUI in my original Let's Play TDD series (http://www.jamesshore.com/Blog/Lets-Play). It's a lot less polished than Let's Code TDJS, but it's free.
I'm curious to hear back from anyone who has bought into TDD full-bore and recognized all the benefits, but has instead decided to go back to test-last development (write the features, and then write tests purely for code coverage). If so, why?