Tags: Java
This IBM Developer Works article,
In pursuit of code quality: Unit testing Ajax applications came up on my blog crawl today. Andrew Glover says "the emergence of Ajax has essentially invalidated a host of test frameworks and tools that weren't designed to test asynchronous Web applications" and goes on to discuss a methodology to creating unit tests for the GWT application framework.
The approach is to ignore "interaction testing", that is to ignore automation of the interactions with the GUI elements. Instead the approach suggested is to make sure the application is factored with a clean separation of GUI elements and "business logic", and then to test the business logic that's called from the GUI elements.
A similar approach can be taken with any GUI application toolkit. As Andrew says in the article, this is a good approach to building applications in the first place, and it is a recommended best practice to cleanly separate business logic from the UI elements. Doing so makes it easier to refactor the GUI application as your user experience team refines the interactionality of the application.
Testing GUI's at the UI layer can be done, though it requires specialized tools. For example GWT is written with Java language syntax, and one might think one of the Java GUI test tools might do the trick. However those tools only work with Java GUI's, and in GWT the application is compiled to Javascript and executed in the web browser, and the java.awt.Robot class does not exist in the web browser. To automate web browser tests usually test engineers turn to the commercial tools (Silk, WinRunner, etc) and while these will do the job there are a couple issues. First, those tools only exist for Windows so if you want to test the user experience on other platforms (e.g. OS X is gaining in popularity) you're out of luck. Second, the core issue in testing GUI interaction is what happens when the GUI changes? The tests all have to be rewritten to accommodate the GUI change.
This second issue, GUI changes that invalidate tests, is something which strongly encourages the recommendation of cleanly separating UI from business logic. One could refactor the GUI all you want, and so long as the business logic doesn't refactor the tests wouldn't change. And, it's clear that in certain parts of the application development process the user experience people must be able to quickly refactor the GUI, try out new ideas, and make refinement after refinement.
I've been helping the Java SE SQE team with test automation for several years now, and one thing I've learned is that the return-on-investment of a test is better the longer you can reuse that test without having to rewrite it. If your test is coded to relatively unchanging interfaces or system attributes it should be reusable for years and years giving great ROI.
Getting back to the question of testing AJAX applications... I think there's approximately four levels to test:
- The server end which provides the datasourcing used by the AJAX app
- The protocol(s) between the AJAX app(s) and the back end(s)
- The business logic inside each of the AJAX app(s)
- The GUI of the AJAX app(s)
A similar separation of layers could be made for other over-the-network applications, it's just that AJAX application construction techniques present some interesting challenges. While one could automate testing the first two pretty readily, it's an interesting question whether the 'J' part of the AJAX app works correctly. Javascript implementations apparently vary so much in behavior that it's difficult to have them work correctly across web browsers. Testing in every web browser combination you can afford to test is vital, due to these variances.
But this leaves us with a problem. It leaves out testing one of the application layers. How are you going to validate that the GUI behaves properly? If you don't automate GUI tests, that leaves you with manual GUI testing. As I said earlier the tools for editing GUI interaction with a web browser, they're all commercial testing tools, and they only exist for Windows. If someone knows different please let me know. What this means is there's a likelihood the GUI application will be better tested on Windows than on the other platforms, because the these commercial tools can automate tests there.
Source:
weblogs.java.net
