Are aUnit frameworks on the horizon?
Something that’s been rolling around in the back of my mind for some time is the term aUnit Framework. A lot of developers are familiar with xUnit family, as least by name if nothing else. If not, I highly recommend reading Martin Fowler’s xUnit history writeup. “aUnit” is not the greatest title, but neither was Microsoft Bob if you ask me.
I say it’s a poor choice of names because I’m not talking about unit-tests in the traditional sense. The web development community needs a well-designed tool crafted around the constructs that the modern-day web is fashioned from. Selenium is quite powerful, but my experience has been that it’s a royal pain to make any but the simplest tests tolerant of response delays with Ajax calls. In the pure Unit Testing world, YUI Test and my personal favorite, QUnit are excellent for running suites against strictly client-side code, and are capable of wrapping tests around Ajax calls, but there isn’t a clean way to tie those into any kind of continuous integration build.
Looking around StackOverflow and the various feeds I subscribe to from other developers, I see a huge desire for something that just works without an undue amount of pain and suffering.
Boredom-Driven Development
I mentioned in a previous post that the Ajax Experience conference crowd showed a great interest in automated testing. During one of the testing sessions, I posted a thought that got retweeted several times:
After the conference, I spent some time looking at what the various frameworks had as for testing hooks built in. While I don’t have working experience with Rails, I was familiar with it’s console and some of the clever ways it lets you peek into your application to see how things are working (or not working) together. I was curious if Django had something similar, although I got sidetracked watching Django in the Real World from Django-Con 2009 before I got too far. There’s actually quite a few good quotes throughout the presentation, but this one from Kent Beck’s Test Driven Development: By Example stood out:
Tests are the Programmer’s stone, transmuting fear into boredom.
Too often, those of us in the maintenance section of the software life cycle are paralyzed by fear when we come across a problem. Can I fix this without breaking other things? Does anything in my application depend on this broken implementation? We shouldn’t have to ask these questions, and automated tests give us the confidence to make those necessary changes without the element of fear. You want that level of boredom.
Having to agonize over what should have been a simple bug fix is not a fun process. Test-driven development has caught a bad wrap from some who argue that TDD imposes unrealistic principles in real-world development. I disagree with that stance on the basis that most of Beck’s work that I’ve read has argued for practical rather than fanatical testing. If you can get to 100% code coverage, great, but do you really need to test your getter/setter methods? Probably not.