Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I Hate Test Driven Development

robg3d.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Why I Hate Test Driven Development

#61

Post by Retric »

boyter wrote: post #34
kiba wrote: post #3

I hate TDD because I have to actually debug them, sometime more so than the actual app themselves. Also, there's the issue of slow TDD suite, which means you have to optimize them or otherwise it will slow down your development pace. TDD is only good when it provide more benefits than its negative(debugging time, time waiting for it to run, time spent ripping out code). That being said, it's better than 0 test. Just…

Unless of course you are writing software that goes into a pacemaker, in which case I would want that tested like crazy for every possible scenario you can imagine including automated fuzz testing. Same goes for databases and quite a few other classes of software. In short, use common sense. Personally I love TDD. Not because of the tests, but because the resulting code IS testable, and generally testable code is mai…

If I knew one pacemaker was developed with TDD and one without it I would probably go for the one without it. Most programs are fine on the Happy Path, and TDD seems like it's focused on expanding the Happy Path vs actually writing correct software.

This could just be internal bias, but without TDD programmers more focused on the possible error conditions. I would rather see:

  If ((a/2-1) + (b/2-1)) > (largestInt/2-5)) 
  ... do something
  vs.
  A large try catch block.
Arguably the second is just as safe, but it's the test's you don't think to run that tend to end up as production bugs and good tests require a level of paranoia which is more important than methodology IMO.

Re: Why I Hate Test Driven Development

#62

Post by raverbashing »

jsprinkles wrote: post #26
begriffs wrote: post #23

Reminds me of what Edsger Dijkstra wrote, "Let me start with a well-established fact: by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. A major part of the average programmer's activity is devoted to debugging, and from this observation we may conclude that the correctness of his programs —or should we say: their patent incorrectness?— is for him a…

Next, tell us why goto is bad.

It's not necessarily bad, for example, see how it's used on the linux kernel (+/- like an exception handler)

But of course, having a mess is bad and goto makes it really easy

Re: Why I Hate Test Driven Development

#63

Post by politician »

vlisivka wrote: post #58
jrockway wrote: post #32

Earlier quoted context omitted.

That's quite a generalization. Debugging does not necessarily mean debugging your own code: you might have stumbled upon a compiler bug, or a timing bug with your hardware, or you may be trying to buffer overflow some massive proprietary database so you can take over the world. All of those tasks will involve lots of time looking at memory addresses and hex dumps, but none of them mean the person doing it is a bad pr…

Why you need to look at them manually? Computer will compare all that much faster. If you are good programmer and bug is non-trivial, you will create code to catch bug much faster than you will catch it manually. Moreover, you will be rewarded next time, because your code will be already written and ready to use.

It dramatically improves your cycle time to debug this kind of issue interactively instead of repeatedly stopping the process, coding up a hypothesis as a test case, running the tests, and then dealing with the positive results and the false positive results.

Re: Why I Hate Test Driven Development

#64

Post by fierarul »

begriffs wrote: post #23

Reminds me of what Edsger Dijkstra wrote, "Let me start with a well-established fact: by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. A major part of the average programmer's activity is devoted to debugging, and from this observation we may conclude that the correctness of his programs —or should we say: their patent incorrectness?— is for him a…

>Apparently, many programmers derive the major part of their intellectual satisfaction and professional excitement from not quite understanding what they are doing.

This is one of my favorites remarks from Dijkstra, but I found it in a video interview with him. I had no idea there's more context to this. Thanks!

Re: Why I Hate Test Driven Development

#65

Post by vlisivka »

politician wrote: post #63
vlisivka wrote: post #58

Earlier quoted context omitted.

Why you need to look at them manually? Computer will compare all that much faster. If you are good programmer and bug is non-trivial, you will create code to catch bug much faster than you will catch it manually. Moreover, you will be rewarded next time, because your code will be already written and ready to use.

It dramatically improves your cycle time to debug this kind of issue interactively instead of repeatedly stopping the process, coding up a hypothesis as a test case, running the tests, and then dealing with the positive results and the false positive results.

So question is: why I awarded as "Top Performer", while I avoiding debugger at all cost? ;-)

Re: Why I Hate Test Driven Development

#66

Post by jrockway »

vlisivka wrote: post #58
jrockway wrote: post #32

Earlier quoted context omitted.

That's quite a generalization. Debugging does not necessarily mean debugging your own code: you might have stumbled upon a compiler bug, or a timing bug with your hardware, or you may be trying to buffer overflow some massive proprietary database so you can take over the world. All of those tasks will involve lots of time looking at memory addresses and hex dumps, but none of them mean the person doing it is a bad pr…

Why you need to look at them manually? Computer will compare all that much faster. If you are good programmer and bug is non-trivial, you will create code to catch bug much faster than you will catch it manually. Moreover, you will be rewarded next time, because your code will be already written and ready to use.

Let's call it "exploratory programming" instead of debugging. Yes, your computer will run unit tests. No, your computer will not notice that memory is being corrupted because of a particular sequence of instructions emitted by the compiler. To solve a problem, you have to understand it. And if you're writing code to solve a problem that's well-understood, you should have just downloaded the library instead.

Re: Why I Hate Test Driven Development

#67

Post by jinushaun »

Fice wrote: post #44

I tend not to like TDD for a different and serious reasons. TDD seems to encourage bad trial and error programming practices where developer blindly modifies the code until it passes the tests instead of reasoning about correctness based on algorithms and specifications. TDD does not consider that even a program that work correctly in the current environment for any possible set of input data is still incorrect if it…

Not to sound snarky, but sounds like you're doing it wrong. You're right that the canonical example of TDD is to write a test that fails and write code until the test passes, but that, IMO, is an over-simplification that ignores the motivation behind TDD. You should write tests whether or not you do TDD, but TDD ensures proper test coverage. If you write tests first, you ensure every line of code is covered by a test.

Otherwise you have to do what I had to last month, which was go back—after the fact—and write unit tests for a large chunk of our code base because we didn't have an automated way of verifying that our logic worked with different (read: non-happy path) data sets.

Re: Why I Hate Test Driven Development

#69

Post by vlisivka »

jrockway wrote: post #66
vlisivka wrote: post #58

Earlier quoted context omitted.

Why you need to look at them manually? Computer will compare all that much faster. If you are good programmer and bug is non-trivial, you will create code to catch bug much faster than you will catch it manually. Moreover, you will be rewarded next time, because your code will be already written and ready to use.

Let's call it "exploratory programming" instead of debugging. Yes, your computer will run unit tests. No, your computer will not notice that memory is being corrupted because of a particular sequence of instructions emitted by the compiler. To solve a problem, you have to understand it. And if you're writing code to solve a problem that's well-understood, you should have just downloaded the library instead.

Did you ever saw how program crashes when run, but works fine in debugger (or vice versa)? What you will do in such case? What you will do after few such cases?
Post reply on HN