PBT-centric TDD has worked very well for us.
TDD did not live up to expectations
21–30 of 450 posts
Re: TDD did not live up to expectations
#22My day job is teaching TDD. Just like other agile rhetoric I've found the benefits are not what the proponents advertise. I teach it through pairing and here's what I find. TDD provides two things. 1. Focus Focus is something I find most programmers struggle with. When we're starting some work and I ask, "ok what are we doing here" and then say "ok let's start with a test" it is a focusing activity that brings clarit…
Regarding Focus, I have to agree mostly that pairing is amazing for focus. I've found that I never lose focus when I pair. And we almost always come up with better solutions when we think out loud.
Regarding being done, often this works for more cut and dry elements, which are increasingly more like boilerplate. But this doesn't hold up for what I nowadays spend most to my time on, which is UX and the experience of using the application.
Re: TDD did not live up to expectations
#23TLDR: TDD done badly doesn't work well.
I'd say a better summary is that TDD won't transform OK programmers into great programmers.
Re: TDD did not live up to expectations
#24Gonna throw the baby out with the bathwater because bad programmers write bad tests.
Re: TDD did not live up to expectations
#25I disagree with the assertion that TDD takes more time. TDD takes less time if you factor in the reduction of errors TDD helps prevent.
This article should be renamed, “TDD doesn’t work if you don’t do it right.”
This article seems to argue for Big Design Up Front. Ok, if you do that, then why not write the tests for those designs after you make the design – then the code you write confirms to the design.
I don’t think anyone advocates that writing tests is the same as the design process. Tests are the result of design not the other way around. The gray area is not design up front – but how much design up front.
Re: TDD did not live up to expectations
#26The problem with TDD is that we flawed humans are writing the tests in the first place. If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. I use it on occasion as a good sanity check to make sure I didn't break anything too obvious, but this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.
> this idea that TDD is a panacea where no bugs ever survive
I don't think I've heard many people claim that. Rather the point I've seen made is that it not only ensures you've got tests, doing them up front encourages developers to write code in a way that is easy to test, which usually happens to be higher quality, more loosely coupled code.
When it comes to writing code there are no silver bullets, TDD included.
Re: TDD did not live up to expectations
#27The problem with TDD is that we flawed humans are writing the tests in the first place. If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. I use it on occasion as a good sanity check to make sure I didn't break anything too obvious, but this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.
"I use it on occasion as a good sanity check to make sure I didn't break anything too obvious" That sounds more like unit tests than TDD. With TDD you should already know that you didn't break anything.. If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input; it is not however going to determine if you did that in the best possible way.
This is a good and cool post. TDD is less susceptible to "sucky code" for two reasons:
1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD.
2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code.
Writing tests after you've written code strongly encourages you to write implementation tests rather than specification tests. Both are important and useful, but for separate things (if you have to change your specification tests it's probably because you need to bump a minor or major version number for your software).
Re: TDD did not live up to expectations
#28The problem with TDD is that we flawed humans are writing the tests in the first place. If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. I use it on occasion as a good sanity check to make sure I didn't break anything too obvious, but this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.
> The problem win TDD is that we flawed humans are writing the tests in the first place.
A general AI could have the same kind of problem, and if we had specialized AIs, we could presumably create the target software directly anyway...
Re: TDD did not live up to expectations
#29Maybe the title should be: TDD did not live up to my expectations?
I too, like the author, have been practicing TDD for > 10 years. Test, implement, refactor, test... that's the cycle. If you follow that workflow I've never seen it do anything to a code base other than improve it. If you fail on the refactor step, as the author mentions, you're not getting the full benefit of TDD and may, in fact, be shooting yourself in the foot.
I've read studies that have demonstrated that whether you test first or last doesn't really have a huge impact on productivity.
However it does seem to have an impact on design. Testing first forces you to think about your desired outcomes and design your implementation towards them. If you think clearly about your problem, invariants, and APIs then you will guide yourself towards a decent system.
The only failing I've seen with TDD is that all too often we use it as a specification... and a test suite is woefully incomplete as a specification language. A sound type system, static analysis, or at the very least, property-based testing fill gaps here.
But for me, TDD, is just the state of the art. I've yet to see someone suggest a better process or practice that alleviates their concerns with TDD.
Re: TDD did not live up to expectations
#30It always startles me when people assume that one programming technique either works for every type of programming or doesn't work for every type.
Working on Perl 6 compilers, an extensive set of tests was our best friend. It was (probably still is, I haven't had time to help the last few years) utterly routine to write tests first and then write the code to make them work. It was a perfect way of working on it.
On the other hand, one of my personal projects in Perl 6 is abc2ly. It has lots of low level unit tests, great. But almost everything really interesting the program does is really hard to test programmatically. How would I write tests to make sure the sheet music PDF generated has all the correct notes and looks nice? That problem is significantly harder than generating the sheet music in the first place!