Introduction to Xebium
When testing web interfaces, it’s convenient to use an intuitive tool like Selenium IDE, it’s easy to use and can be used by non-technical people, but it is solely meant for record and playback of test-scripts. One of its limitations is that it misses sufficient options for documenting and managing tests. Furthermore it misses an interface with the backend of the system under test (SUT), to setup preconditions for a test or for instance to manipulate or read from a database.
Fitnesse is a great tool to do just that, it has the Wiki to manage tests and it by default has a setup and teardown mechanism, it’s easy to add non invasive testfixtures to interface directly with your SUT. The downside is that it is incapable of doing webtests.
We now have the glue that combines the two, it’s called Xebium!
On several projects I’ve tried to find a way to combine the two, because both tools are free of use and both have their individual charm, but it seems combined they would master practically any situation. As a tester I miss the development skills to come up with a satisfying solution and I never convinced my team members to help me out in a satisfactory manner.
At our company we recently started app-incubator, a new form of knowledge exchange, in the form of mini projects, anyone can pitch a project idea and when enough colleagues sponsor the project, we can spend up to three days collaborating on it. My pitch caught fire and with about five people we brainstormed on the solution. For me a prerequisite was that it should be possible to use the test scripts two directional, so record them with Selenium IDE, run and edit them in Fitnesse and playback from Selenium IDE again. During this first project session we came up with additional requirements, it should support data-driven testing and variable substitution. We wanted to keep it as simple as possible, no new DSL’s should be introduced and it should not require conversions between the two products. We explored some existing solutions such as Fitnium and Selenesse but came to the conclusion these (at the time) were fully based on their own DSL’s and did not support exchanging files between Selenium IDE and Fitnesse. So we decided to created something far more simple.
After several attempts we discovered that Webdriver (Selenium 2.0) would be the best engine for running our tests. It seems more future proof, turned out to be a lot more stable than Selenium Testrunner and its commands are more compatible with Selenium IDE than Selenium RC.
We introduced a Selenium IDE formatter which output can be directly copied into the Wiki. We created a Fitnesse fixture that is capable of running the pre-formatted scripts without additional interpretations of the Selenium commands.
The additional features we had in mind, the data-driven testing and variable substitution turned out to be standard Fitnesse features. What we did not realize when we started was that Fitnesse would introduce a mechanism which, in my opinion, added mind-blowing power to project: Scenario tables, which now enables us to create abstractions on top of our testscripts.
Xebium enables us to use both Selenium IDE (low learning curve) and FitNesse (ease of maintenance) to it’s fullest and provides a complete solution when it comes to automated web testing.