Guess it does comes down to the type of site we’re building. Agreed, JavaScript events are a beast to test since they have the most disparity across browsers, which makes web development so “special” :P I understand what you mean by the code smell… It would be good to acknowledge those developing larger sites geared up for a rich user experience, however.

So there’s a couple of things to take away from this…

1) Testing the browser event layer is tricky – Selenium is recommended for testing the JavaScript event layer across all browsers, to establish consistent behaviour.
2) Applying Unit testing is dependent upon the complexity of your site. If your site is geared up to be a web application, then Unit testing is viable for your library and API code.

PS: I’m interested in knowing more about the issues with Prototype’s test suite, might be helpful for the points raised here.

Your right – Selenium is an acceptance testing tool which is meant for full stack testing of a web application but what I was saying is that it can also be used for testing of JavaScript elements of an application in isolation and I’ve found testing with it to allow much more coverage than unit testing because DOM scripting essentially is a behavior layer so simulating events is the only way to test this whether your code is modular or not. After all, the essence of browser JavaScript is handling events and showing some kind of feedback – exactly what selenium gives us the facility to test. Browser JavaScript is really difficult to unit test effectively. For example, you may assert in a unit test that after running a certain method a DOM element has a certain property set but can you ever rely on that meaning that it’s actually doing what you need it to do in all browsers? Selenium allows you to pick up on this stuff along with all kinds of other things like how you app response to keyboard controls etc. It tests you code in the actual context that it’s running in rather than the isolation of unit tests.

There are cases when you can (and should) unit test parts of browser JavaScript (such as string methods etc in libraries) and, yes, you could test a fair bit of library code using JSUnit but not any of the event stuff. This leaves you with a pretty crippled test suite – a problem which Prototype’s test suite has had. I guess there is a case when testing something like a library that you might want to use both JSUnit and Selenium but, as I said during questions, the way I build browser applications is that JavaScript is a dumb waiter to the server so there’s I’m hardly ever left with any unit testable logic at all (given that the library Im using is suitably unit tested). Everything is the response to an event. If I find that there’s complex logic within my behavior layer that feels like it should be unit tested it does feel like a code smell. Sometimes it is necessary of course, but for me its definitely a sign I might have designed my app wrongly.

Here is a link to one such resource to learn how to program those widgets.

Just a thought.