This post was written for the MuleSoft Blog by Dan Diephouse, software architect at MuleSoft, and has been reprinted with his permission.
Most people who write UIs don’t care about testing. You know why? Because it’s hard. So hard, they’d rather not even bother and test things manually. You have multiple browsers. You have multiple platforms. And worse, you have all these frameworks and toolkits which are difficult to test. I’ll pick on GWT here for a moment. It takes 20 seconds to start a test – let alone a server side component to interact with or the time it takes to run your test.
Testing as an afterthought doesn’t work for SaaS/PaaS offerings though. You’re deploying multiple times a week or even day. You need to be sure that you’re not breaking anything. And there is only one way to do this: tests! And I mean real, actual-in-the-browser-dealing-with-crazy-cross-browser-bugs tests.
There is only one real way to do this as far as I know: Selenium. And while it will work with any webapp, it shines when your UI is completely browser based. This is the approach we took with iON – there is no server side framework. It’s a rich Javascript, MVC(ish) UI made with Backbone.js and jQuery, and powered by a set of RESTful services. Having used many UI frameworks over the years this has to be by far my favorite UI setup and the easiest to test that I’ve worked with. And, it’s fast – I can run tests quicker than I can test things manually. This puts proper incentives in places to write tests.
We combine this setup with Sauce Labs support to run tests on their grid against our build server. There is no way I would’ve been able to get things QA’d and working in IE with such little time if I could not have used their infrastructure to do so. QA’ing manually simply takes too long and to set up this infrastructure ourselves would’ve taken forever.
(Sauce would like to mention that MuleSoft is looking for strong Web UI/JavaScript Engineers to hack on Selenium. If that sounds like fun to you, get in touch with them!)
