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

The Failures of "Intro to TDD"

blog.testdouble.com

Post reply on HN
Print view View original

51–60 of 85 posts

Re: The Failures of "Intro to TDD"

#51

Post by vinceguidry »

akeefer wrote: post #23

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. I personally have kind of moved away from TDD over the years, because of some of these reasons: namely, that if the tests match the structure of the code too closely, changes to the organization of that code are incredibly painful because…

> 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 reinventing the wheel.

There are a lot of subtle concepts Gary taught me that I'm still learning to master. You learn what to test, how to test it, at what level to test it, how to structure your workflow to accommodate it.

Re: The Failures of "Intro to TDD"

#52

Post by couchand »

akeefer wrote: post #38
ArbitraryLimits wrote: post #35

Earlier quoted context omitted.

> When TDD isn't a good idea (say, when ... you don't yet know how you want to structure the system) (Apologies in advance as I can't figure out how not to sound snarky here.) Isn't that called "the design? And is there any meaningful way in which, if "test-driven design" fails if you don't already have the design, it's worth anything at all?

Sure, you can call that structure the design, or the architecture, or whatever you like. Either way, it's a fair question. As a point of semantics: TDD generally stands for "test-driven development," not "test-driven design," though the article here does make the claim that TDD helps with design. To reduce my personal philosophy to a near tautology: if you don't design the system to be testable, it's not going to be…

I think you're spot on here - TDD is great as long as you're not too obstinate about it. It's a trade off, just like every interesting problem.

One point I'd like to draw out. If you don't have a clue how you want to build things, TDD isn't going to help.

This is exactly right. If you find yourself completely unable to articulate a test for something, you probably don't really know what it is you're trying to build. I think that's the greatest benefit to TDD: it forces you to stop typing and think.

Re: The Failures of "Intro to TDD"

#53

Post by couchand »

wpietri wrote: post #31
usea wrote: post #22

I have tried many times to do TDD. I find it extraordinarily hard to let tests drive the design, because I already see the design in my head before I start coding. All the details might not be filled in, and there are surely things I overlook from the high-up view, but for the most part I already envision the solution. It's difficult to ignore the solution that is staring my brain in the face and pretend to let it ha…

My big tip for someone at your stage: don't see the design . See a few designs . Sure, be going in some direction, but constantly be seeking alternatives to choose from. And always favor the simpler alternative to start. One thing that helps keep me doing that: it's only with trivial problems that you know everything important up front. Accept that your domain will surprise you. That your technology will surprise you…

And your users, they'll surely surprise you!

Re: The Failures of "Intro to TDD"

#54

Post by Chris_Newton »

couchand wrote: post #52
akeefer wrote: post #38

Earlier quoted context omitted.

Sure, you can call that structure the design, or the architecture, or whatever you like. Either way, it's a fair question. As a point of semantics: TDD generally stands for "test-driven development," not "test-driven design," though the article here does make the claim that TDD helps with design. To reduce my personal philosophy to a near tautology: if you don't design the system to be testable, it's not going to be…

I think you're spot on here - TDD is great as long as you're not too obstinate about it. It's a trade off, just like every interesting problem. One point I'd like to draw out. If you don't have a clue how you want to build things, TDD isn't going to help. This is exactly right. If you find yourself completely unable to articulate a test for something, you probably don't really know what it is you're trying to build.…

If you find yourself completely unable to articulate a test for something, you probably don't really know what it is you're trying to build.

I don’t buy this argument. How would you write tests to drive the development of a graphics demo, say rendering a Mandelbrot set? Or a tool to convert audio data from one format to another? Or any other kind of software where the output doesn’t consist of readily verifiable, discrete data points?

Re: The Failures of "Intro to TDD"

#55

Post by searls »

vinceguidry wrote: post #51
akeefer wrote: post #23

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. I personally have kind of moved away from TDD over the years, because of some of these reasons: namely, that if the tests match the structure of the code too closely, changes to the organization of that code are incredibly painful because…

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

Re: The Failures of "Intro to TDD"

#56

Post by julie1 »

TDD and agile have been an effort at breaking an old must have for code which was: ISO9001; the code should behave according to the plan, and if they don't conform, plan must be revised if the tests failed. The Plan Do Check Act Mantra. Now, they find themselves facing the consequences of not respecting the expectation of the customers and they whine because "it was not applied correctly, because no one cared".

So now, they reformalize exactly the so "rigid" ISO9001 they were trying to throw down.

What an irony.

Re: The Failures of "Intro to TDD"

#57

Post by couchand »

Chris_Newton wrote: post #54
couchand wrote: post #52

Earlier quoted context omitted.

I think you're spot on here - TDD is great as long as you're not too obstinate about it. It's a trade off, just like every interesting problem. One point I'd like to draw out. If you don't have a clue how you want to build things, TDD isn't going to help. This is exactly right. If you find yourself completely unable to articulate a test for something, you probably don't really know what it is you're trying to build.…

If you find yourself completely unable to articulate a test for something, you probably don't really know what it is you're trying to build. I don’t buy this argument. How would you write tests to drive the development of a graphics demo, say rendering a Mandelbrot set? Or a tool to convert audio data from one format to another? Or any other kind of software where the output doesn’t consist of readily verifiable, dis…

Are you asking about unit tests or acceptance tests?

The problems you describe are very high level, but we could design an acceptance testing scheme for them. For the Mandelbrot set it might involve comparison to a reference rendering, for the audio tool a reference recording. In both cases you'd allow a delta relevant to the application, and probably also benchmark for acceptable performance.

But my point was more aimed at unit testing. When you set out to write a function you should know something about that function before starting. If you know enough to write the function signature, you can first write a failing test. If you can write a bit of code in that function, you can write a bit expecting the behavior of that code.

Re: The Failures of "Intro to TDD"

#58

Post by bphogan »

couchand wrote: post #52
akeefer wrote: post #38

Earlier quoted context omitted.

Sure, you can call that structure the design, or the architecture, or whatever you like. Either way, it's a fair question. As a point of semantics: TDD generally stands for "test-driven development," not "test-driven design," though the article here does make the claim that TDD helps with design. To reduce my personal philosophy to a near tautology: if you don't design the system to be testable, it's not going to be…

I think you're spot on here - TDD is great as long as you're not too obstinate about it. It's a trade off, just like every interesting problem. One point I'd like to draw out. If you don't have a clue how you want to build things, TDD isn't going to help. This is exactly right. If you find yourself completely unable to articulate a test for something, you probably don't really know what it is you're trying to build.…

Exactly. This is the whole purpose behind the "spike" - make a branch, write a crap implementation of some code to help understand the problem, put it aside. Then go write the production version TDD style. Once you understand the problem, you can use TDD to create a good design to solve that problem.

Sounds crazy, but this is how I do everything I don't understand. And my second implementation is usually better than my first.

Re: The Failures of "Intro to TDD"

#59

Post by bphogan »

richardjordan wrote: post #26

The comments section today looks like a support group for beginners/intermediates who struggled with TDD and gave up, and so want to explain why it's all bunk. I get this. I am not a great programmer. I'm self taught like a lot of you. I had tremendous difficulty grokking TDD and for the longest time I'd start, give up, build without it. But, I'm here as a you-can-do-it-to. You might not think you want to but I'm so…

This is really right on the money. If it's too hard to test then you've already found something really valuable - a problem with your design that will cause you friction later on.

That itself might be worth a ton to you.

Re: The Failures of "Intro to TDD"

#60

Post by couchand »

bphogan wrote: post #58
couchand wrote: post #52

Earlier quoted context omitted.

I think you're spot on here - TDD is great as long as you're not too obstinate about it. It's a trade off, just like every interesting problem. One point I'd like to draw out. If you don't have a clue how you want to build things, TDD isn't going to help. This is exactly right. If you find yourself completely unable to articulate a test for something, you probably don't really know what it is you're trying to build.…

Exactly. This is the whole purpose behind the "spike" - make a branch, write a crap implementation of some code to help understand the problem, put it aside. Then go write the production version TDD style. Once you understand the problem, you can use TDD to create a good design to solve that problem. Sounds crazy, but this is how I do everything I don't understand. And my second implementation is usually better than…

Or, in the words of Fred Brooks, build one to throw away. I'm always amazed at how prescient he was.

Unfortunately I find all too often that spike project finds its way into production for one reason or another. Now I only spike in Befunge.

Post reply on HN