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–58 of 58 posts

Re: The Failures of “Intro to TDD”

#51

Post by s73v3r »

Aleman360 wrote: post #37
lowbloodsugar wrote: post #36

Earlier quoted context omitted.

Conversely, objects should have a single responsibility [1] and so functions that are unrelated should go on different objects. An InvoiceFetcher is definitely unrelated to a PaymentApplier, unless one takes the argument that "Its about money", in which case you have to argue for a single giant class. [1] http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

I dunno, I always thought objects were about managing state. If an object does nothing except provide a method, why can't the method just be a free function instead? InvoiceFetcher.FetchInvoice() PaymentApplier.ApplyPayment() just seems terrible.

In several languages coughJavacough you can't really have free functions.

Re: The Failures of “Intro to TDD”

#52

Post by maxxxxx »

bksta wrote: post #15

Methodologies aren't a substitute for creativity or intelligence. At best they can give a person with good judgement a different angle to look at their problems with. At worst they are thought-stopping slogans that turn a gullible novice into a crippled novice.

Yup. TDD, object orientation, agile, functional programming and whatever else are all good ideas. In some cases they work, in others not.

But it seems people have a tendency to make them into ideologies/religions that when applied correctly will solve everything. I guess it's a way to exercise power over people. No individual thought allowed.

Re: The Failures of “Intro to TDD”

#53

Post by vinceguidry »

BurningFrog wrote: post #43
xorcist wrote: post #18

This article sums up the problems I've seen with TDD first hand. I've never seen a team end up with a better design than they would have using the old maxim: "Think hard. Then code.". I'm sure they exist, but adopting TDD does not automatically lead to better design, that much seems certain. Another issue with TDD is that it is incredibly difficult to reason about. In many groups, there are at least one developer sol…

TDD is hard. You need to work up a skill, and you probably need someone experienced to guide you at first.

Unfortunately, it stays hard no matter how much deliberate practice you sink into it. I didn't understand what DHH was saying about design damage inflicted by testing until I started seriously confronting questions like "which parts of this API should I mock and which parts should I just use integration tests for?"

Eventually you spend more time thinking about testing than you do actually getting shit done. You have to because otherwise you find yourself rewriting tests every time you refactor. You rationalize this time under the guise of "it's making me think more clearly about my design." Once it starts wearing thin disillusionment takes root. The first step towards my own enlightenment was when I realized that I needed tests to help me ensure that my test framework was working. What's testing those tests? Tests are code, and code needs to be tested. Where does it end?

I wrote my own toy test framework as an exercise. I was trying to * really * wrap my head around meta-programming, so I meta-programmed my test suite to test the heavily meta-programmed data classes. It solidified into a grotesque mush and I scrapped the whole thing. Now I'm solving the original problem with boring old Rails and sanity has been restored.

Now when I start a project I do it knowing that my code is going to suck and I'm going to refactor it over time. The truth is, when there's no tests I only have to refactor one code base and not two. I don't need to learn two frameworks. I don't need to understand two domains. The amount of time I've spent maintaining code has sharply diminished after I stopped being so religious about testing. If I don't know what it's doing, the REPL is my best friend. Backtraces rule.

If your code is Serious Business, like, say, SQLite which is used everywhere, a robust test suite is a very nice tool to have and maintain. For everyone else, it's another step on the road to mastery.

Also if you're using a dangerously unsafe language like C, tests can alert you to brewing problems. If you're using a safe language solving not-so-hard problems, a test framework is just adding complexity to paper over your lack of experience.

Re: The Failures of “Intro to TDD”

#54

Post by nartz »

A better description of the audience you were teaching to would be super helpful, because how you teach needs to be tailored to the crowd. Making a generic statement like you will never start with TDD anymore doesn't make sense.

To be frank, when you said the audience was 'typical enterprise java developers', it seems that you are already describing a group of developers who are sort of 'stuck' in their ways, who maybe haven't heard of other things like TDD and WOULD necessarily miss the point of a lot of it.

Just sayin - it could be helpful to avoid broad statements like "never start with TDD" that may be more audience specific.

Re: The Failures of “Intro to TDD”

#55

Post by nartz »

moron4hire wrote: post #29

His steps 4 through 6 seem to completely violate the principle of YAGNI. It also seems way too much like big-bang releasing. You write all this code for a very long time and don't have any way to objectively say the design is correct (in that it actually performs the business case from start to finish) until the very end. I've designed systems in this way before (strangely, they always seem to be some sort of documen…

I like to always start with YAGNI, and then try some of these exercises after I already have something that kind of works - its much easier imho to refactor something that is simple and gets the job done, i.e. add-to versus something that is wrought with way too many abstractions and such.

Re: The Failures of “Intro to TDD”

#56

Post by mkozlows »

moron4hire wrote: post #29

His steps 4 through 6 seem to completely violate the principle of YAGNI. It also seems way too much like big-bang releasing. You write all this code for a very long time and don't have any way to objectively say the design is correct (in that it actually performs the business case from start to finish) until the very end. I've designed systems in this way before (strangely, they always seem to be some sort of documen…

That's why I thought this article was honestly the case against TDD. Because the upfront "this method has major problems" stuff rang very true, but then the "this is the correct way to do it" made me wince hard, with its Java-esque upfront complexity.

Re: The Failures of “Intro to TDD”

#57

Post by mjevans »

IanCal wrote: post #9

I've found the way TDD has been "sold" to me as quite odd, and probably what's turned me off from it the most (cure of all ills). At the same time, I find the religious pushes for and against to be both understandable and bizarre. I've been thinking about this for some time now, but don't think I've ever really written it down. As a very general statement, I'd say any developer should try their hardest covers the bas…

I agree this seems reasonable and sane.

However there are types of programs which aren't well covered by a test (demo) or set there of.

Sometimes the program is being written to learn a value which is unknown, or for which a simplified example having success insufficiently tests the validity or scalability of the software.

Tests in those cases may work at a unit level, but still provide insufficient insight in to the soundness of the overall results.

Re: The Failures of “Intro to TDD”

#58

Post by lowbloodsugar »

Aleman360 wrote: post #37
lowbloodsugar wrote: post #36

Earlier quoted context omitted.

Conversely, objects should have a single responsibility [1] and so functions that are unrelated should go on different objects. An InvoiceFetcher is definitely unrelated to a PaymentApplier, unless one takes the argument that "Its about money", in which case you have to argue for a single giant class. [1] http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign

I dunno, I always thought objects were about managing state. If an object does nothing except provide a method, why can't the method just be a free function instead? InvoiceFetcher.FetchInvoice() PaymentApplier.ApplyPayment() just seems terrible.

Because Java. At least I can use an interface to define the function's specification, and then use that in mocks. On the one hand, it seems very different to what I learned about OOP twenty odd years ago, but on the other, it makes for extremely well designed and easy to understand code.
Post reply on HN