Database Reset in Automated Testing

By mark

At TIST conference, after my demonstration, on tester asked me "We saw you running the same test (changing password) twice, before and after refactoring, how could it work second time? The data has been changed from first run.". The answer was database reset, ie. the database is reset to the known state before running each test. As I have been doing this for a number of years now, it almost become second nature to me in terms of automated testing. To make the concept of database reset easy to remember, I call it "The Simpsons Pattern".

Benefits of database reset is so important that you probably will appreciate only after experience it. Once I asked a business analyst to rate his view of importance on database reset in scale of 1 - 10. He answered "9.... No, 10".

  • Develop tests without worrying of data changes caused by tests, what a feeling!
  • Faster test execution. Use seeded data records instead of creating data from scratch every time.
  • Always know data record states, great even for manual inspections of applications.
My typical RWebSpec test scripts like this:
    suite "Group of related test cases" do
  include TestHelper

  before(:all) do

  before(:each) do

  after(:each) do
    failsafe{ logout }

  test "One test" do
    # might change application records

  test "Another test case" do
    # doesn't matter the above test is run or not, as we start fresh

Now comes the hard question, how could you implement database reset as testers? No, it has to been done by developers. If your team is doing Agile (or claiming so), go ask them, and it will be of great help for them as well. From experience, the better architecture, easier to implement database reset and the earlier the better.