2012-08-31
A realization about one bit of test-driven development
One of the standard pieces of instruction for TDD is that when you are about to do some coding you should not just write the tests before the code but you should also run the tests and see them fail before starting on the real code. You can find this cycle described in a lot of places; write test, run test, see the failure, write the code, run the test, see the test pass, feel good (monkey got a pellet, yay). Running tests that you knew were going to fail always struck me as stupidly robotic behavior, so even when I wrote tests before my code (eg, to try out my APIs) I skipped that step.
Recently I came to a realization about why this is actually a sensible thing to do (at least sometimes). The important thing about seeing your test fail first is it verifies that your code change is what made the test pass.
(This is partly a very basic check that your test is at least somewhat correct and partly a check on the code change itself.)
Sometimes this is a stupid thing to verify because it's already clear
and obvious. If you're adding a new doWhatever() method, one that
didn't exist before, and calling it from the test, then your code change
is clearly responsible for the test succeeding (at least in pretty much
any sane codebase; your mileage may vary if you have complex inheritance
trees or magic metaprogramming that catches undefined methods and so
on).
But not all changes are like that. Sometimes you're making a subtle change deep in the depths of existing code. This is where you most want to verify that the code is behaving as you expect even before you make your modification; in other words, that the tests you expect to fail and that should fail do indeed fail. Because if a test already passes even before your code change, you don't understand the existing code as well as you thought and it's not clear what your change actually does. Maybe it does nothing and is redundant; maybe it does something else entirely than what you thought (if you have good test coverage, it's at least nothing visibly damaging).
(Alternately, your test itself has a problem and isn't actually testing what you think it is.)
There's a spectrum between the two extremes, of course. I'm not sure where most of my code falls on it and I still don't like the robotic nature of routinely running tests that you expect to fail, but this realization has at least given me something to think about.
A small rant about looking down on Linux users
Sometimes, in some quarters, it is popular to say that the reason people use Linux is that they don't know any better. If they had been (properly) exposed to the magnificence of the *BSD of your choice, Solaris, or whatever, these Linux users would immediately understand and switch. If they were exposed to these Unixes and did not switch, it would clearly be because they had been damaged by their Linux experience and did not understand the true appeal of Unix; they were clearly too used to the gimmicks and glitz of Linux to really appreciate good stuff, and should perhaps migrate to Macs for even more glitz.
This is various sorts of hogwash. It is also startlingly arrogant, since it presumes that Linux and Linux distributions have no actual appealing elements to anyone with any brains and taste, and betrays an ironic lack of historical awareness given that the Lisp people raised pretty much the same indignant complaints against Unix way back when.
One of the ways that it is hogwash is that its premise is demonstrably wrong, and I'm an example of that. While why I use Linux is a complicated subject and I may or may not have taste, my continued use of Linux is definitely not through ignorance of the elegant Unix alternatives. Rather the contrary, in fact. I've used and worked deeply with plenty of versions of Unix over the years, and I still like Linux. Although I haven't tried to conduct an ethnographic survey, I'm pretty confidant that there are any number of old Unix hands who think that Linux is perfectly fine.
(A certain number of those old hands will look at you oddly if you get very worked up over which Unix you use. They're all Unix, after all. I'm not quite one of these, but a lot of that is because I'm a sysadmin so the fine details of how systems work and are administered do matter to me.)
(Of course and as always, if you ignore how real people actually behave in the real world you are ignoring the real problems. This is part of what happened to the Lisp people way back when and in my view they've never recovered from the resulting bitterness; it would be a shame to see the general Unix community go down the same road. And yes, saying 'people behave like this because they're ignorant' usually is ignoring how real people actually behave.)