I’m working on a legacy code base, with all that entails, but that hasn’t stopped me in the past. So why am I not writing as many tests this time? For that matter, is it possible that it’s correct for me to not be writing so many tests?
There is, I think, a good reason for some of this. A lot of what I’m doing is arranging graphical elements so they look good on screen. And tests wouldn’t help with that: they’re great for getting logic right, but with presentation, all they’d do is pin down unimportant details. So if I later decide that a margin should be seven pixels wide instead of five, having a test would be pure overhead. (Incidentally, placing images properly is another thing that I’m surprised how much I enjoy—I really like participating in a process that leads to a much better-looking page, even though the art team is doing most of the hard work.)
So I wrote a few JsTestDriver tests as a proof of concept. At which point I ran into my first roadblock: without trying to do anything tricky, the first four tests that I wrote all failed in Internet Explorer! Which was useful information—I learned that querying CSS properties is not likely to give the results I expect in IE—but the functionality in question actually worked fine in IE, I was doing the querying to check results in tests, not as part of the product code.
The good news: I could, indeed, get into a TDD rhythm. Looking at the code right now, I have 374 lines of product code and 294 lines of test code; that amount of test code looks a little small (or, actually, given what the animation does, that amount of product code looks a little high…), but it’s not a ridiculously low proportion of test code.
Indifferent news: I’m still not sure that all the tests are really getting at the core of what I’m doing. A fair amount of the thought in the programming exercise involved fiddling with CSS classes and creating HTML elements to give the illusion that you have a single box that is stacked up, then moving, then entering the stack again, while behind the scenes there are actually two HTML elements involved. (One positioned in the normal document flow, one positioned absolutely.) And the tests for that part of the code have too little to do with the desired visual effect and too much to do with implementation details. (Though not my all unit tests involving animations were bad: e.g. the unit tests for the movement of the element once I’d lifted it out of the normal document flow were perfectly reasonable.)
I typically was running my tests in both Safari and Firefox. And, on more than one occasion, a test would just fail repeatedly in one of the browsers, for no apparent reason. The first couple of times this happened, I would curse the lack of cross-browser compatibility, check that the product code behaved as I expected, and reluctantly proceed. But then I noticed that, if I actually killed the browser where the tests were passing and restarted it, then the tests would start working again! So it seems to be the case that it’s rather difficult for JsTestDriver to completely wipe out its state from test run to test run. (I’m not sure if I tested just closing the window where JsTestDriver was running instead of exiting the browser completely; so maybe unit test frameworks where you have to manually reload a page in every browser each run wouldn’t suffer from this problem.)
- October 1, 2011 @ 14:13:49 [Current Revision] by David Carlton
- June 5, 2010 @ 21:03:09 by David Carlton