Home / Tutorials / Testing with Known Database States

Testing with Known Database States

Ensure consistent, repeatable tests by using tagged database snapshots as known initial states. Perfect for regression testing and test automation.

The Story: When Tests Become Unreliable

Meet Morgan, a QA engineer responsible for testing a complex e-commerce application. The test suite includes hundreds of test cases that need to run reliably, especially for regression testing before each release.

⏰ Monday, 9:00 AM - The First Test Run

Morgan runs the test suite for the shopping cart feature. The tests pass. Great! But Morgan knows these tests need to run many times—during development, before releases, and for regression testing.

⏰ Monday, 2:00 PM - The Second Test Run

After developers made some changes, Morgan runs the tests again. This time, 3 tests fail. But were they failing because of the new changes, or because the database state changed from the first test run?

The problem: The database state is unknown and inconsistent.

⏰ Tuesday, 10:00 AM - The Regression Test Nightmare

It's release day. Morgan needs to run the full regression suite. But:

  • The database has been used by multiple testers
  • Previous test runs left the database in an unknown state
  • Some tests pass, some fail, but it's unclear if failures are real bugs or just inconsistent data
  • Morgan spends hours trying to figure out what the "correct" database state should be

⏰ Tuesday, 3:00 PM - The Realization

Morgan realizes the fundamental problem: Tests need a known, consistent starting state. Without it:

  • Tests are unreliable and flaky
  • Failures are hard to diagnose
  • Regression testing is unreliable
  • Time is wasted debugging false failures

The Solution

With Quemsi, create tagged snapshots as known database states for each test scenario. Before each test run, restore to the known state. This ensures tests start with the exact same data every time, making tests reliable, repeatable, and predictable.

Why Known Database States Matter for Testing

Consistent Test Results

Tests run against the same database state every time, eliminating flaky tests caused by inconsistent data. If a test fails, you know it's a real issue, not a data problem.

Predictable Outcomes

With known initial states, you know exactly what to expect from each test. Test results become predictable and reliable, making it easier to identify real bugs.

Repeatable Regression Testing

Run regression tests hundreds of times with confidence. Each run starts from the same known state, ensuring consistent results across all test executions.

Faster Debugging

When a test fails, you know the exact database state it started with. This makes debugging faster and more accurate—no guessing about what data was present.

Parallel Test Execution

Run multiple test suites in parallel, each restoring to its own known state. No conflicts, no race conditions, just reliable parallel testing.

How to Set Up Known Database States for Testing

1

Prepare Your Test Database State

Set up your database with the exact data needed for your test scenario:

  1. Create the database structure (tables, indexes, etc.)
  2. Insert test data (users, products, orders, etc.)
  3. Set up relationships and dependencies
  4. Verify the data is correct for your test scenario

This becomes your "known state" that tests will start from.

2

Create a Tagged Snapshot

Once your database is in the desired state, create a snapshot with a descriptive tag:

  1. Open Quemsi web UI
  2. Navigate to your test database
  3. Click "Create Backup"
  4. Tag it descriptively: test-shopping-cart-baseline or test-user-registration-initial
  5. Add a description explaining what test scenario this state supports
# Example: Create snapshot for shopping cart tests quemsi backup create \ --database test_db \ --tag "test-shopping-cart-baseline" \ --description "Initial state for shopping cart test suite: 10 products, 5 users, empty carts"
3

Restore Before Each Test Run

Before running your tests, restore to the known state:

  1. Open Quemsi web UI
  2. Find your tagged snapshot in the timeline
  3. Click "Restore"
  4. Select your test database
  5. Confirm the restore

Your database is now in the exact known state, ready for testing.

# Example: Restore before test run quemsi restore execute \ --backup-id "test-shopping-cart-baseline" \ --target-database test_db
4

Run Your Tests

Now run your test suite. Since the database starts from a known state, test results are reliable and predictable.

5

Repeat for Regression Testing

For regression testing, simply restore to the known state again and run tests. The process is:

  1. Restore to known state (2 minutes)
  2. Run test suite
  3. Review results
  4. Repeat as needed

Each test run starts from the same state, ensuring consistent results.

Test Workflow with Known States

🔄 Complete Test Cycle

  1. Setup: Create tagged snapshot of known test state (one-time setup)
  2. Before Test: Restore to known state (2 minutes)
  3. Run Tests: Execute test suite
  4. Verify Results: Check test outcomes
  5. Repeat: For regression, restore and run again

Time per test cycle: 2 minutes restore + test execution time

✅ The Quemsi Advantage for Testing

With Quemsi, testing with known database states is:

  • Fast: Restore to known state in 2 minutes
  • Reliable: Same state every time = consistent test results
  • Repeatable: Run tests hundreds of times with confidence
  • Simple: Just restore and run—no complex setup scripts
  • Traceable: Tagged snapshots document what state each test uses

Best Practices for Test Database States

🏷️ Use Descriptive Tags

Tag your snapshots clearly to indicate their purpose:

  • test-{feature}-baseline - Base state for a feature's tests
  • test-{scenario}-initial - Initial state for a specific test scenario
  • test-regression-{date} - State used for regression testing
  • test-{suite}-setup - Setup state for a test suite

Examples:

  • test-shopping-cart-baseline
  • test-user-registration-initial
  • test-payment-processing-setup

📝 Document Test Scenarios

In your snapshot description, document what the state contains:

# Good snapshot description: "Baseline state for shopping cart test suite. Contains: 10 products, 5 registered users, 3 users with items in cart. Expected test outcomes: All cart operations should work correctly. Last updated: 2025-01-15"

This helps testers understand what to expect from tests.

🔄 Create Multiple States for Different Scenarios

Different test scenarios may need different initial states:

  • test-empty-cart - For testing cart creation
  • test-cart-with-items - For testing cart modifications
  • test-cart-checkout-ready - For testing checkout flow

Create separate snapshots for each scenario to test different conditions.

🔄 Update States When Tests Change

When test requirements change, update your known states:

  • Modify the database to match new requirements
  • Create a new snapshot with an updated tag
  • Or update the existing snapshot if the scenario is the same
  • Document what changed in the snapshot description

🧪 Test Your Known States

Before relying on a snapshot for testing:

  • Restore the snapshot to a test database
  • Verify the data matches expectations
  • Run a sample test to confirm it works
  • Document any quirks or special considerations

📊 Version Your Test States

As your application evolves, you may need different versions of test states:

  • test-shopping-cart-v1 - For testing version 1 features
  • test-shopping-cart-v2 - For testing version 2 features

This allows you to test different application versions with appropriate data.

Integration with CI/CD Pipelines

Quemsi integrates seamlessly with CI/CD pipelines for automated testing:

🔄 CI/CD Test Pipeline

  1. Pipeline starts: CI/CD pipeline triggers
  2. Restore state: Restore to known test state using Quemsi API
  3. Run tests: Execute automated test suite
  4. Report results: Generate test reports
  5. Cleanup: Optionally restore to clean state for next run
# Example: CI/CD pipeline script #!/bin/bash # Restore to known test state quemsi restore execute \ --backup-id "test-shopping-cart-baseline" \ --target-database test_db # Run test suite npm test # Check test results if [ $? -eq 0 ]; then echo "Tests passed!" else echo "Tests failed!" exit 1 fi

Benefits:

Real-World Testing Scenarios

Scenario 1: Regression Testing Before Release

Problem: Need to run full regression suite, but database state is unknown from previous test runs.

Solution:

  1. Restore to test-regression-baseline snapshot
  2. Run full regression test suite
  3. All tests start from known state
  4. Results are reliable and consistent

Time saved: Hours of debugging false failures vs. 2 minutes to restore known state.

Scenario 2: Parallel Test Execution

Problem: Multiple testers need to run tests simultaneously, but they conflict when using the same database.

Solution:

  1. Each tester has their own test database
  2. Each restores to the same known state snapshot
  3. Tests run in parallel without conflicts
  4. All tests use the same initial state

Result: Parallel testing is safe and reliable.

Scenario 3: Testing Different Scenarios

Problem: Need to test multiple scenarios (empty cart, cart with items, checkout ready) but setting up each state manually takes too long.

Solution:

  1. Create separate snapshots for each scenario
  2. Restore to test-empty-cart for cart creation tests
  3. Restore to test-cart-with-items for modification tests
  4. Restore to test-checkout-ready for checkout tests

Time saved: Minutes to restore vs. hours to manually set up each scenario.

Scenario 4: Debugging Test Failures

Problem: Test fails, but it's unclear if it's a real bug or just inconsistent database state.

Solution:

  1. Restore to the known test state
  2. Run the failing test in isolation
  3. Since the state is known, you can verify if the failure is real
  4. Debug with confidence knowing the exact initial conditions

Result: Faster, more accurate debugging.

Advanced: Multiple Test Suites with Different States

For complex applications, you might have multiple test suites, each requiring different database states:

📋 Test Suite Organization

  • Unit Tests: test-unit-baseline - Minimal data for fast unit tests
  • Integration Tests: test-integration-setup - Full data for integration scenarios
  • E2E Tests: test-e2e-complete - Complete application state for end-to-end tests
  • Performance Tests: test-performance-large - Large dataset for performance testing

Each test suite can restore to its appropriate known state, ensuring optimal test conditions for each type of testing.

Ready to Make Your Tests Reliable and Repeatable?

Start using Quemsi to create known database states for testing. Ensure consistent, repeatable test results with tagged snapshots that restore in minutes.

Get Started Free

Next Steps