Database Reset in Automated Testing

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
    open_browser
  end

  before(:each) do
    reset_database
    login_as("zhimin")
  end

  after(:each) do
    failsafe{ logout }
  end

  test "One test" do
    # might change application records
  end

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

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.