views:

532

answers:

5

I'm setting up some Selenium tests for an internal web app and looking for advice on a testing 'best practice'. One of the tests is going to add some data via the UI that cannot be removed via the UI (e.g., you can add a record via the web app, but removing requires contacting someone internally to remove it at the database level). How do you typically account for cleaning up data after the Selenium test is run?

The app in question is written in PHP and I'm using PHP for testing (with Selenium RC and SimpleTest), but I'm open to other tools, etc. as this is just a broad best practice question. The app being tested is in our development environment, so I'm not particularly worried about data carrying over from tests.

Some ideas:

  1. Manually connect to the database in the Selenium test to cleanup the data
  2. Use something like DBUnit to manage this?
  3. Just add data and don't worry about cleaning it up (aka, the lazy approach)

Thanks!

Edit: Seems most of the ideas centered around the same conclusion: work off a known set of data and restore when the tests are finished. The mechanism for this probably will vary depending on language, amount of data, etc. but this looks like it should work for my needs.

+2  A: 

We have a web front end to a database restore routine. First thing our tests do is restore a "well known" starting point.

+2  A: 

I use Selenium with a Rails application, and I use the fixture mechanism to load and unload data from the test database. It's similar to the DbUnit approach, though I don't unload and reload between tests due to the volume of data. (This is something I'm working on, though.)

Sarah Mei
A: 

Point the webapp to a different database instance that you can wipe when you are done with the tests. Then you will have the database to inspect after the tests have run if you need to debug, and you can just blow away all the tables when you are done. You could get an export of the current database and restore it into your fresh instance before the tests if you need seed data.

digitaljoel
A: 

Avoid the lazy approach. It's no good and will ultimately fail you. See my previous response on this topic in this separate StackOverflow question.

Patrick Lightbody
A: 

Agree with the other answers here. I've wired in Selenium and DBUnit tests to the past 3 projects I've worked on. On the first project we tried the lazy approach, but predictably it fell in a heap, so we used DBUnit and I've not looked back.

I realize you are using PHP, so please translate DBUnit/JUnit to your PHP equivalents.

A couple of points:

  • Use as little data as possible. With many selenium tests running, you want the DBUnit load to be as quick as possible. So try to minimize the amount of data you are loading.
  • Only load the data that changes. Often you can skip tables which are never changed by the web app. Ref data tables and so on. However you might want to create a seperate DBUnit xml file/db backup to load this data in case you accidentally lose it.
  • Let the JUnit selenium tests choose whether they need a reload. Some Selenium tests will not change any data, so there is no point reloading the database after they run. In each of my selenium tests I override/implement a method to return the desired DBUnit behavior.

    @Override protected DBUnitRunConfig getDBUnitRunConfig() {

    return DBUnitRunConfig.RUN_ONCE_FOR_THIS_TEST_CASE;
    

    }

(Couldn't get that snippet to format correctly.) Where DBUnitRunConfig is:

public enum DBUnitRunConfig {
    NONE, 
    RUN_IF_NOT_YET_RUN_IN_ANY_TEST_CASE, 
    RUN_ONCE_FOR_THIS_TEST_CASE, 
    RUN_FOR_EACH_TEST_IN_TEST_CASE
};

This cuts down the time required to get through the tests. The Selenium enabled super class (or helper class) can then run, or not run, DBUnit for the given tests.