A lot of people know that I’ve been working with Selenium to automate UI tests. You can now see a few examples of how specifically we use Selenium at Google, via the publicly released Selenium-based tests used as part of the Maps API testing process.
When you’re developing a Web-based application, testing a Web UI can get quite time-consuming. Throw in the problem of having to support multiple browsers, and the complexity of AJAX, and things can get out of hand quite quickly. This is where having an automated set of UI tests can be a life-saver. Make these tests part of your CI process, and you’ll get feedback as soon as something is broken.
Often, people end up testing the UI as part of an end-to-end test. This isn’t necessarily the best way to be testing the UI, as you’re no longer able to pinpoint the location of problems to a particular layer. Is that problem you’re seeing a data-encoding issue of the HTTP request/response, the database, or the persistence API? It could be anywhere. So take advantage of that multi-tiered system design which you have. Test each layer in isolation, separate it from the other layers that it’s talking to by putting fake, mock or stub layers in place, and test that layer by pumping in events and calling methods. Check the calls appearing out of that layer to verify they’re what you expect, and you have a much more useful set of tests.