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

51–60 of 69 posts

Re: Why I Hate Test Driven Development

#51

Post by gouranga »

Great article. Between TDD, dotting constraint checks all around my code and actually knowing what I want before I write it, I rarely have to use any debugger.

With respect to people feeling like TDD is a waste of time, this thought is immediately extinguished the moment you see an accidental regression get flagged instantly, resulting in you NOT having to spend hours finding it.

Debugging is one of those tasks that you don't really want to have to do either. If you're debugging all the time, you are doing things wrong. I don't find debugging fun - I find problem solving fun (not problems I've created!).

Re: Why I Hate Test Driven Development

#52

Post by drostie »

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…

My problem is more that I never know what to test. I mean, suppose I have some nontrivial code -- one of my latest random projects contains this:

    def permute(tpl):
        """Gives the set of valid permutations for this tuple."""
        if len(tpl) == 0:
            yield ()
        else:
            for t in permute(tpl[1:]):
                for n in range(0, len(t) + 1):
                    yield t[0:n] + (tpl[0],) + t[n:]
It's a recursive generator-driven permutation engine. Technically I suppose the order of the permutations doesn't matter, so long as they are all distinct and there are n! of them. Is that what I should be testing? That is, should my test code read:

    permute_test = tuple(permute((1, 2, 3, 4)))
    assert(len(permute_test) == 24)
    for i in range(0, 24):
        assert(len(permute_test[i]) == 4)

    for i in range(0, 23):
        for j in range(i + 1, 24):
            assert(permute_test[i] != permute_test[j])
...? And if so, how does that help me write the original function? Or am I supposed to test a base case and one or two recursion steps, so that it helps me write the function, but "hard-wires" a particular order?

Re: Why I Hate Test Driven Development

#53

Post by scott_w »

smiler wrote: post #46
keypusher wrote: post #43

Earlier quoted context omitted.

There is an entire field of CS research on this topic, commonly referred to as formal verification. Some programs are written this way.

Yup and I had to take two modules on it for my degree. I've never encountered anything so dull in my life! [That was probably because the material was presented in such a dry way, I'm pretty sure anything can be interesting if someone with passion is also a skilled presenter]

It's definitely the presentation. I also studied formal verification in my second year and used it as an opportunity to catch up on missed sleep.

However, the third year I studied how to formally define programming languages and really enjoyed it. It was all about delivery.

I think class size has an effect too - it's much easier to engage with smaller classes. The second year module was mandatory, whereas the third year module was optional.

Re: Why I Hate Test Driven Development

#54

Post by blazingice »

drostie wrote: post #52
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…

My problem is more that I never know what to test. I mean, suppose I have some nontrivial code -- one of my latest random projects contains this: def permute(tpl): """Gives the set of valid permutations for this tuple.""" if len(tpl) == 0: yield () else: for t in permute(tpl[1:]): for n in range(0, len(t) + 1): yield t[0:n] + (tpl[0],) + t[n:] It's a recursive generator-driven permutation engine. Technically I suppos…

You have a good point about TDD, and I'm unsure how to address it.

However, you might find the itertools library helpful, particularly itertools.permutations(): http://docs.python.org/library/itertools.html#itertools.perm...

Re: Why I Hate Test Driven Development

#55

Post by mcobrien »

drostie wrote: post #52
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…

My problem is more that I never know what to test. I mean, suppose I have some nontrivial code -- one of my latest random projects contains this: def permute(tpl): """Gives the set of valid permutations for this tuple.""" if len(tpl) == 0: yield () else: for t in permute(tpl[1:]): for n in range(0, len(t) + 1): yield t[0:n] + (tpl[0],) + t[n:] It's a recursive generator-driven permutation engine. Technically I suppos…

You're right to want to avoid duplicating your code inside your test. In this case, I'd work out some simple permutations and test against those values, sorting the results so order doesn't matter.

    assert(sorted(permute((1, 2))) == [(1, 2), (2, 1)])

Re: Why I Hate Test Driven Development

#56

Post by vlisivka »

LaRakel wrote: post #49
jakejake wrote: post #7

I can kinda relate to having fun fixing bugs, but I think (i addition to some sarcasm) the author is kinda romanticizing debugging. 90% of the time it's no fun, feels like a waste of time and doesn't really provide much satisfaction. Once in a while, though, you do find a really interesting bug and fix it and it feels pretty great!

Creating tests usually feels like a waste of time as well.

Execute all these test cases by hands 10 times a day and feel the difference. You will enjoy automating after that.

Re: Why I Hate Test Driven Development

#57

Post by vlisivka »

jsprinkles wrote: post #10
pthread wrote: post #4

This is a good thing, isn’t it? So why do I hate TDD? Because debugging is fun. There, I said it. I love debugging. I think lots of clever people like debugging. I've been doing embedded development for quite some time, so you know, flipping bits like a boss, a shitload of open terminals, lots of cables everywhere all the stuff that makes you look like you know what you're doing but debugging is not fun, it never was…

I debug because I'm smart, and I enjoy it, and I frequently find bugs that I didn't know existed by seeing inside a frame as it's executing. Debugging is a crucial skill in many fields, particularly embedded work (which is the irony in your comment), and the insight from breakpoints and a couple afternoons of digging is unique among our tools. I hate sweeping generalizations of how programming should be done, regardl…

If you are programmer, why you debug your programs manually ?

I, personally, stopped to use debugger more than 10 years ago.

Re: Why I Hate Test Driven Development

#58

Post by vlisivka »

jrockway wrote: post #32
pthread wrote: post #16

Earlier quoted context omitted.

If you love debugging, I don't think you're a seasoned or valuable programmer.

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.

Re: Why I Hate Test Driven Development

#59

Post by yummyfajitas »

drostie wrote: post #52
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…

My problem is more that I never know what to test. I mean, suppose I have some nontrivial code -- one of my latest random projects contains this: def permute(tpl): """Gives the set of valid permutations for this tuple.""" if len(tpl) == 0: yield () else: for t in permute(tpl[1:]): for n in range(0, len(t) + 1): yield t[0:n] + (tpl[0],) + t[n:] It's a recursive generator-driven permutation engine. Technically I suppos…

...so that it helps me write the function, but "hard-wires" a particular order?

Use assertItemsEqual.

http://docs.python.org/library/unittest.html#unittest.TestCa...

The way I do it:

In the doctest, I include a few toy examples, stuff I can verify by hand, and which helps the user understand what I'm doing.

In the unit tests, I try to do things in the style of Haskell's Quickcheck (the greatest testing library out there). Generate some random values and test properties (e.g., len(permute(x)) == factorial(len(x))).

Re: Why I Hate Test Driven Development

#60

Post by astrec »

smiler wrote: post #46
keypusher wrote: post #43

Earlier quoted context omitted.

There is an entire field of CS research on this topic, commonly referred to as formal verification. Some programs are written this way.

Yup and I had to take two modules on it for my degree. I've never encountered anything so dull in my life! [That was probably because the material was presented in such a dry way, I'm pretty sure anything can be interesting if someone with passion is also a skilled presenter]

That's quite sad: Formal methods should be one of the more exciting topics in your CS programme. Hope they didn't scar you too badly.
Post reply on HN