- Runs on Ruby Selenium-Client 1.2.17, and Selenium-Grid 1.0.4 with Selenium RC 1.0.3
- Rake Multi-Processing Tests to speed execution of tests utilizing Selenium-Grid
- Element Level Classes that eliminates the use of adding sleeps to tests/specs, multi-window support, and elements that work with ExtJs, JQuery, GWT objects.
- Modified Aggregate Report generator that displays number of specs run, examples runs, and Total and Cumulative Test Times.
- Main Objective – Team Involvement (again all levels of experience in Development/QA Environment to assist in test creation)
- Tests suitable for Agile environment w/ ability to be executed through a CI Server
I have released my first version of selenium-rspec-dsl on RubyGems.org and on GitHub. It that makes selenium testing easier to create, maintainable, and scalable.
Coming Soon – Documentation on how to use DSL.
A year ago, I was put to the task, with the help of Joe Ocampo (fellow los techie) to have automated UI tests that everyone in a Development/QA environment (all levels of experience) can help with. We wanted to have a framework/DSL that had the following objectives:
Based on prior experience using commercial UI automated tools, some of these principles we based on flaws of those tools, so we wanted to go the open source route, and the obvious choice was selenium. At the time I had some experience writing selenium tests in python, plus I did create a selenium multi-thread runner in python by simply modifying unit-test library in python to accept threads. I was committed to using selenium just for solving the scalable objective (by utilizing selenium-grid). This still didn’t solve the main objective of having Team Involvement. This is were Joe had the vision of having me look into using of Rspec. With the combination of Selenium and Rspec, we were able to solve all the objectives.
With Rspec, manual testers could now participate in writing specs (which could replace the need to writing manual tests, because it is the manual test)
Manual testers could still write tests as you would in any manual testing tool (Action – Expected Result)
Example of pending spec (Manual test):
Using the power of Rspec; testers can easily write tests in this format. Once a spec has been written, trained QA testers will then ‘fill in’ the
test with automation test. This gives QA a more agile approach as far as keep the manual and
automation test together in one file. The spec gives QA the opportunity to run the automated tests manually if
Example of automated spec:
With the framework/DSL created and using Rspec assertions, it even allows the automation code to be easily read and reduces the need to know selenium api commands. Selenium and Rspec have their own Selenium Test Formatter that will print out beautiful reports, that can be read by anyone in the
business, print screenshots, and capture selenium server logs in event of test
Example of passing test:
Specs will be written in a QA test repository (centralized), which will allow the reuse of code from other projects or applications automated. (Object-Oriented Approach) objects and element classes will be
centralized and only maintained in one place, to make updates easier to
Example of object classes:
Utilizing Selenium Grid and multiple Selenium Servers, specs can be run on
multiple threads to decrease the amount of time to run the spec.
Tests suitable for Agile environment w/ ability to be executed through a
Using this format manual specs can be written before development begins and automation can be filled in during and/or completion of development. Writing Rake tasks to execute tests and using Hudson CI Server, selenium-grid plugin, and rake plugin, tests can easlly run and tracked.
More to come!
subscribe via RSS