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

391–400 of 450 posts

Re: TDD did not live up to expectations

#391

Post by agentultra »

nickpsecurity wrote: post #325
agentultra wrote: post #29

Maybe the title should be: TDD did not live up to my expectations ? I too, like the author, have been practicing TDD for > 10 years. Test, implement, refactor, test... that's the cycle. If you follow that workflow I've never seen it do anything to a code base other than improve it. If you fail on the refactor step, as the author mentions, you're not getting the full benefit of TDD and may, in fact, be shooting yourse…

"But for me, TDD, is just the state of the art. I've yet to see someone suggest a better process or practice that alleviates their concerns with TDD." Design by Contract specifying key properties at interfaces with tests for stuff not easy to specify was state of the art in the 90's. In the 2000's, there's tools to automatically generate tests from such properties or apply formal proofs to code if it's simple enough.…

Hey nickpsecurity! :)

> I don't see TDD as either strongest method or state of the art.

It's not the strongest method. But as far as the SWEBOK[0] is concerned it is state of the art.

The most effective teams I've worked with layer their testing strategies and use multiple approaches to verification depending on the needs of the project. I love quickcheck. I even pull out formal methods when the problem domain demands it or I need to check my thinking.

On the scale of "sketch on a napkin" to "verified and signed-off-by-master-engineer blueprint" I'd say a unit test suite, as far as it is a specification, is somewhere between napkin and the middle. If you use a soundly typed language AND a unit test suite using property-based assertions you're somewhere in the middle; building houses.

However I do see it as a warning sign if a team actively avoids TDD and tries to ship the first thing that works. If I was an actuary that project would represent a high level of risk and I'd probably raise their insurance rates to match that risk depending on the work they're trying to do.

Re: TDD did not live up to expectations

#392

Post by UK-AL »

sametmax wrote: post #387

Another reason for the failure of TDD is the fact you need to be a very good programmer to be productive with it. Indeed, it requires you to be able to think your general API and architecture ahead. Junior and 9-to-5 programmers suck at this. They are much better at tinkering until it forms a whole, then shape that into something that look decent and works well enough. And we live in a world where they represent a go…

Not really. Core tenants of TDD are failed test -> Get it working -> Refactor into something nice.

Re: TDD did not live up to expectations

#393

Post by UK-AL »

raverbashing wrote: post #78
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…

Yes a lot of people kept parroting TDD (as most people parrot the latest fad without thinking for 3 seconds if they should actually do that) > I absolutely think _tests_ are useful, but have never found any advantages to test-DRIVEN-development (test-first). Seconded. Especially the crap about "make the test fail first" (making the test fail is useful, especially if you're unfamiliar with some aspect of it), but it s…

The term making the test fail, isn't about explicitly making the test fail.

It's about the fact that it's not implemented yet, so of course it going to fail!

Re: TDD did not live up to expectations

#394

Post by th4dv »

taeric wrote: post #64
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…

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…

> The main failing of TDD is the assumption that you know all of the tests that you will need before you know your software

One of the main failings of TDD is that developers think they need to know all of the tests up front.

Re: TDD did not live up to expectations

#395

Post by UK-AL »

moron4hire wrote: post #62
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…

Like the author in the original article, I used to be all about TDD. Now, I like to tell people that "I'm apostate in the ways of TDD". I specifically use the language of religion because I think strict adherence to TDD is itself a religion. I somewhat disagree with the statement he makes, "we know that most developers do not have great design/refactoring skills". I've certainly worked at places that all but ordered…

I find TDD very good implementing business rules on objects. Not so great experimentation on UI and presentation, which is what you seem to be doing.

You have to remember there a lot programmers out there, just implementing business rules into code.

Re: TDD did not live up to expectations

#396

Post by sametmax »

UK-AL wrote: post #392
sametmax wrote: post #387

Another reason for the failure of TDD is the fact you need to be a very good programmer to be productive with it. Indeed, it requires you to be able to think your general API and architecture ahead. Junior and 9-to-5 programmers suck at this. They are much better at tinkering until it forms a whole, then shape that into something that look decent and works well enough. And we live in a world where they represent a go…

Not really. Core tenants of TDD are failed test -> Get it working -> Refactor into something nice.

But you need to know what the working API must look like. Creating an API is a much harder task than you think. You are used to it so it seems natural to you, but I assure you I keep giving training in IT months after months, and most people are not very good at it.

HN is full of 10x devs and they live in an expert bubble.

Re: TDD did not live up to expectations

#397

Post by UK-AL »

borplk wrote: post #218

Unfortunately TDD has become a band-aid for lack of constructs that should be a part of the language in the first place. A language that allows you to express the spec could be so much more useful.

If you implement the feature in the language, surely that language is expressing the spec.

Re: TDD did not live up to expectations

#398

Post by hdi »

romanovcode wrote: post #357

Oh, finally the TDD fad is dying. Never got into it and always thought it is a complete waste of time. I advocate to write tests only for critical algorithmic calculations and nothing else. Integration tests matter 100x more (at least in webdev).

> Never got into it and always thought it is a complete waste of time. I advocate to write tests only for critical algorithmic calculations and nothing else.

What great advice! While we're at it let's advocate surgeons didn't use sterile instruments cos it's a waste of time.. well maybe only for heart transplants.

Re: TDD did not live up to expectations

#399

Post by richardknop »

tokenizerrr wrote: post #373
richardknop wrote: post #359

Earlier quoted context omitted.

Well, that's exactly this case. You would write a test to replicate/prove the bug and then - afterwards write the code to fix the bug, no? So you would write tests first.

But the code containing the bug is already there. The idea of TDD is that you write tests verifying behavior before there is any code.

If you are writing something from scratch yes. But if you inherited a codebase written by somebody else who didn't to TDD so there are no tests, you can still use TDD for refactoring.

So any new changes/bugfixes you will make to this legacy codebase, first you will write a test and then make change. That's pretty standard. Many legacy codebases will have no tests and people who wrote the code will have left long time ago.

Re: TDD did not live up to expectations

#400

Post by moron4hire »

Joeri wrote: post #275
moron4hire wrote: post #62

Earlier quoted context omitted.

Like the author in the original article, I used to be all about TDD. Now, I like to tell people that "I'm apostate in the ways of TDD". I specifically use the language of religion because I think strict adherence to TDD is itself a religion. I somewhat disagree with the statement he makes, "we know that most developers do not have great design/refactoring skills". I've certainly worked at places that all but ordered…

They thought "refactoring" was a made-up word that programmers used to cover up dicking around and wasting time. From a non-programmer's perspective, all they see is the programmer spending several hours with the end result being that nothing has visibly changed. The thing is, many refactoring efforts make code worse, not better. Refuctoring is something I've observed many times over, by people who consider themselve…

Even in the honest case, I think people go about it wrong. Refactoring as a separate step is going to get a lot of push-back from a lot of different places. But there frequently is a need to change the structure of existing code to make room for new features (especially if you're on a team having to deal with "refuctoring").

Just put it in the estimate for that new feature. When your boss starts to needle you about why such a "simple" feature is taking so long, that is when you throw the bad code under the bus. You get to demonstrate a real need, rather than just a theoretical one.

The older I get, the more I believe "Big Bang" code is a bad idea, no matter what the bang actually entails. Gotta make a branch to make a feature? Gotta rewrite a large part of the underpinnings of the app to make things able to move forward? Please don't, please develop it in parallel in the mainline.

In a way, refactoring on its own violates TDD. You are supposed to write failing tests first, then write code that passes the test. Refactoring as it is described by the most zealous of TDD advocates is just a hand-waiving over writing code without testing. If we're being strict about it, write a test that proves the code needs to be changed, then you can change the code. If we're not being strict about it, what is even the point?

Regression is some of the biggest harm that can come to users, because it violates their ingrained expectations. Greenfield defects might prevent the adoption of a new feature, in which case the status quo is maintained, but regression is forward progress that is physically lost.

Post reply on HN