Oh yeah when a test fails I have to call AAA to tow my git repo out of the ditch. Then I have to phone up Mutual Insurance to see if they’ll cover it or if I’ve got to pay myself. And then I have to drive my repository into the shop so that they can buff out the dents.
Analogies are what people use when they don’t have actual arguments. I’m not sure there’s much to be gained from engaging with them.
Analogies are what people use when they don’t have actual arguments. I’m not sure there’s much to be gained from engaging with them.
I strongly disagree with this. Analogies are what people use when they want to communicate a concept quickly and effectively, regardless of whether they have “actual arguments” or not. Dismissing analogies as mere rhetoric is itself a form of rhetorical sleight of hand used to avoid engaging with the point being made.
Hickey’s point, as I understand it, is this:
When programming, one has an end state (“destination”) in mind
Writing a lot of one-off tests which check against possible problems (“guard rails”) does not actually help you achieve this end state
Achieving the end state is a result of examining what’s in between here and there, reasoning through the best route to take, and then taking it
Note that he does not say tests aren’t useful, just as he doesn’t say guard rails aren’t useful. He merely says that programming towards your goal by continually bumping against test failures is inferior to actually reasoning about the solution.
[…] programming towards your goal by continually bumping against test failures is inferior to actually reasoning about the solution.
Very eloquently put! (This post comes to mind.) I used TDD quite a bit, particularly earlier in my career, but the last few years I’ve favoured thinking and exploring first. TBH whether I do TDD now is a bit dependent on the culture of each language / project. If the project setup makes it easy to add tests first I will do that, but IDEs don’t work that way. (You can easily create code/interfaces first then generate a test skeleton in IDEA/Eclipse, but as far as I know you can’t write the tests first and generate code/interface for it.)
Writing a lot of one-off tests which check against possible problems (“guard rails”) does not actually help you achieve this end state
But that’s not what programming tests do, is it? IME tests tend to make assertions that we have got to a specific endpoint, not that we have not gone wrong in a particular way.
Hmm. This is why you need to “Thoughtfully add Provocative test cases in the order of "What I need to Handle Next”"
https://groups.yahoo.com/neo/groups/testdrivendevelopment/conversations/messages/35586
Oh yeah when a test fails I have to call AAA to tow my git repo out of the ditch. Then I have to phone up Mutual Insurance to see if they’ll cover it or if I’ve got to pay myself. And then I have to drive my repository into the shop so that they can buff out the dents.
Analogies are what people use when they don’t have actual arguments. I’m not sure there’s much to be gained from engaging with them.
I strongly disagree with this. Analogies are what people use when they want to communicate a concept quickly and effectively, regardless of whether they have “actual arguments” or not. Dismissing analogies as mere rhetoric is itself a form of rhetorical sleight of hand used to avoid engaging with the point being made.
Hickey’s point, as I understand it, is this:
Note that he does not say tests aren’t useful, just as he doesn’t say guard rails aren’t useful. He merely says that programming towards your goal by continually bumping against test failures is inferior to actually reasoning about the solution.
Very eloquently put! (This post comes to mind.) I used TDD quite a bit, particularly earlier in my career, but the last few years I’ve favoured thinking and exploring first. TBH whether I do TDD now is a bit dependent on the culture of each language / project. If the project setup makes it easy to add tests first I will do that, but IDEs don’t work that way. (You can easily create code/interfaces first then generate a test skeleton in IDEA/Eclipse, but as far as I know you can’t write the tests first and generate code/interface for it.)
But that’s not what programming tests do, is it? IME tests tend to make assertions that we have got to a specific endpoint, not that we have not gone wrong in a particular way.
Every time I see this analogy, I wonder if Hickey’s ever heard of trains.