Quality Assurance at Openbravo

July 16, 2010

Using Selenium with DBUnit

Filed under: openbravo — obqateam @ 9:09 am

We were working using Selenium for several years now, and our experience is great. Selenium is flexible, powerful and easy to learn.

We have the Smoke Test running as a required step for code promotion in Continuous Integration release cycle.

However, we are looking for moving the Selenium tests earlier in the ERP’s development cycle. Here we face one of the biggest drawbacks of our tests: They were developed thinking in a full execution starting from scratch.

That is, test cases depend of successful run of previous test cases in order to execute. A first snapshot of these dependencies appeared when we worked in parallel execution .

Now the following scenario. I am a developer and I made a fix that could cause some instability in Production module. I should not make the commit and wait CI’s email about the result, not to say waiting for QA’s standard testing cycle, nor a customer after the fix was included in some release.

Release Management team has done a very cool feature, named “Try” and we would like to add something else. Instead of executing an “all-purpose” test, we look for specifics suites.

So, in the example, even if we know that only Production module could be affected by the change, current available test would only allow a full run. Could the Production Smoke suite be executed separately? Well, yes. We added some extra capabilities to our suites by combining standard Selenium scripts with DBUnit scripts. The concept is quite simple, as explained in the DBunit’s web page:

DBUnit is a JUnit extension targeted at database-driven projects that, among other things, puts your database into a known state between test runs.

A DBUnit script will be executed before launching the Selenium script, and it will do the required changes in order to fulfill the Selenium script preconditions. Then, the test case is executed as usual.

DBunit data is created using XML files containing the rows that will be used by the next script. This has a complicated issue. The DBUnit part should be created in a safe way, meaning no interferences with current data are allowed. So static XML files were not enough. We created tags where dynamic data was required and then made that dynamic data parameters so we could use them as part of the next tests.

The result of this work can be seen at pi-dbunit branch . Currently, there is only an small set of tests available, and that is because generating the XML files is a hard task, requiring deep knowledge of Openbravo’s DB structure, table names, triggers and constraints.

Our goal is to have a full set of tests for every major module in the ERP, making easier to make specific testing in a very fast way.

Just for info: A full DBUnit+Selenium execution in Production suite could take ten to fifteen minutes. Currently, it takes ten minutes… but you have to execute one hour of tests before getting there.



  1. […] we said in previous posts our expertise in Selenium is increasing rapidly. We are currently able to perform several types of […]

    Pingback by Openbravo ERP 3.0: Easier than I thought « Quality Assurance at Openbravo — October 20, 2010 @ 10:21 pm

  2. […] we said in previous posts our expertise in Selenium is increasing rapidly. We are currently able to perform several types of […]

    Pingback by Openbravo ERP 3.0: Easier than I thought | myErp — October 21, 2010 @ 11:22 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: