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

241–250 of 450 posts

Re: TDD did not live up to expectations

#241

Post by lliamander »

srcmap wrote: post #235
lliamander wrote: post #191

Earlier quoted context omitted.

It's worth noting that Kent Beck ("Father of TDD") himself said that TDD doesn't always make sense. For him, the important thing has always been having a tight feedback loop for determining if he was still on the right track. For instance, when he was working on an unstructured log parser, there was no way TDD would work because the logging stream didn't have a pre-defined structure. Instead, he developed a process w…

TDD always worked for me. All successful projects in my career had full functional regression test coverage. For those successful projects, I made following conclusions: * My personal TDD process are: * Script enable - always run every night, every weekends. Output to html files to see overall green/red in

Sounds like you're doing the right thing. Note that not every one would agree that you are doing "true TDD" (due to your lack of "unit" tests) but that doesn't matter. What matters is that:

a) you are disciplined in your commitment to quality

b) you offload as much of the tedious, repetitive work to the computer as possible.

Regarding unit tests and mocking, I have a similar opinion. I tend to test at the larger component/package level rather than the smaller class/module level. Furthermore, I avoid mocking as much as possible. Object-Oriented decoupling through dependency injection makes mocking a lot easier (and removes the need for mocking frameworks) and Functional decoupling[0] makes mocking largely unnecessary.

[0]http://prog21.dadgum.com/131.html

Re: TDD did not live up to expectations

#242

Post by sb8244 »

taeric wrote: post #132
sb8244 wrote: post #120

Earlier quoted context omitted.

You can throw away the test if you don't find value in it. This can be very useful for fleshing out an idea.

But this advice should be extended further. Always be willing to throw away the code and the tests. Take the learning. Be ware, though, that you are not throwing your customers for a bad ride. As soon as you have customers, it is nigh impossible to throw away the code without neglecting them. And they are your ultimate responsibility. Not the code.

Exactly right, it can be very hard to make changes (even the right changes) once it's in customer hands. Sometimes it is easy, sometimes it is not. However, it's always easy to throw out code that isn't yet committed.

Re: TDD did not live up to expectations

#243

Post by fran7118 »

stale2002 wrote: post #75
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…

"What I've found works really well is independently writing tests afterwards to really test your assumptions." Sure. If you actually do it. The problem with most companies, and the reason why I think that TDD 'works' is that it forces you to right some tests, any tests at all. Many people, if they don't write the test first, will just end up not making any tests at all.

Exactly. I worked at a place where the majority of dev teams had little to no automated tests. Getting them to write tests was near impossible due to it 'taking too much time away from features and bug fixes'.

One team adopted TDD and forced themselves to do it for a year. They admitted it slowed their overall dev-cycle down a ton, but they ended up learning a lot about how to build a well designed API. I think more internal documentation about good design emerged from that then them evangelizing TDD.

Re: TDD did not live up to expectations

#244

Post by remotehack »

Software obeys its own dynamics. Some things work well. Some not quite the same. It's nice to see someone admitting that testing is good, rigid TDD; like rigid Agile or rigid Waterfall, are bad. Corollary, what our parents said still holds true; too much of a good thing is bad.

Re: TDD did not live up to expectations

#245

Post by remotehack »

dang wrote: post #221
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…

> the assumption that you know all of the tests that you will need before you know your software I'm not a TDDer but must object on their behalf: not only is that not what they said, it couldn't be further from it! What they taught was to work in short iterations and work out a bit of requirements, design, and implementation in each one. If you needed knowledge you didn't have yet, they would advise you to make each…

> iterations

The property of iterations is that things change, outcomes change, ideas change, requirements change. Iterations are not black boxes that we tuck away as 100% complete; they often require re-examination as the iteration process continues.

Re: TDD did not live up to expectations

#246

Post by dang »

remotehack wrote: post #245
dang wrote: post #221

Earlier quoted context omitted.

> the assumption that you know all of the tests that you will need before you know your software I'm not a TDDer but must object on their behalf: not only is that not what they said, it couldn't be further from it! What they taught was to work in short iterations and work out a bit of requirements, design, and implementation in each one. If you needed knowledge you didn't have yet, they would advise you to make each…

> iterations The property of iterations is that things change, outcomes change, ideas change, requirements change. Iterations are not black boxes that we tuck away as 100% complete; they often require re-examination as the iteration process continues.

Sure. I think the idea was that you'd incorporate that into the next iteration. But what do I know—I'm sure we were all doing it wrong.

Re: TDD did not live up to expectations

#247

Post by PaulKeeble »

Microsofts own study of TDD showed that it definitely improved defect rates and they went fully into developing with it for Vista which is part of the reason for the delays. Nowadays large chunks of the API is automatically tested and this has allowed Microsoft to release changes must more often with a lot less manually testing.

So while this individual is finding his local team isn't getting the full benefits, Microsoft appears to be based on its own report on the technique and its outwards software release cycle changing.

Re: TDD did not live up to expectations

#248

Post by PaulKeeble »

fanpuns wrote: post #217

I appreciate that many of you (including the article author) are coming at this question with a lot of experience. I, however, knew very little about coding a year ago and learned with TDD as part of how I build almost every project. Although I think it's always the case that I might "be doing it wrong", it's hard for me to imagine now writing code without first writing tests. Part of this is, admittedly, that I'm st…

You don't refactor if you don't have tests, or rather you do and you break stuff and take on a lot of risk. The reality is a lot of developers aren't working in teams with others and working on software that has a long future ahead of it, hacker news tends towards the smaller teams with short runways and its write it and throw it away as a strategy rather than refactoring.

Re: TDD did not live up to expectations

#249

Post by ericgunnerson »

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…

Author here...

I agree that time to market is really important, but when a company is searching for the product that will work, the most important thing that you can have is code that is easily refactored, which generally means low coupling.

TDD is one way to get there for some people, and it's not 2x the amount of time. My experience is that TDD takes a little bit longer (say 30%) than just writing the code, but my bug rate with TDD code (and I don't do TDD for all my code) is very small. Bugs are so damn expensive that 30% to not have them is a small investment, even if that were the only benefit you got.

Re: TDD did not live up to expectations

#250

Post by ericgunnerson »

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…

Author here...

This discussion on what happens - or doesn't happen - after the tests are passing is precisely the point of the article.

The idea of TDD is that every test you look at the existing code and improve it. The majority of developers I've seen trying TDD do this with small code but do not with significant codebases, and you end without the benefits.

Post reply on HN