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

31–40 of 85 posts

Re: The Failures of "Intro to TDD"

#31

Post by wpietri »

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. That your own code will surprise you if you pay close attention to what's working well and what could be better.

Re: The Failures of "Intro to TDD"

#32

Post by Nimi »

I wonder about these workshops (even asked Uncle Bob Martin about them in a recent thread). I can't shake the feeling they are the exact opposite of agility (obviously, he is better qualified than me to judge that). Their limited time schedules, which is essentially a bound over the amount of contact between the client and the supplier, seems analogous to the infamous "requirements document". Also, there doesn't appear to be a "shippable" product at the end - the developers apparently don't end up practicing TDD.

I used to be an instructor for a living, and I kind-of equated lectures to waterfall and exercises to XP. There is even a semantically analogous term in teaching research, problem-based learning (each word corresponds to the respective word in test-driven development - cool, right?). Is there anyone else who sees these analogues, or am I completely crazy here?

Re: The Failures of "Intro to TDD"

#33

Post by searls »

radicalbyte wrote: post #10

Excellent post, I've had exactly the same experience and come to exactly the same conclusion. I still follow the old Code Complete method: think about the problem, sketch it out, then finally implement with unit tests. The results are the same, and it's a lot less painful than greenhorn-TDD.

Time at a white board breaking down a problem is rarely wasted :)

Re: The Failures of "Intro to TDD"

#35

Post by ArbitraryLimits »

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…

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

Re: The Failures of "Intro to TDD"

#36

Post by zwieback »

Sure, but if the end result is "lots of little objects/methods/functions" maybe there's a simpler way of getting there, e.g. prescriptive design rules. After all, that's what every design method, including stuff from the waterfall era attempted.

I'd like TDD to be more than just another way to relearn those old rules, especially if we arrive at the same conclusions on a circuitous path. Perhaps the old design rules, object patterns, etc. have to each be integrated with a testing strategy, e.g. if you're using an observer you have to test it like this and if you refactor it like that you change your tests like so.

The general rules are easy to understand and your post makes perfect sense but once you formulate your new design approach you'll have to find a way to teach it precisely enough to avoid whatever antipattern is certain to evolve among the half-educated user community, which usually includes myself and about 95% of everyone else.

Re: The Failures of "Intro to TDD"

#37

Post by Silhouette »

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…

I want to see the light.

Some of us would argue that you already have.

You're already doing several reasonable things that tend to improve results: using unit tests, being aware of dependencies, being aware of where your state is held. There is ample credible evidence to suggest that both using automated testing processes and controlling the complexity of your code are good things.

There is little if any robust evidence that adopting TDD would necessarily improve your performance from the respectable position you're already in. So do the truly agile thing, and follow a process that works for you on your projects. You can and should always be looking for ways to improve that process as you gain experience. But never feel compelled to adopt a practice just because some textbook or blog post or high-profile consultant advocated it, if you've tried it and your own experience is that it is counterproductive for you at that time.

Re: The Failures of "Intro to TDD"

#38

Post by akeefer »

ArbitraryLimits wrote: post #35
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…

> 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 testable. TDD, to me, is really about designing for testability. Doing that, however, isn't easy: knowing what's testable and what's not requires a lot of practical experience which tends to be gained by writing a bunch of tests for things. In addition, the longer you wait to validate how testable your design actually is, the more likely it is that you got things wrong and will find it very painful to fix them. So when I talk about TDD myself, I'm really talking about "design for testability and validate testability early and often." If you don't have a clue how you want to build things, TDD isn't going to help.

If you take TDD to mean strictly test-first development . . . well, I only find that useful when I'm fixing bugs, where step 1 is always to write a regression test (if possible). Otherwise it just makes me miserable.

The other thing worth pointing out is that design for testability isn't always 100% aligned with other design concerns like performance, readability, or flexibility: you often have to make a tradeoff, and testability isn't always the right answer. I personally get really irked by the arguments some people make that "TDD always leads to good design; if you did TDD and the result isn't good, you're doing TDD wrong." Sure, plenty of people have no clue what they're doing and make a mess of things in the name of testability. (To be clear, I don't think the author here makes the mistake of begging the question: I liked the article because I think it honestly points out many of the types of mistakes people make and provides a reasonable approach to avoiding them.)

Re: The Failures of "Intro to TDD"

#39

Post by twic »

ArbitraryLimits wrote: post #35
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…

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

"Test-driven design", as it is commonly understood, does seem to be a mythical beast. I've hunted it with both logic and experience and come up empty-handed.

That said, i do still find that while test-driven development doesn't itself create good design, it is a useful tool to help me create good design. I have a bite-size piece of functionality to write; i think about what the class should look like; i write tests to describe the class; i write the class. The key thing is that the tests are a description of the class. The act of writing down a description of something has an amazing power to force the mind to really understand it; to see what's missing, what's contradictory, what's unnecessary, and what's really important. I experience this when i write presentations, when i write documentation, and when i write tests. The tests don't do the thinking for me, but they are a very useful tool for my thinking.

Post reply on HN