Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TDD did not live up to expectations

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

121–130 of 450 posts

Re: TDD did not live up to expectations

#121

Post by reitanqild »

hinkley wrote: post #103
atonse wrote: post #8

In the earlier days of the ruby community, I feel TDD was seen as gospel. And if you dared say that TDD wasn't the way (which I always felt), you'd feel like you were ostracized (update: just rewording to say, you'd worry that it would hurt you in a job search, not that people were mean to you). So I never spoke up. I feel like I was in the TDD-bad closet. I absolutely think _tests_ are useful, but have never found a…

I was quite comfortable with refactoring for a very long time before I started doing tests, and I think that colors my approach to the problem space. I write code until it misbehaves the first time, and then I start writing tests, comfortable in the knowledge that in another half hour this code will be unit testable and look better than what everyone else is turning in, and that I'll spend 20 minutes at the end clean…

What language?

Re: TDD did not live up to expectations

#122

Post by s73ver »

dtech wrote: post #58
colomon wrote: post #30

It always startles me when people assume that one programming technique either works for every type of programming or doesn't work for every type. Working on Perl 6 compilers, an extensive set of tests was our best friend. It was (probably still is, I haven't had time to help the last few years) utterly routine to write tests first and then write the code to make them work. It was a perfect way of working on it. On t…

I think TDD works great if you have a very clearly designed input or interface. A programming language falls under this category: here's a piece of code, make sure it compiles and returns the correct output is a perfect test. And one which you can defined beforehand and is achievable to write as a test. However, programmers are often not in such a luxurious position. Business requirements are unclear, it is unclear w…

If the requirements are unclear, then why are you writing code? Why aren't you having conversations with people to clear up those requirements?

Re: TDD did not live up to expectations

#123

Post by weberc2 »

The main benefit for TDD in my mind is that it mostly makes it painful to write spaghetti code. When I'm reviewing something that looks too integrated, I just ask for a unit test for that particular piece of functionality, and the author is effectively forced to go back and refactor. After going through this a few times, they learn to think about their design before they write code. Of course, many dynamic languages defeat this by offering hacks like Python's mock.patch which let you nominally test spaghetti code...

Re: TDD did not live up to expectations

#125

Post by taeric »

amirouche wrote: post #106
taeric wrote: post #64

Earlier quoted context omitted.

No. TDD failed for engineering reasons in addition to economic ones. The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software. This is true in bridge building as much as it is in anything else. Until you fully know the domain of what you are building, you cannot possibly know all of the things you need to test for. To that end, if TDD were focused aroun…

I don't do the TDD like a waterfall. I don't do upfront all the tests, there is a discussion between the code (what express the business need) and the tests that "wraps" it inside a safe zone (what ensures that the behavior is the one intended). As such, as the idea grow, both the code and the test grow at the same time. Look at [0] to have an idea of how the tests extend the safe zone along the code. Also, I much pr…

Rereading my post, I see where it sounds more strawman of the "entire wall of tests." I did not mean it to be the final test suite is written first.

Instead, I intended that to be the wall that you will be passing in a given cycle. So, for a small development cycle, you add in some new tests that will be this cycle's "wall" of failing tests that you flip to passing.

And don't take this to be an indication that I think integration tests are somehow superior. They all have advantages and there is a massive cost benefit tradeoff that has to be considered at all times.

It is easy to talk in strawmen. Such that I can confidently say if you have a set of tests that always fails together, that should just be a single test. However, I do not feel that statements like that are informative, precisely because it is a judgement call masquerading as a rule.

Re: TDD did not live up to expectations

#126

Post by andybak »

s73ver wrote: post #82
taeric wrote: post #64

Earlier quoted context omitted.

No. TDD failed for engineering reasons in addition to economic ones. The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software. This is true in bridge building as much as it is in anything else. Until you fully know the domain of what you are building, you cannot possibly know all of the things you need to test for. To that end, if TDD were focused aroun…

I've never heard TDD being that you write all of your tests up front, before you've written any code. I've always heard it as: When you're writing a class/unit, you write a few tests for what that unit is going to do. You then make those tests pass. You add some more tests, make those pass, and so on and so on.

> I've never heard TDD being that you write all of your tests up front, before you've written any code.

That's the only way I've ever heard it described. I thought that's why it's called "Test Driven"

Re: TDD did not live up to expectations

#127

Post by AstralStorm »

eropple wrote: post #33
tonyedgecombe wrote: post #6

Earlier quoted context omitted.

It's interesting where this leads you though, deep into dependency injection, inversion of control containers and patterns like MVVM. I'm not saying these things are bad but they do have a cost.

It doesn't necessarily lead you there at all. "Dependency injection" is a fancy phrase for "pass stuff a function needs into the function", only it does so by adding state to objects where that state probably shouldn't exist. You don't have to faff around with IoC or MVVM to properly isolate dependencies; indeed, it's the core idea behind something like Gary Bernhardt's "Functional Core, Imperative Shell" (which, if…

Sometimes state is an actual desirable thing and strategy can be a dependency.

Heck, higher order functions (functions taking functions as argument) are dependency injection personified.

Re: TDD did not live up to expectations

#128

Post by nostrademons »

taeric wrote: post #96
s73ver wrote: post #82

Earlier quoted context omitted.

I've never heard TDD being that you write all of your tests up front, before you've written any code. I've always heard it as: When you're writing a class/unit, you write a few tests for what that unit is going to do. You then make those tests pass. You add some more tests, make those pass, and so on and so on.

You are still writing the tests first, with no real learning from them other than "they are now passing." It is thought this is like engineering. You design an experiment and then pass it. However, that is not how experiments work. You design an experiment, and then you collect results from it. These may be enough to indicate that you are doing something right/wrong. They are intended, though, to be directional learn…

You're often learning the optimal API as well. I've had several experiences where I write a library, write some tests for it, and then realize that the library's API is inconvenient in ways X, Y, and Z, and that I could have a much simpler API by moving a few tokens around. When I write the tests first, I tend to get a fairly usable API the first time around, because I'm designing it in response to real client code.

(This all depends on having a clear enough idea of what the library needs to do that I can write realistic test code...I've also had the experience where I write the tests, write the library, and then find that the real system has a "hidden" requirement that isn't captured by the tests and requires a very different way of interacting with the library.)

Re: TDD did not live up to expectations

#129

Post by jrs235 »

nostrademons wrote: post #37

TDD failed for economic reasons, not engineering ones. If you look at who were the early TDD proponents, virtually all of them were consultants who were called in to fix failing enterprise projects. When you're in this situation, the requirements are known. You have a single client, so you can largely do what the contract says you'll deliver and expect to get paid, and the previous failing team has already unearthed…

P.S. If you click the [1] link above you will be taken to an imgur image making fun of Hacker News.

To read the real article you'll need to copy and paste the URL address in your browser. Looks like the site is reading the referrer and forwarding to mean things...

Re: TDD did not live up to expectations

#130

Post by tonyedgecombe »

eropple wrote: post #33
tonyedgecombe wrote: post #6

Earlier quoted context omitted.

It's interesting where this leads you though, deep into dependency injection, inversion of control containers and patterns like MVVM. I'm not saying these things are bad but they do have a cost.

It doesn't necessarily lead you there at all. "Dependency injection" is a fancy phrase for "pass stuff a function needs into the function", only it does so by adding state to objects where that state probably shouldn't exist. You don't have to faff around with IoC or MVVM to properly isolate dependencies; indeed, it's the core idea behind something like Gary Bernhardt's "Functional Core, Imperative Shell" (which, if…

That's interesting although after a brief look it just looks like he is splitting the code into two parts, one part he tests and the other part he doesn't. I don't really disagree with this, my UI code has very few tests.

"which, if you're not understanding this instinctively, makes me fear for your code"

Thanks for the insult.

Post reply on HN