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

Re: The Failures of “Intro to TDD”

#41

Post by marcosdumay »

rubiquity wrote: post #31

Any discussion about TDD requires a link to Rich Hickey's Hammock-Driven Development talk: https://www.youtube.com/watch?v=f84n5oFoZBct The important thing that TDD or any other software design methodology is trying to accomplish is getting you to think about the design of your programs. However you want to accomplish that is fine as long as you take some time before you open your editor and think before you start wr…

Funny thing.

I think that thinking about the design of my programs is easier once I have some amount of working code.

There's a minimum organization needed for starting to code, but every time I decide to think any further when solving a problem I'm not used to (optimally that would be always), I end up optimizing for the wrong problems and have to restructure it all later anyway.

Re: The Failures of “Intro to TDD”

#42

Post by marcosdumay »

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.

On Java and Java-like languages, objects are also a good option for providing namespaces.

Re: The Failures of “Intro to TDD”

#43

Post by BurningFrog »

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.

Re: The Failures of “Intro to TDD”

#45

Post by rubiquity »

marcosdumay wrote: post #41
rubiquity wrote: post #31

Any discussion about TDD requires a link to Rich Hickey's Hammock-Driven Development talk: https://www.youtube.com/watch?v=f84n5oFoZBct The important thing that TDD or any other software design methodology is trying to accomplish is getting you to think about the design of your programs. However you want to accomplish that is fine as long as you take some time before you open your editor and think before you start wr…

Funny thing. I think that thinking about the design of my programs is easier once I have some amount of working code. There's a minimum organization needed for starting to code, but every time I decide to think any further when solving a problem I'm not used to (optimally that would be always), I end up optimizing for the wrong problems and have to restructure it all later anyway.

That's a great point! I've certainly had times where spiking a bit of code and then thinking was valuable. There are no maxims in program design so I'm glad you took the time and thought about that :)

Re: The Failures of “Intro to TDD”

#46

Post by _asummers »

colin_jack wrote: post #28
_asummers wrote: post #26

Earlier quoted context omitted.

It definitely is. The problem, I think, is that people forget these fundamental concepts when they're shoved into a giant legacy code base that clearly didn't follow that process. They seem to get overwhelmed by the spaghetti and forget their entire undergrad curriculum. As a side note, I find it helpful to think of what the high level business objects will be at the beginning, but build a bunch of utility functions…

> As a side note, I find it helpful to think of what the high level business objects will be at the beginning, but build a bunch of utility functions from the bottom up Yeah I think this is a reasonable approach, especially as if you do end up completing this, and get to a design you are happy with, it will probably be very different (and hopefully infinitely superior) to your original high level design. You've proba…

I had not heard of this before. I will have to investigate. I found an InfoQ[0] talk on it that I will watch after work.

[0] http://www.infoq.com/interviews/mikado-method-restrurcture-s...

Re: The Failures of “Intro to TDD”

#47

Post by ta0967 »

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.

you're not alone. http://steve-yegge.blogspot.cz/2006/03/execution-in-kingdom-...

Re: The Failures of “Intro to TDD”

#48

Post by s73v3r »

Retra wrote: post #34
moron4hire wrote: post #27

Earlier quoted context omitted.

The problem is students don't listen. The majority of people see course work as a necessary evil, to be gotten through, and forgotten after passing the final exam.

"Students don't listen" is never the problem. "Teachers don't teach" is more like it.

No, students not listening can often be the problem. You can be the greatest teacher in the world, and still there will be a few students who don't want to listen.

Re: The Failures of “Intro to TDD”

#49

Post by amadeusw »

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…

Sadly, usually tests are written after the fact to satisfy a code coverage requirement. Perhaps that's why people hate testing. That's why I did!

At my startup we're indirectly tackling difficulties associated with unit testing. Our tool Alive [0] is an interactive programming extension to Visual Studio that made me really enjoy writing tests first and then implementing the features - when with each keystroke I get to see what the code does.

[0] http://comealive.io/

Re: The Failures of “Intro to TDD”

#50

Post by Retra »

s73v3r wrote: post #48
Retra wrote: post #34

Earlier quoted context omitted.

"Students don't listen" is never the problem. "Teachers don't teach" is more like it.

No, students not listening can often be the problem. You can be the greatest teacher in the world, and still there will be a few students who don't want to listen.

But you can't be the greatest teacher in the world.
Post reply on HN