Some developers and tester feel Ajax is too complicated an environment. Do you agree or disagree? All programming...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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?
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.
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?
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