Live data from Hacker News

The Failures of "Intro to TDD"

blog.testdouble.com

81–85 of 85 posts

Re: The Failures of "Intro to TDD"

#81

Earlier quoted context omitted.

The Mandelbrot set does consist of readily verifiable discrete data points, after all. Indeed it does, but in order to verify them I see only two options. One is that you have to choose test cases where the answer is trivially determined. However, with this strategy, it seems you must ultimately rely on the refactoring step to magically convert your implementation to support the general case, so the hard part isn’t r…

Whether the spec itself is correct is another question, but then we’re getting into verification vs. validation, a different issue. I think you get to the nub of it here. TDD lets you develop a spec that is consistent with requirements (the subset so far implemented) and the code at all times. Writing a comprehensive suite of tests before any production code is like writing a complete spec without any clue as to its…

I think you get to the nub of it here. TDD lets you develop a spec that is consistent with requirements (the subset so far implemented) and the code at all times.

This is another TDD-related argument that I just don’t understand.

A specification might say that the function add returns the sum of its arguments.

A unit test might verify that add(1,1) = 2.

One of these describes the general case. One of them describes a single specific case. Unless your problem space is small enough to enumerate every possible set of inputs and the expected result for each of them, no amount of unit tests can replace a full specification of the required behaviour. Unfortunately, not many real world problems are that convenient.

Re: The Failures of "Intro to TDD"

#82
post #75

Earlier quoted context omitted.

I kind of wish I had the time to actually do it right now and see how it works. But here's how I imagine it going: 1) Establish tests for the is-in-set function. You're absolutely right that the most obvious way to do this meaningfully is to reimplement the function. A better approach would be to find some way to leverage an existing "known good" implementation for the test. Maybe a graphics file of the Mandelbrot se…

1) I absolutely would NOT do the "write a test; write just enough code to pass that test; write another test..." thing for this. My strong inclination would be to write a fairly complete set of tests for is-in-set, and then focus on making that function work. The latter is what I’d expect most developers who like a test-first approach to do. I don’t see anything wrong with it, either. I just don’t think it’s the same…

I almost feel like we should come up with a "How the hell would you test this?" challenge for TDD advocates. At least, my impression is it is mostly naïveté rather than snake oil.

Re: The Failures of "Intro to TDD"

#83
post #55

Earlier quoted context omitted.

> I think this is a great explanation of a lot of the obvious pitfalls with "basic" TDD, and why so many people end up putting in a lot of effort with TDD without getting much return. If you have the cash, spring for Gary Bernhardt's Destroy All Software screencasts. That $240 was the best money my employer ever spent on me. Trying to learn TDD on your own is asking for a lot of pain, and all you'll end up doing is r…

+1 for DAS. Gary's great and I think we agree pretty closely on these issues.

Were there any particular seasons your found useful in Destroy All? It seams like it's mixed where there's just snipped of TDD spread around at will, whenever the need hit.

(I ask because there's no way I'm going to have time to watch/absorb all those things).

Re: The Failures of "Intro to TDD"

#85
post #83
post #55

Earlier quoted context omitted.

+1 for DAS. Gary's great and I think we agree pretty closely on these issues.

Were there any particular seasons your found useful in Destroy All? It seams like it's mixed where there's just snipped of TDD spread around at will, whenever the need hit. (I ask because there's no way I'm going to have time to watch/absorb all those things).

There was one 4-episode series on testing untested code that I thought was great. Especially because I have a ginormous untested codebase that I have to work with. It's in season 3. Also the one before that series about Test Isolation, that's a great topic.
Post reply on HN