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

41–50 of 450 posts

Re: TDD did not live up to expectations

#41

Post by [deleted] »

falcolas wrote: post #32
_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.

> If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input Well, if you suck at writing code, what guarantees do you have that the tests (which are also code you write) are even correct?

[deleted]

Re: TDD did not live up to expectations

#42

Post by felipeccastro »

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…

Agreed, but I would add there are specific scenarios where doing the test first really helps - when you're building a routine complex enough that you can't think upfront how you'll do it, like a complex calculation for example. In that case, at least thinking about the tests first and making one by one pass helps you breaking down the problem into smaller, easier parts.

Re: TDD did not live up to expectations

#43

Post by lazyasciiart »

hyperpallium wrote: post #18
thinkingkong wrote: post #11

Earlier quoted context omitted.

Except in order to have a checklist you have to have your design and implementation up front which is out of reach for most developers. If were testing high level results in multiple cases thats cool. But a lot of the time youre going to try different approaches that may modify or involve changing your output.

TDD is waterfall

Not really. You can definitely practice TDD in two week sprints.

Re: TDD did not live up to expectations

#44

Post by Klathmon »

dcherman wrote: post #31

I've also never found TDD to really be very beneficial except for all but the most trivial utility libraries. Most of the time, I have an idea of where I want to go, but not necessarily exactly what my interface will look like. Writing tests beforehand seems to never work our since nearly always, then will be some requirement or change that I decide to make that'd necessitate re-writing the test anyway, so why write…

That's exactly how I've always done it, and it works beautifully for me.

Put "test stubs" out there that define what I'm testing in "human" terms, leave the stub either skipped or failing.

I've also found that if I wait a day or 2 after writing the implementation to write the tests, they catch much more.

If you write the code to match the tests, or you write the tests right after the code the chance that both the test and the code are wrong is much higher in my experience than if you wait a bit and come back to write the tests with fresh eyes.

Re: TDD did not live up to expectations

#45

Post by brango »

pcarolan wrote: post #35

Defining the interface before you write the code is the major advantage of test-driven development and what it added to that way of thinking was very valuable especially to novices. It also makes your code more modular and reusable. Writing code as if other people were going to use it is something we don't talk about enough.

I found it just flew in the face of iteration. I get something simple working, then iterate a few times, adding complexity. If you have to iterate your tests as well, you're just walking in treacle.

Either that or you end up with a load of stuff in your interface that you thought you'd need, but when you actually got to it you either didn't, or it wasn't important to implement at the outset.

Re: TDD did not live up to expectations

#46

Post by comstock »

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…

It's interesting to me that programming is becoming a fundamental part of many (maybe most) things humans do. And yet we treat it as if there was one single correct way of programming and all other ways are wrong.

I feel like it's much more akin to human language. Though the language primatives might be the same, it's used differently in different contexts are appropriate.

In formal, legal speech, you might want to be explicit.

In informal, everyday speech, not so much.

Similar analogs exist in programming. 10 time script to reformat data for one time use, careful documentation, tests etc. not really required.

Aircraft flight control system, very different...

But then why is it that so many programmers seem to focus on "the one true way" (TDD, agile etc). Beats me.

Re: TDD did not live up to expectations

#48

Post by alexandercrohde »

Tl, dr: When we treat unit tests as an ends in itself, this leads to writing clunky tests for clunky code. If an engineer doesn't understand modular, reusable code then that engineer can't won't be able to write code that can tested easily. Thus understanding design is a prerequisite to effective TDD.

Re: TDD did not live up to expectations

#49

Post by heifer2822 »

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 think TDD helps or doesn't help depending on the circumstances. The problem is the people who claim there's One True Way.

For instance, if you were working on a big app and there was a bug, writing a failing test for that bug and then looking into the fix is very helpful. But if you're starting a new project from scratch with loose requirements, or worse yet, building a prototype, starting with tests would be a waste of time at best.

Re: TDD did not live up to expectations

#50

Post by AdmiralAsshat »

Stylistic critique of the article: Is it too much to ask that you enumerate your acronym at least once throughout the entire article? The acronym "TDD" appears 16 times throughout the article, and not once do we get "Test-driven development" spelled out.

I get that it's a technical blog, but "TDD" isn't exactly a household name. You can't utter it in the same breath as SSL or RSA and expect people to know what it means without context.

As a test (no pun intended), try reading the article with the premise that you have NO idea what "TDD" stands for. Can you reasonably infer it from the rest of the article?

Post reply on HN