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

111–120 of 450 posts

Re: TDD did not live up to expectations

#111

Post by lgunsch »

eropple wrote: post #27
_puk wrote: post #12

Earlier quoted context omitted.

"I use it on occasion as a good sanity check to make sure I didn't break anything too obvious" That sounds more like unit tests than TDD. With TDD you should already know that you didn't break anything.. If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input; it is not however going to determine if you did that in the best possible way.

This is a good and cool post. TDD is less susceptible to "sucky code" for two reasons: 1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD. 2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code. Writing tests after you've written code strongly encourages you to write implementation te…

Regarding your second point, it is not only very difficult, but also not even how TDD was designed to work by its original creators at all. It is specifically not written by other people.

TDD, as outlined by the one who created the technique, as well as other big proponents such as Robert Martin, is done in tight 2 or 3 minute loops. As Kent Beck says, if you can't write your test in 5 minutes, you're doing too much.

Re: TDD did not live up to expectations

#112

Post by mparr4 »

buckbova wrote: post #54

Seems a little arrogant to say most developers don't know how to refactor or do it poorly. Maybe it's true. I really can't say one way or the other because what I see is most devs believe they don't have time to refactor.

> most devs believe they don't have time to refactor

tough to do something well if you don't spend time doing it

Re: TDD did not live up to expectations

#113

Post by spdionis »

buckbova wrote: post #54

Seems a little arrogant to say most developers don't know how to refactor or do it poorly. Maybe it's true. I really can't say one way or the other because what I see is most devs believe they don't have time to refactor.

If most devs don't have time to refactor, then most devs have not had much experience doing refactoring, thus most devs are bad at refactoring.

Sounds reasonable.

Re: TDD did not live up to expectations

#114

Post by smokeyj »

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 feel this way about code coverage (need that 100% badge).

If I took on a project with low quality and had a limited budget to ensure QA - I'd prioritize E2E testing over unit testing.

Re: TDD did not live up to expectations

#115

Post by thaumasiotes »

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…

> They do a LOT of transcription instead of copy and paste

Transcription makes you think about what you're typing in and avoids the whole class of errors that arise from copy-and-paste. Transcribing code rather than pasting it is not a red flag.

Re: TDD did not live up to expectations

#116

Post by hinkley »

nostrademons wrote: post #81
hinkley wrote: post #65

Earlier quoted context omitted.

I have a colleague who is not a household name but still fairly widely known in the software process space and he has insisted to me multiple times, for more than ten years now, that this is a west coast thing. Other parts of the US are much less allergic to discipline in development.

I'd agree with this characterization. I started my career in Boston - actually, one of the first companies I interned at did high-assurance systems for avionics, financials, and medical devices. However, look at the size of the West Coast tech industry vs. the size of tech firms in New England or the Midwest. That's what I mean by an economic argument. I got paid 5x more at Google than I did in Boston, and I was empl…

Unless the causal relationship is the other direction.

That is, everyone always assumes in our industry that the chaos allows this volume of people to be employed. But usually large number of people leads to chaos all by itself. Maybe we have it backward.

I know I've worked on a lot of projects that got version one out quick and could never get version 3 out the door. It gets old after a while. Why do I want to spend a few years of my life working on something nobody will remember? No thanks.

Re: TDD did not live up to expectations

#117

Post by goldenkey »

Sir_Substance wrote: post #100
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.

>I've never heard TDD being that you write all of your tests up front, before you've written any code. That's interesting, because as a non-TDD practitioner who occasionally gets it evangelized to me, that's certainly how I was told to go about it by multiple people. Possibly TDD has a marketing problem?

TDD doesn't have a marketing problem -- all these sponsored wigs evangelized it for the last 20 years, there's at least a dozen at every conference, many getting paid thousands to give their gritty speeches.

TDD as these maggots explained it is: write your tests first, write your code, make sure the tests pass, rinse, repeat.

Re: TDD did not live up to expectations

#118

Post by eropple »

StevePerkins wrote: post #34

Any programming language suitable for business application development is going to have static analysis tools that can reveal your percentage of test coverage. As long as 95% (or whatever) of your logical branches are covered by tests, I don't really care whether you wrote the tests beforehand or after the fact. However, TDD being hard is not a justification for not writing the test coverage at some point in the dev…

> As long as 95% (or whatever) of your logical branches are covered by tests, I don't really care whether you wrote the tests beforehand or after the fact.

Do you care that those tests reflect the business goal or just the implementation? 'Cause TDD is way, way more likely to do the former than test-last development.

Re: TDD did not live up to expectations

#119

Post by sb8244 »

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.

You are correct.

Not only this, but it's a blatant violation of TDD. TDD is having a single test go red->green, not a suite.

Re: TDD did not live up to expectations

#120

Post by sb8244 »

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 can throw away the test if you don't find value in it. This can be very useful for fleshing out an idea.
Post reply on HN