We have a considerable code base with relatively high test coverage for pages/forms, all via vanilla POST/GET.
Now, we are find ourselves moving more into the ‘ajaxy’ space, and it’s not quite possible to test with GET/POST complete scenarios like user registration, or an item creation, as they involve lots of JavaScript/Ajax calls.
While things like that are the most likely candidates for testing with Selenium, I wonder should we adopt the Selenium testing across the board, leaving the old-school POST/GET tests altogether?
Advantages of Selenium adoption seems to be too good – ability to run pretty much same GET/POST tests but across the range of browsers.
Or am I missing something in my pursuit of cool and trendy stuff and ditching the old proven POST/GET tests?
There’s advantages and disadvantages of both approaches, so my recommendation would be to use both.
Selenium launches an actual browser and simulates a user interacting with your web application, which can be great if you’re testing Ajax features. It can verify that elements are visible and interact with them just as a user would. Another killer feature is the ability to take screenshots through Selenium, which can be incredibly useful when investigating failures.
Unfortunately launching a browser and navigating to a specific page/state in your application can be slow, and you’d need a lot of hardware if you wanted to test concurrent users (load testing) with Selenium.
If you just want to test that your server responds with a HTTP 200 for certain actions, or load test your applications, or that the response contains certain values then basic POST/GET would be more suitable.
If you do decide to go with a pure Selenium approach to testing I would recommend looking into using Selenium Grid or a cloud based service, as running lots of tests through Selenium can be quite time consuming.