This edition of TTF revolves around Selenium. Not the element, but the test tool for web applications. Selenium allows you to do automate web GUI tests. Before I go on about the details of Selenium and why I use it I first want to touch on subject of automating web GUI tests.
First, while tools like Selenium are getting better and better all the time, I make no illusions that you will be able to automate all of your web GUI tests and walk away and have them run over and over again. If you are a manager and reading this you need to remember that automation is not a silver bullet to solve all of your problems. Automated testing just doesn't work that way, especially on a product that is constantly changing. The problem with automated tests in general is that they require care and feeding (contant updates) as the application changes. Don't get me wrong, I think automation is a good thing and that you should automate as much as possible, but at the same time know when you've automated enough. And when you set out to automate a web application I recommend first focusing on automating against the API because that is a lot less likely to change than the layout of the GUI. So you'll get more bang for your buck there. Then focus on automating the main functional paths through the GUI and then branch off into the less likely occurences from there as time and resources allow. And lastly, even if you've automated nearly all the web GUI functionality, you still want to have a human take a look and run through at least some tests every few days. You would be amazed at how many things a person can catch that would never be caught by automated tests. OK, moving on to Selenium...
I use Selenium for a few reasons. They are:
1. It is open source and doesn't suck as much as other GUI automation tools that I've used.
2. I can use Selenium RC to run against all the browsers that my product (OYE) supports.
3. You can write the automated scripts in java, c#, perl, php, phython, or ruby. and Selenium RC can play them all back.
4. You can easily plug it in to other test infrastructure to have it run on a regular basis.
Where Selenium fits in for me:
On my project we plug it into Jameleon which is then can be kicked off via ant scripts. Right now we don't use it as part of CruiseControl or BuildForge, but it can easily be plugged into those frameworks and run every time we get a build. And the way we do our Selenium tests is that we write a "tag" in java that performs each function (login, logout, add web crawl, etc...) and then each test case (xml file run via Jameleon) is basically just a collection of tags put together in different orders. One way to think about it is that each "tag" is a lego block, and each test case is a lego castle or boat or whatever. That way when things change in the GUI (login, logout, navigation, etc...) all we have to do is update the tags and not actually update the test cases. Another benefit of this division is that you can have less technical personell write the test cases in xml and have the more technical ones write the tags (in the language of your choice). In our case I'm the one that does both for GUI automation.
So if you are interested in automating your web GUI tests I highly recommend checking out Selenium. You don't have to get complicated like I have on my project. You can use the Selenium IDE to record and play back your tests, but this method is brittle and will easily break if anything in the GUI changes.
Posted by troutm8 at October 12, 2007 04:38 PM