Test Data Management

1 The Hook — Why This Matters

A Wellington fintech team ran their 300-test suite in parallel on eight workers. Every Monday morning, three random tests failed. After two weeks of debugging, they discovered the cause: all tests shared a single test user account. When two tests tried to update the same user's profile simultaneously, one overwrote the other's data. The "flakiness" was a data collision, not a code bug.

Test data is the silent killer of automation reliability. If your data strategy is "use the same account every time," your tests will fail mysteriously, intermittently, and expensively.

2 The Rule — The One-Sentence Version

Shared data creates hidden dependencies between tests. Hardcoded credentials create security risks. Static CSVs become stale the moment the schema changes. Dynamic, isolated, factory-generated data is the only scalable approach.

3 The Analogy — Think Of It Like...

4 Watch Me Do It — Step by Step

Here are the three pillars of professional test data management.

1. Fixtures for setup and teardown

   @pytest.fixture
   def new_user():
       return {"username": "alice", "email": "alice@example.com"}
   
   @pytest.fixture
   def temp_database():
       db = create_test_db()
       yield db
       db.drop_all()  # teardown always runs

2. Factories for dynamic data generation

   import factory
   from faker import Faker
   
   fake = Faker()
   
   class UserFactory(factory.Factory):
       class Meta:
           model = User
       username = factory.LazyAttribute(lambda x: fake.user_name())
       email = factory.LazyAttribute(lambda x: fake.email())
       is_active = True
   
   # Each call creates unique data
   user1 = UserFactory()
   user2 = UserFactory()

3. Environment variables for secrets and config

   # .env (NEVER COMMIT)
   BASE_URL=https://staging.example.com
   API_KEY=sk_test_xxx
   
   # test code
   from dotenv import load_dotenv
   load_dotenv()
   BASE_URL = os.getenv("BASE_URL", "https://localhost:3000")

@pytest.fixture(scope="session")
def database_url(worker_id):
    # Each parallel worker gets its own test database
    if worker_id == "master":
        db_name = "test_db_master"
    else:
        db_name = f"test_db_{worker_id}"
    return f"postgresql://user:pass@localhost/{db_name}"

@pytest.fixture(autouse=True)
def setup_db(database_url):
    # Reset tables before each test (or use transactions)
    db = create_engine(database_url)
    Base.metadata.drop_all(db)
    Base.metadata.create_all(db)
    yield db
    db.dispose()

5 When to Use It / When NOT to Use It

6 Common Mistakes — Don't Do This

7 Now You Try — Interview Warm-Up

8 Self-Check — Can You Actually Do This?

Click each question to reveal the answer. If you got all three, you're ready to practice.

9 Interview Prep — Mid-Level Q&A

Interviewers ask how you've solved real test data problems. Be prepared to discuss isolation, parallelism, and security.