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

191–200 of 450 posts

Re: TDD did not live up to expectations

#191

Post by lliamander »

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…

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 where he could quickly inject his parser into the logging stream, visually inspect the results, tweak, and then test again.

Others (Such as Martin Fowler and Uncle Bob) have also emphasized the value of automated unit testing integrated with a CI pipeline as a way of ensuring that you didn't break existing functionality.

As always, what's important is not the specific practice, but rather the engineering principles behind it. The key questions being:

* Am I on the right track?

* Did I break existing functionality?

* How quickly and frequently can I get answers to the above two questions?

Re: TDD did not live up to expectations

#192

Post by kevwil »

This logic is flawed, and I'm not surprised it's coming from Microsoft. If the expectation is that (repeatedly?) making blind guesses quickly and (optionally) cleaning up the mess later is better than expressing an understanding of the problem domain before writing 'real' code, then yes TDD will not live up to those expectations.

Re: TDD did not live up to expectations

#193

Post by Ace17 »

austenallred wrote: post #3

The problem with TDD is that we flawed humans are writing the tests in the first place. If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code. I use it on occasion as a good sanity check to make sure I didn't break anything too obvious, but this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.

> If I suck at writing code there's no reason to believe I wouldn't suck at writing tests to check that code.

Actually, there is ; providing the difficulty is algorithmic. Take "sort", for example.

// test code

assertEquals([1,2,3,4,5], sort([4, 1, 2, 3, 5]))

// production code

int[] mySort(int[] list)

{

  // TODO: implement a sorting algorithm here.
}

Any programmer could write a fairly good test suite for "sort". However, I highly doubt they could write the implementation.

Of course, this is a very simple example.

Most of the times, the difficulty lies in finding the proper interface between test and production code. And there, there's no way to compensate for poor software design skills. Actually, forcing bad software designers to test the code they write might even worsen the situation, by rigidifying poorly-designed-wannabe-interfaces.

> this idea that TDD is a panacea where no bugs ever survive didn't ever make sense to me in the first place.

This is the software industry ; new techniques are confused with silver bullets!

Re: TDD did not live up to expectations

#194

Post by seanmcdirmid »

nostrademons wrote: post #91
Retric wrote: post #71

Earlier quoted context omitted.

Which is another way of saying TDD is somewhat usefull, if you start from a huge pile of code written by someone else. When you think this might be going on, so if I do this it should work... then writing some tests will help decide if your assumptions or your code is wrong. Most importantly you are probably writing minimal code in those situations so the overhead of tests is minimized.

Or even just a clear spec from a customer who knows what they want. The challenge in most of the software industry is that the customer does not know what they want, and oftentimes it isn't even clear who the customer is. TDD is great if you can define your problem well enough to write tests for it up-front. Most software problems with a decent economic return are not like that.

I would say that the primary job of a modern developer is actually to figure out what the spec really is. Implementing the spec is easy in comparison. More often than not, "bugs" are errors in the spec that TDD of course has no hope of catching.

Re: TDD did not live up to expectations

#195

Post by HeroOfAges »

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…

"If you think clearly about your problem, invariants, and APIs then you will guide yourself towards a decent system."

This is the most beneficial part of TDD to me. Most devs will deny this, but their biggest issue with TDD is not wanting to take the time to think clearly about a problem. To me that seems a bit sloppy and lazy. We're supposed to be professionals. From some of the comments I've read, it also seems that devs are trying to "test drive" or write unit tests for the wrong things. As I've gained experience as a software developer, I actually look for ways to write less code. The most effective way for me to do that, is to actually think about the problem before I write a single line of code. If I have a clear idea of what it is I'm trying to build, it's very easy for me to write a test first. If I can't identify a way to write a failing test, it's an indication to me that I really don't understand the problem well enough to deliver a dependable solution.

Re: TDD did not live up to expectations

#196

Post by nekitamo »

briandear wrote: post #74
AdmiralAsshat wrote: post #50

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 mea…

What’s RSA?

https://en.wikipedia.org/wiki/RSA_(cryptosystem)

Re: TDD did not live up to expectations

#197

Post by kevwil »

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?

Wow, if that's how people are describing it, no wonder it's seen negatively. That seems very waterfall-ish and horrible. Thankfully that's not TDD as originally intended.

Re: TDD did not live up to expectations

#198

Post by [deleted] »

Cephlin wrote: post #14
willvarfar wrote: post #9

No article about TDD, particularly one that shouts out to the respected Ron Jeffries http://ronjeffries.com/ , is complete without mentioning the TDD Sudoku Fiasco :) Ravi has a nice summary: http://ravimohan.blogspot.se/2007/04/learning-from-sudoku-so... Peter Norvig's old-fashioned approach is excellent counterbalance: http://norvig.com/sudoku.html

Uncle Bob always has some clever things to say on TDD too: http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar... and: http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-w...

[deleted]

Re: TDD did not live up to expectations

#199

Post by plinkplonk »

willvarfar wrote: post #9

No article about TDD, particularly one that shouts out to the respected Ron Jeffries http://ronjeffries.com/ , is complete without mentioning the TDD Sudoku Fiasco :) Ravi has a nice summary: http://ravimohan.blogspot.se/2007/04/learning-from-sudoku-so... Peter Norvig's old-fashioned approach is excellent counterbalance: http://norvig.com/sudoku.html

that 3 line post is the most popular blog post I ever wrote.

I got a lot of nasty mail from agile consultants, but it was worth it, heh!

Which reminds me, I haven't blogged in years.

One day I just stopped.

Perhaps it is time to restart.

Re: TDD did not live up to expectations

#200

Post by poikniok »

reitanqild wrote: post #178
hinkley wrote: post #166

Earlier quoted context omitted.

In this case a bunch of former Java devs touching Java for the first time in a while. There could be something to that. Could be they've forgotten how, but this isn't the first experience like this. I am doing fine with the tools even though they don't do everything when the language is not statically typed).

I'm afraid it is common. Java isn't perfect and when people also treat their IDE as a glorified text editor I think it is no wonder they dislike it. (If you go with Java, embrace it. This is probably the thing I disliked most about the way programming was taught in school: they used Java, but without the tooling that makes it awesome. Supposedly so we should learn it well. If anyone here teaches Java: by all mean hav…

What is wrong with autogenerated code?
Post reply on HN