Photo from Chile

My Interview on WebDevRadio

I had the honour and pleasure of being interviewed by Michael Kimsal for his WebDevRadio podcast a few weeks ago. The episode was published last week and is now available for listening and/or downloading from the podcast website, as well as via iTunes.

For those of you that don't know Michael, you're missing out. I met him at NCDevCon and found him to be an extremely pleasant, funny and smart individual. I enjoyed my chats with him at the conference, and really enjoyed discussing all sorts of topics with him for the podcast, including, but not limited to, how I came to develop using ColdFusion, contributing to open source projects, test-driven development and unit testing in general, and object-relational mapping (ORM) in ColdFusion. I also really appreciated the opportunity to have my voice heard outside of the ColdFusion community.

Checking for JavaScript Errors with Selenium

I've recently been writing some end-to-end tests for ValidateThis, my validation framework for ColdFusion objects, using Selenium. One of the things I wanted to test were the client-side validations that the framework generates automatically. Selenium makes it very easy to test these, as I can use Selenium's assertText command to locate failure messages that have been generated by the jQuery Validation plugin, using XPath, and check whether the message is what I expected.

I found, however, that I was often getting JavaScript errors when the page first loaded (because I was working on the JS and was introducing errors), so I was looking for a quick way to add an assert to my test to check whether any JS errors occurred. After some Googling I came to the conclusion that there is nothing built into Selenium to support this, but there are a number of hacks that can be used to accomplish it. I'm going to describe one of them here. Let me state again, for the record, that this is pretty hacky. I'd love to hear from others who may have better solutions.

I simply add a script to my page that will catch any JS errors by intercepting the window.onerror event:

view plain print about
1<script type="text/javascript">
2    window.onerror=function(msg){
3        $("body").attr("JSError",msg);
4    }

This will cause an attribute called JSError with a value corresponding to the JavaScript error message to be added to the body tag of my document if a JavaScript error occurs. Note that I'm using jQuery to do this, so this specific example won't work if jQuery fails to load. Then, in my Selenium test, I just use the command assertElementNotPresent with a target of //body[@JSError]. Now, if any JavaScript errors occur on the page my test will fail and I'll know I have to address them first. If, for some strange reason, I want to check for a particular JavaScript error, I could use the assertElementPresent command with a target of //body[@JSError='the error message'].

Note that I'm using this with a test fixture page, it's not an actual page that is part of an application. I'm not sure that this would be very useful in an automated testing environment, I'm just using it for some TDDing, where I want to write an end-to-end acceptance test first, and then write my unit tests. Getting the test to fail because of a JavaScript error is a nice way, imo, of satisfying the criteria that I must have a failing test before writing code to make it work. The usefullness of this technique in terms of pure testing is questionable, but I find it useful for my purposes, so I thought I'd put it out there for others.

Some Benefits of Unit Testing

I must start by saying that, as much as I like option groups, I love Unit Testing. I had written previously that I Like Unit Testing, but that brief infatuation has blossomed into a full blown love affair. I have two people/groups to thank for that, Paul Marcotte and the MXUnit Team, who produce an excellent suite of unit testing tools for ColdFusion.

I met with Paul in the Toronto airport a couple of weeks ago during a brief stopover (his, not mine) and he walked me through his current methodology for unit testing. He really cleared up some areas of confusion for me, and essentially handed over a set of practices that makes everything oh so easy. He's been blogging about his technique in a series that I heartily recommend.

And what can I say about MXUnit that hasn't already been said? It totally rocks! The Eclipse Plugin is da bomb! If you haven't checked it out, do so. Now. 'Nuff said.

So when do I get to hear about "Some Benefits of Unit Testing", you may be asking? Read on.


I Like Unit Testing

I never imagined that I'd say those words, but they're true. I must start by admitting that I wrote my first unit test a few days ago. I know, I'm bad, I should have been doing this for years. I've known about unit testing for a long time, I've been reading more and more about it, and listening to speakers at conferences extol its virtues. But somehow I just couldn't get my a$$ in gear. It just seemed like too much extra work. And as a sole developer working on relatively small projects I was able to get away with not doing it.

Anyway, I read a blog post a few days ago that inspired me to take the plunge. The post describes unit testing with CFUnit, but I'd been hearing a lot of good things about MXUnit, so I decided to give that a try.