I recently found this interesting article about UI test automation. I agree with most points mentioned there.
By definition the only thing that cannot be tested any other way than via UI is the UI itself - in a typical web application this means mainly JavaScript. However the good thing with JavaScript is that usually there are not many dependencies between different pages. If you change one page then JavaScript on it may break but at least it's not likely going to cause bugs on some other totally unexpected places.
For example in recent Grails project we stopped writing UI tests because they just needed to be updated too often and Grails offers very nice integration testing tools where you can easily test your whole system using MVC controllers as the API. In such small 9-man month project we just were not able to stabilize the UI soon enough to make UI test automation beneficial. On the other hand if the project is longer or there just is no API layer suitable for testing then UI tests may be the only way for automating integration tests.
Comments (3)
Jan 18
Anonymous says:
I'm not sure what you were using for automated UI tests, but you might want to c...I'm not sure what you were using for automated UI tests, but you might want to check out http://seleniumhq.org/, you can rapidly update UI tests using selenium IDE, I have found it to be a pretty good solution for UI tests. Designing the UI end to end before implementing it fully in grails / javascript etc so that you only end up messing with the wiring behind the UI means that your tests remain fairly static.
Failing the above, there's always the amazon turk style option, I believe there's a few low cost startups that provide full testing at fairly reasonable rates.
Jan 20
Ürgo Ringo says:
We were using Canoo Webtest which turned out to have quite many problems with AJ...We were using Canoo Webtest which turned out to have quite many problems with AJAX support so were had to use many workarounds to get it working in some cases. What kinds of UIs are you testing? Does it contain many dynamic widgets or is it more static?
In our case we had some pages with fairly complex AJAX calls so that depending on user actions many different asynchronous calls were made. We found that maintaining such tests took us quite a lot of effort since we were developing the whole application in an incremental style. I guess if the UI is more fixed then probably having UI tests from the beginning is more cost effective.
Jan 25
Anonymous says:
The critical difference between Canoo and something like Selenium is that Canoo ...The critical difference between Canoo and something like Selenium is that Canoo executes tests from the perspective of invoking application calls programmatically, whilst selenium RC simply controls a browser proper, remotely. So if you can do something with a browser, you can fairly quickly put together a test using selenium IDE (which actually just records your interactions with the UI) and play it back. Later, you can use this script created in Selenium IDE to drive selenium RC automated tests on the application. Selenium drives the browser, so if it can be done with a browser it can be tested in Selenium (which makes it ideal for testing arbitrarily complex AJAX interfaces)
Add Comment