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

211–220 of 450 posts

Re: TDD did not live up to expectations

#211

Post by seanmcdirmid »

s73ver wrote: post #108
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.

No you don't. You just need to know what the unit you're currently working on does. And if you're working on it, you should know what it does. If you don't, that's a sign that maybe you need to have a conversation with someone.

> You just need to know what the unit you're currently working on does.

Which means the system design must be obvious enough that you have well defined lowly coupled units in the first place.

Re: TDD did not live up to expectations

#213

Post by reitanqild »

poikniok wrote: post #200
reitanqild wrote: post #178

Earlier quoted context omitted.

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?

Nothing. There is nothing wrong with code generation in a production setting with "grown up" engineers who uses version control and knows the pitfalls.

The part in parenthesis is just a rant about education and how teachers use notepad and javac to teach Java.

So my point is the only thing students shouldn't use in an IDE is code generation.

Re: TDD did not live up to expectations

#214

Post by dragonwriter »

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.

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

I've literally never encountered this idea, in person or otherwise, from anyone advocating TDD, only as a an argument TDD opponents like this attack. I'm not sure if it's a rare argument they've latched onto, a common misunderstanding of the purpose of TDD, or an outright strawman, but it's certainly not the main argument (or one of them) I've seen for TDD.

TDD:

1. Validates that you have a reasonably clear operational understanding of the intended behavior (but not completeness), forcing more questions out early and preventing some portion of the waste of code aimed at something that isn't the intended functionality that would otherwise occur, and

2. Assures that automated tests (which are often most valuable for regression testing later changes) actually get written, which is a significant issue in practice with test-last processes.

Re: TDD did not live up to expectations

#215

Post by YZF »

lliamander wrote: post #191
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…

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…

I absolutely agree. It's also nice to know:

* What's my confidence that the code will work correctly under different situations.

* How maintainable the code is and related how easy is it to make changes.

* How much time/effort does it take to create.

It's funny (or sad) how the XP guys like Kent are always talking about doing the right thing and not being religious. This stops working when the people using it don't know what the right thing is any more. They write terrible tests, they make bad changes to their code to support those tests, it ends up a big un-refactor-able ball of mud that takes longer to create and is more difficult to maintain.

If you're writing a shortest path algorithm or a JPEG decoder then you absolutely should code up some tests to check your code. The tests are relatively simple. They don't need to know anything about the internals of your code. They help you check quickly whether your code is correct and don't interfere with any refactoring. You can rewrite your JPEG decoder from scratch without needing to touch the tests at all.

Re: TDD did not live up to expectations

#216

Post by strictnein »

Ace17 wrote: post #193
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". How…

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

I mean, any developer should be able to write a sort. They might end up with some O(2^n) behemoth, but they should be able to do it.

Re: TDD did not live up to expectations

#217

Post by fanpuns »

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 still uncertain if my solutions or code will even work and writing tests helps me to both organize what I want to do and also verify that I haven't made silly syntax mistakes.

Was it harder to learn this way? Absolutely (at least I think so, but my sample size is 1). I can't tell you the state of despondency I was sometimes in learning test suites and trying to figure out how to test certain things all while knowing that I could just write the stupid code and inspect the output to see if it was right.

Also, I love to refactor. How do you refactor if you don't have tests to catch you when you break something?

Re: TDD did not live up to expectations

#219

Post by kafkaesq »

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…

TDD failed for economic reasons, not engineering ones.

And yet, engineering is inseparable from economics.

Re: TDD did not live up to expectations

#220

Post by ern »

baybal2 wrote: post #208

As I remember, one Microsoft was one of the original TDD pushers. One person who worked there for over 20 years told me that "the peak TDD" at Microsoft was right around time of Win ME release

As I remember, one Microsoft was one of the original TDD pushers.

You may be mistaken: There was a well-known incident back in 2005 where Microsoft published guidance for TDD that was flat-out wrong (or at least not fitting with the mainstream understanding), and they had to retract it (in fact it was so far-out that they had to expunge the article from MSDN).

http://codebetter.com/jeremymiller/2005/11/18/microsoft’s-re...

One person who worked there for over 20 years told me that "the peak TDD" at Microsoft was right around time of Win ME release

Of course, Microsoft is big, and the broken guidance may not have reflected practices elsewhere in the company, but it seems unlikely that they were early TDD pushers if they hadn't grasped the concept (as commonly understood) by 2005.

Post reply on HN