Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TDD did not live up to expectations

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

11–20 of 450 posts

Re: TDD did not live up to expectations

#11

Post by thinkingkong »

gkop wrote: post #4

There are at least several other advantages to TDD the article misses: * Faster development feedback loop by minimizing manual interactions with the system * The tests are an executable to-do list that guides development, helping you stay focused and reminding you what the next step is * Provides a record of the experimentation taken to accomplish a goal, which is especially useful when multiple developers collaborat…

Except in order to have a checklist you have to have your design and implementation up front which is out of reach for most developers.

If were testing high level results in multiple cases thats cool. But a lot of the time youre going to try different approaches that may modify or involve changing your output.

Re: TDD did not live up to expectations

#12

Post by _puk »

austenallred wrote: post #3

The 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.

Re: TDD did not live up to expectations

#14

Post by Cephlin »

willvarfar wrote: post #9

No article about TDD, particularly one that shouts out to the respected Ron Jeffries http://ronjeffries.com/ , is complete without mentioning the TDD Sudoku Fiasco :) Ravi has a nice summary: http://ravimohan.blogspot.se/2007/04/learning-from-sudoku-so... Peter Norvig's old-fashioned approach is excellent counterbalance: http://norvig.com/sudoku.html

Uncle Bob always has some clever things to say on TDD too: http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar...

and: http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-w...

Re: TDD did not live up to expectations

#15

Post by [deleted] »

_puk wrote: post #12
austenallred wrote: post #3

The 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.

[deleted]

Re: TDD did not live up to expectations

#16

Post by norswap »

TDD never worked for me, I believe because of the nature of my work: research code, very explorative in nature. I do not now in advance how the interface will turn up, so it's hard to anticipate the interface in my tests (or it leads to a lot of wasted).

Nowadays I mostly test with "redundant random generation testing": generate random but coherent input, run logic, then... Either I can reverse the logic, and I do that and verify that I get back the original input. Or I can't and then I simply write a second implementation (as simple as possible, usually extremely inefficient). This finds bugs that classical unit and integration testing would never find.

Re: TDD did not live up to expectations

#17

Post by ryanmarsh »

My 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 clarity to the cluttered mind of the developer neck deep in complexity. I find my pairing partners write much less code, and much better code (even without good refactoring skills) when they write a test first. Few people naturally poses this kind of focus.

2. "Done"

This one caught me by surprise. My students often tell me they like TDD because when they're done programming they are actually done. They don't need to go and begin writing tests now that the code works. They like the feeling of not having additional chores after the real task is complete.

Re: TDD did not live up to expectations

#18

Post by hyperpallium »

thinkingkong wrote: post #11
gkop wrote: post #4

There are at least several other advantages to TDD the article misses: * Faster development feedback loop by minimizing manual interactions with the system * The tests are an executable to-do list that guides development, helping you stay focused and reminding you what the next step is * Provides a record of the experimentation taken to accomplish a goal, which is especially useful when multiple developers collaborat…

Except in order to have a checklist you have to have your design and implementation up front which is out of reach for most developers. If were testing high level results in multiple cases thats cool. But a lot of the time youre going to try different approaches that may modify or involve changing your output.

TDD is waterfall

Re: TDD did not live up to expectations

#20

Post by falcolas »

gkop wrote: post #4

There are at least several other advantages to TDD the article misses: * Faster development feedback loop by minimizing manual interactions with the system * The tests are an executable to-do list that guides development, helping you stay focused and reminding you what the next step is * Provides a record of the experimentation taken to accomplish a goal, which is especially useful when multiple developers collaborat…

> The tests are an executable to-do list that guides development

So what generates the to-do list when you're building out the tests (arguably the harder of the two tasks, when the tests drive the design).

> Provides a record of the experimentation taken to accomplish a goal

If you're doing a proper refactor cycle, those tests will vanish (or change) as the code evolves. You're back to relying on your source control, which provides the benefit with or without tests.

There are benefits to TDD; these two are not among them IMO.

Post reply on HN