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

41–50 of 85 posts

Re: The Failures of "Intro to TDD"

#41

Post by mrisse »

searls wrote: post #18
mrisse wrote: post #6

Might one of the problems be that we place too much importance on the "symmetrical" unit test. In your example the child code is still covered when it is extracted from the parent. As a developer that often prefers tests at the functional level, the primary benefit of tests for me is to get faster feedback while I am developing.

The trouble with abandoning symmetrical unit tests is that: * The unit is no longer portable and can't be pulled from the context it was first used in (e.g. into a library or another app) without becoming untested. And adding characterization testing later is usually more expensive * A developer who needs to make a change to that unit needs to know where to "test drive" that change from, which requires that they know…

Unless I'm missing something, wouldn't the child dependency be enough to prevent the unit from being dropped into another library or app? That's a good point you bring up about knowing where to "test drive" the changes from, though usually on the apps I've worked on, they've been small enough that the relevant integration test could be found without much detective work.

I guess I haven't been involved in too many 2-3 year monolithic projects. Maybe that's when a stricter symmetrical unit test policy makes the most sense.

What other levels of tests do you end up running besides your unit tests? Do you have any integrated unit tests? Functional tests? End to end tests?

Re: The Failures of "Intro to TDD"

#42

Post by ChuckMcM »

I suspect if they had called it Architecture Driven Development (ADD) rather than Test Driven Development (TDD) it might contextualize better. Basically what the author explains is that you can design an architecture top down from simple requirements, deriving more complex requirements, and then providing an implementation strategy that lets you reason about whether or not you are "done."

But that 'test' word really puts people in the wrong frame of mind at the outset.

Re: The Failures of "Intro to TDD"

#43

Post by searls »

ChuckMcM wrote: post #42

I suspect if they had called it Architecture Driven Development (ADD) rather than Test Driven Development (TDD) it might contextualize better. Basically what the author explains is that you can design an architecture top down from simple requirements, deriving more complex requirements, and then providing an implementation strategy that lets you reason about whether or not you are "done." But that 'test' word really…

Yeah, the common implications of the word "test" have always been problematic. The BDD movement did a good job bringing that to light, but I didn't want to re-litigate that all in my post just to make a point about semantics. Totally agree, though.

Re: The Failures of "Intro to TDD"

#45

Post by ams6110 »

sethkojo wrote: post #29
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…

Maybe you're over thinking it? It sounds like you're already doing the right things. 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. The design part of TDD is just the expectations. So if you were to test an add function for example, you might write something like assertEqual(add(5,2), 7) assertEqual(add(-5,2)…

Incidentally for functions like that, if you have an environment that supports a tool like QuickCheck[1], it's a great thing to use. "The programmer provides a specification of the program, in the form of properties which functions should satisfy, and QuickCheck then tests that the properties hold in a large number of randomly generated cases."

1: http://www.cse.chalmers.se/~rjmh/QuickCheck/

Re: The Failures of "Intro to TDD"

#46

Post by GhotiFish »

searls wrote: post #44
GhotiFish wrote: post #40

I like the way he broke things up, but something bothers me about his technique. All his classes ended in "er". he's not writing object oriented software, he's writing imperative software with objects.

Yes I am.

fair enough. Do you think TDD and OOP are mutually exclusive practices?

Re: The Failures of "Intro to TDD"

#47

Post by searls »

GhotiFish wrote: post #46
searls wrote: post #44

Earlier quoted context omitted.

Yes I am.

fair enough. Do you think TDD and OOP are mutually exclusive practices?

TDD as I practice it does, but I think OOP as it's traditionally taught encourages developers to tangle mutable application state and behavior, which leads to all sorts of problems. The more I practice, the more I learn that life is better when I separate whatever holds the state from whatever has the behavior

Re: The Failures of "Intro to TDD"

#48

Post by Groxx »

richardjordan wrote: post #27

Shout out for Sandi Metz book POODR, and her Railsconf talk The Magic Tricks of Testing, if you're a rubyist (though the principles hold true for non-ruby OO programmers too). https://www.youtube.com/watch?v=URSWYvyc42M

+1 for POODR - very (very) well written, goes down multiple pathways reasonably (rather than "this is how you solve that" without any clue why you solve it that way), and gives some decent tools for any project. I only wish it were longer.

Re: The Failures of "Intro to TDD"

#49

Post by dboat »

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?

It's very common in software development to receive incomplete requirements. My world would be a very different place if I always receive feature complete design documents (and in same cases, any documents at all). Had I insisted on any kind of TDD, it would greatly increase my workload by reducing my ability to alter the design to accommodate new feature requests and changes while internal clients test the code.

I do gather some places do things differently though. Must be nice.

Re: The Failures of "Intro to TDD"

#50

Post by searls »

dboat wrote: post #49
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?

It's very common in software development to receive incomplete requirements. My world would be a very different place if I always receive feature complete design documents (and in same cases, any documents at all). Had I insisted on any kind of TDD, it would greatly increase my workload by reducing my ability to alter the design to accommodate new feature requests and changes while internal clients test the code. I d…

I think I'd have to offer that my experience differs. TDD is not at all big-design-up-front, even with this reductive exercise. In fact, most features start very minimally and the tree of dependencies grows over time, just like any system becomes incrementally more complex. TDD is just one tool (of many) to help manage that complexity. Both by offering some regression value (at least of the logical bits) and also by encouraging small, bite-sized units that are easy to make sense of (and therefore change or replace)
Post reply on HN