| QUESTION & ANSWER |
Ajax testing: Using available tools is key |
 |
By Colleen Frye
03 Aug 2009 | SearchSoftwareQuality.com |
|
|
Ted Husted is a business analyst, author, consultant, and speaker. His books include JUnit in Action, Struts in Action, and Professional JSP Site Design. Husted will be speaking at the upcoming Ajax Experience 2009 in Boston in September, and one of his presentations will be on how to simplify and automate testing Ajax applications. He gives us a preview here.Some developers and tester feel Ajax is too complicated an environment. Do you agree or disagree?
Ted Husted: All programming environments are complicated. Ajax has its own flavor in that it's also a scripting language and very easy to change. It had been more difficult to program and debug in the past because it lacked the same tools that people had developed for Java, C# and other languages. Today with tools like Firebug and also the excellent debuggers that are now built into tools like Visual Studio and Eclipse, it's much easier to treat Ajax like a conventional language and apply all the same tried-and-true techniques.
The reason why Ajax seemed more complicated was just the lack of tools. Back in the day all we had was the alert box, but all that's changed now. While the Java/C# tools are still better, the Ajax tools are now as good as what we had with Java/C# say 5 years ago, just to throw a number out.
Are Ajax, JavaFX and Silver all either/or types of choices?
Ted Husted: There are a number of good tools. A lot of Ajax testing depends on what you're writing. If you're writing more of an Ajax toolkit for your use and other developers, tools like YUI Unit are very useful; if you're writing expressly in jQuery then QUnit is also very useful for testing your Ajax code internally. If you're more of a quality assurance person and you're testing the actual user interface of an application, then tools like Selenium are priceless. Selenium has been out for some time. It's got that perennial beta/Google disease in that they just won't cut a release, but the code is quite stable and a lot of people like myself have been using it successfully for years on all platforms. It's a Firefox plugin so it's very easy to install and use.
Also built into lot of browsers today, and including things that are deployed widely like Eclipse, JetBrains' IDEA and Visual Studio, are some excellent JavaScript debuggers. So you can go in and set up a breakpoint in JavaScript, in Ajax script, and watch it run. If you're in a Microsoft application and you're using both a code behind to talk to your database, and an Ajax front end, and going back and forth that way you can set two breakpoints, one in the front end and one in the back end and see it jump the gap from the UI to the back end.
That's one of the side benefits of doing more programming in JavaScript, because it does more strongly enforce the layers between the user interface and the back end. The MVC model-view-controller paradigm is very popular in Java circles and it keeps making inroads in Microsoft and C#. Right now a lot of Web applications still suffer from spaghetti code disease, in that a lot of UI code is mixed in with database access code and it makes debugging and testing much harder than it should be. But with Ajax development we're encouraged to have that strong separation, and having that separation is really a good thing.
Are there any particular hurdles to automating Ajax testing?
Ted Husted: Not with the right toolset. It's not perfect, but again, for automated testing Selenium is one of the better tools out there and one reason is because it has a proxy server, so you can write standard NUnit or JUunit tests with it, and in the middle of running your automated test suite, whether it's on a check-in basis or a daily basis, the browser can automatically come up server side and start running to your test. So running these automated tests isn't any different than running any other type of test. The hurdle is to get people to automate tests, because there's always a tendency to continue testing by hand no matter how many times you have to step through the same testing script. That's true in Ajax environments too.
What are some common mistakes when testing Ajax components?
Ted Husted: The most common mistake is we don't prepare our test scripts or our test avatars well enough. There's a tendency to throw out random or arbitrary data. Something we should really be doing from the get-go is coming up with testing scenarios that mirror real life. This is true for all kinds of testing. I resist the notion that testing an Ajax application with the proper tools is any different than testing any other application. If you try using the tools, you'll find out it's much easier to test an Ajax web application today than it was to test any kind of web application in '99.
Where we run into a lot of problems is the asynchronous nature of Ajax, so one of the more difficult aspects of testing Ajax which people sometimes forget is that an Ajax application will fire off a request and go merrily on its way. So if you're not careful how you conduct your tests you end up with false negatives or false positives because you didn't get the results back. Today the tools we have, like YUI Unit and Selenium, have capability built in to help us with that.
Click here for more information on the Ajax Experience 2009
|
|
|
|
