Dimecasts is a site created and run by fellow Chicago Alt.Net group ‘founder by which we mean we were in the bar when we decided to do it’ Derik Whittaker that hosts a decent number of relatively short webcasts on topics that Alt.Net type people might be interested in. They are supposed to be all under 10 minutes, but as I like to heckle Derik about, it’s usually 11 minutes up to about 15 minutes. No matter, really, but heckling is fun and cheap.
Anyway, Episode #65 is a ‘demo’ of sorts of both TDD and Pair Programming, as Derik and Kyle Baley begin to implement a basic new feature for the Dimecast site, one which will email the author of a Dimecast episode any comments that are added to it (the site already allows comments). So, pretty basic stuff. Kyle (whom I have exchanged email with on occasion but don’t know anywhere near as much as I do Derik) is remote, so there is lag and some static in the webcast, blah blah blah, but the production values aren’t really important, as the two are able to do what they want to do, and it is easy to follow. And taking 15 minutes to test out a design for a feature seems like a decent amount of time to do it, so no worries there.
Having said that, watching this webcast, it worries me that any competent developer who might see this will reject TDD out of hand.
To put in a few caveats/disclaimers about what I *don’t* mean by this:
- as my own hobo-like presentation at the Chicago Alt.Net group will attest to, I embrace the idea of programming to interfaces, so the fact that there are four interfaces in the design doesn’t bother me.
- while I personally don’t have a love affair with the underscore naming convention, I understand how the sorts of reports that can be generated off of them can be much easier to understand in various situations, so that’s cool.
- rap master douchebag hasn’t issued any ultimatums about this episode, so I assume it is at least a reasonable presentation of TDD in this space.
Having said all that, there are obvious problems here. The piece of functionality under test is that an email is sent to the author of an episode if someone comments. As designed, the test requires *8* vars to do so. Each ‘var’ is a place for possible error and often requires a proper understanding of the mock framework. That’s a hell of a lot of code required to test a single assert. Imagine if the requirement was actually difficult. Related to this, the code in the test has basically no semblance to the code that will actually perform the functionality as required in the *real* code (which hasn’t been written yet, but will be in the next episode, numbered whatever).
From a philosophical standpoint, <insert gratuitous comment>I have multiple degrees in Philosophy, the core of which involves logic</insert gratuitous comment>, TDD makes a lot of sense. What is my code supposed to do, and what is its API supposed to be? Great. But, maybe it is the syntax, maybe it is the process, but the fact of the matter is, if I really want to know if an email is sent when a comment is added, I can write 10x less code and just run an integration test. “OOOO, integration tests are slow!!!!!!”. Sure (though I immediately want to ask, compared to what, and what’s your confidence that your 74 vars in your test code actually test what will happen in production??), but slow is better than inaccurate.
It is easy to get addicted to the fast results of unit tests. If you’ve ever had to switch between them and long-running integration-style tests, it is *painful*. Extremely so. But integration-style tests, when done properly, test your real code, not some ‘hopefully accurate’ code.