The Failures of “Intro to TDD” • Hacker News Board

Re: The Failures of “Intro to TDD”

#31

Post by rubiquity » Thu, Jun 18, 2015, 2:00 PM UTC

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 writing code. It doesn't necessarily have to be TDD.

Re: The Failures of “Intro to TDD”

#32

Post by jasonwocky » Thu, Jun 18, 2015, 2:06 PM UTC

[deleted] wrote: post #21

eitally wrote: post #16

Earlier quoted context omitted.

If only management understood this. Actually, I think good managers do understand this, and do it anyway, because if you take the general case and look at it from above, methodologies do improve upon chaos.

[deleted]

> Everything I've seen seems so "In my experience..." as opposed to a formal proof.

The scientific method is ill-equipped to formally prove a generalized theory of software development. There are too many significant variables at play; too many equations to solve. We are left with little but "In my experience..." to guide us (as well as local experimentation, where science can actually be of some help).

Re: The Failures of “Intro to TDD”

#33

Post by Aleman360 » Thu, Jun 18, 2015, 2:51 PM UTC

The article ends with a diagram showing a bunch of classes whose names end with "er". In my experience, that's usually a strong indicator of confusing design. Objects that have a single method and no real state should just be functions.

Re: The Failures of “Intro to TDD”

#34

Post by Retra » Thu, Jun 18, 2015, 3:25 PM UTC

moron4hire wrote: post #27

dragonwriter wrote: post #23

Earlier quoted context omitted.

Is "top down" vs. "bottom up" programming/design really not a set of terms and concepts that is still taught in nearly every introductory programming course such that people mentoring "new developers" need to introduce the concepts and invent new terminology for them?

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.

Re: The Failures of “Intro to TDD”

#35

Post by Retra » Thu, Jun 18, 2015, 3:30 PM UTC

mjbellantoni wrote: post #19

ThrustVectoring wrote: post #4

The tl;dr of this article - some programmers _really_ need to get exposed to a Systems Engineering course.

Here here to this. I never continue to be surprised by the number of people who don't realize that engineering is the practice of breaking big and confusing things into small things you understand.

It's "hear, hear."

Re: The Failures of “Intro to TDD”

#36

Post by lowbloodsugar » Thu, Jun 18, 2015, 3:30 PM UTC

Aleman360 wrote: post #33

The article ends with a diagram showing a bunch of classes whose names end with "er". In my experience, that's usually a strong indicator of confusing design. Objects that have a single method and no real state should just be functions.

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

Re: The Failures of “Intro to TDD”

#37

Post by Aleman360 » Thu, Jun 18, 2015, 3:31 PM UTC

lowbloodsugar wrote: post #36

Aleman360 wrote: post #33

The article ends with a diagram showing a bunch of classes whose names end with "er". In my experience, that's usually a strong indicator of confusing design. Objects that have a single method and no real state should just be functions.

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.

Re: The Failures of “Intro to TDD”

#38

Post by lowbloodsugar » Thu, Jun 18, 2015, 3:33 PM UTC

I've been doing TDD for nearly 10 years and this article describes my experience in a way I have not been able to distinguish myself. Thank you.

Re: The Failures of “Intro to TDD”

#39

Post by mpdehaan2 » Thu, Jun 18, 2015, 3:37 PM UTC

Here's a recent post I wrote about reasons for and approaches towards TDD. Generally, I love it. I find an API evolves though as you build it, so for me, it's a bit more about "tests at the same time" and "tests as the primary and first way of exercising the code". Also, that tests do better when they test use cases at a higher level, and that unit tests (I do agree with the article in some ways here) are often written at a level which penalizes refactoring, when they could be instead automated tests at a higher level.

http://michaeldehaan.net/post/120522567217/the-case-for-test...

Re: The Failures of “Intro to TDD”

#40

Post by mcguire » Thu, Jun 18, 2015, 3:54 PM UTC

dragonwriter wrote: post #23

anomie wrote: post #22

I've found the authors proposed approach at the end of the article to be a very useful one, even if you're not using TDD. A very regular piece of advice I give to new developers is "breadth-first not depth-first" - i.e. write a whole function at a consistent level of abstraction before you dive into writing the other classes etc. you need to support those few lines of high level code. I find that most new developers…

Is "top down" vs. "bottom up" programming/design really not a set of terms and concepts that is still taught in nearly every introductory programming course such that people mentoring "new developers" need to introduce the concepts and invent new terminology for them?

The "depth-first" approach (I've seen it as well) is a mistake that is largely orthogonal to a top-down/bottom-up style. It looks top-down, but immediately goes off into the weeds and can easily be recognized by statements of the form, "I need an X, so I'm building a Y." As in, "I need a reporting application, so I'm building a logging module", or the '90s Japanese 5th generation computing project, "We need intelligent, communicating systems, so we'll build a Prolog machine."