Test Isolation and Setup

Test Isolation and Setup: Building Your Test Laboratory 🧪

The Story of the Perfect Science Lab

Imagine you’re a scientist with a super important job: testing if a new medicine works. But here’s the tricky part—you can’t test it on someone who’s already sick with other things, or in a dirty lab with random stuff flying around. You need a clean, controlled space where you know EXACTLY what’s happening.

That’s what Test Isolation is all about! It’s like building the perfect science lab for your code tests.

🎭 Test Doubles: Your Team of Actors

What are Test Doubles?

Think of your code like a movie. Sometimes the real actors are too busy, too expensive, or too dangerous for a scene. So what do movie directors use? Stunt doubles!

Test doubles are fake versions of real code parts that pretend to be the real thing during tests.

Why Do We Need Them?

Imagine you’re testing if your pizza ordering app works. But you don’t want to:

• Actually charge real money every time you test
• Actually send real pizzas to random addresses
• Wait for the real pizza shop computer to respond

So you create test doubles that pretend to be these things!

// The REAL pizza service (costs money!)
const realPizzaService = {
  orderPizza: (type) => {
    // Charges $15 to credit card
    // Calls real pizza shop
    return "Real pizza ordered!"
  }
}

// The TEST DOUBLE (free and fast!)
const fakePizzaService = {
  orderPizza: (type) => {
    return "Pretend pizza ordered!"
  }
}

🎯 Stub vs Driver: Two Special Helpers

The Stub: The Answer Machine

A Stub is like a magic 8-ball that always gives you the answer you need.

Real Life Example:

• You ask your mom: “What’s for dinner?”
• Real mom: Checks fridge, thinks about it, might say “I don’t know yet”
• Stub mom: Always says “Pizza!” (because that’s what you programmed)

// STUB: Always returns what we tell it to
const weatherStub = {
  getTemperature: () => 72  // Always sunny!
}

// Now our test knows exactly what to expect
test('should suggest shorts when warm', () => {
  const suggestion = getClothingSuggestion(weatherStub)
  expect(suggestion).toBe('Wear shorts!')
})

When to use a Stub:

• When you need a specific answer every time
• When the real thing is slow or unreliable
• When you’re testing something that USES this data

The Driver: The Button Pusher

A Driver is like someone who sits in the driver’s seat and pushes all the buttons to see if the car works.

Real Life Example:

• You built a toy robot
• Driver: The person who presses the buttons to test if the robot walks, talks, and dances

// DRIVER: Calls the code we're testing
function testRobotDriver() {
  const robot = new Robot()

  // Driver pushes buttons to test
  robot.walk()       // Does it walk?
  robot.talk()       // Does it talk?
  robot.dance()      // Does it dance?
}

Stub vs Driver: The Simple Difference

graph TD
    A["Your Code Being Tested"] --> B["Needs data FROM something?"]
    B --> C["Use a STUB!"]
    A --> D["Needs something TO test it?"]
    D --> E["Use a DRIVER!"]

    style C fill:#90EE90
    style E fill:#87CEEB

🎪 Mocking Strategies: The Art of Pretending

What is Mocking?

Mocking is like playing pretend, but for code! A Mock is a test double that also remembers what happened.

Real Life Example:

• Normal teddy bear: Just sits there
• Mock teddy bear: Remembers every hug, counts them, and can tell you “I was hugged 5 times!”

Strategy 1: The Simple Mock (Fake Everything)

Just replace the real thing with a fake that works for your test.

// Simple mock of an email sender
const mockEmailSender = {
  sentEmails: [],  // Remembers emails!

  sendEmail: (to, message) => {
    mockEmailSender.sentEmails.push({to, message})
    return true
  }
}

// Test it!
sendWelcomeEmail("friend@email.com", mockEmailSender)

// Check: Did it try to send an email?
expect(mockEmailSender.sentEmails.length).toBe(1)

Strategy 2: The Spy Mock (Watch and Report)

A spy mock watches what happens and reports back, like a friendly detective.

// Spy keeps track of calls
const spyLogger = {
  calls: [],
  log: (message) => {
    spyLogger.calls.push(message)
  }
}

// After test, we can check:
expect(spyLogger.calls).toContain('User logged in')

Strategy 3: The Strict Mock (Must Follow the Script)

A strict mock is like an actor who MUST say their lines exactly as written.

// Strict mock expects specific calls
const strictPayment = {
  expectedCalls: [
    {method: 'charge', args: [100]},
    {method: 'sendReceipt', args: ['customer@email.com']}
  ],
  callIndex: 0,

  charge: (amount) => {
    // Checks if called correctly!
  }
}

graph TD
    A["Mocking Strategies"] --> B["Simple Mock"]
    A --> C["Spy Mock"]
    A --> D["Strict Mock"]

    B --> E["Replace & Work"]
    C --> F["Watch & Remember"]
    D --> G["Follow Script Exactly"]

    style B fill:#FFB6C1
    style C fill:#98FB98
    style D fill:#87CEFA

🧰 Test Fixtures: Your Pre-Set Toy Box

What are Test Fixtures?

A fixture is like a toy box that’s already set up with everything you need to play.

Real Life Example:

• You want to play restaurant
• Without fixture: You need to find plates, cups, pretend food, a table…
• With fixture: Open the toy box—everything’s already there!

// FIXTURE: Pre-made test data
const testUserFixture = {
  name: "Test Tommy",
  age: 10,
  email: "tommy@test.com",
  favoriteColor: "blue"
}

const testOrderFixture = {
  items: ["pizza", "soda"],
  total: 15.99,
  address: "123 Test Street"
}

Why Fixtures Are Awesome

1. Save Time: Don’t create the same data over and over
2. Stay Consistent: Same data = same results
3. Easy to Read: Everyone knows what “testUserFixture” means

// WITHOUT fixtures (messy!)
test('user can order', () => {
  const user = {name: "Bob", age: 25, email: "bob@test.com"}
  const order = {items: ["pizza"], total: 10}
  // ... test code
})

// WITH fixtures (clean!)
test('user can order', () => {
  const user = testUserFixture
  const order = testOrderFixture
  // ... test code
})

🎬 Setup and Teardown: Before and After the Show

The Theater Analogy

Running tests is like putting on a play:

1. Setup (Before the show): Set up the stage, put out the props, get actors ready
2. The Test (The show): Perform the play!
3. Teardown (After the show): Clean up, put away props, reset for next show

Setup: Getting Ready

// Setup runs BEFORE each test
beforeEach(() => {
  // Create a fresh database
  database = new TestDatabase()

  // Add test user
  database.addUser(testUserFixture)

  // Start with clean state
  shoppingCart = new ShoppingCart()
})

Teardown: Cleaning Up

// Teardown runs AFTER each test
afterEach(() => {
  // Empty the cart
  shoppingCart.clear()

  // Close database connection
  database.close()

  // Delete test files
  cleanupTestFiles()
})

The Full Picture

graph TD
    A["beforeEach: Setup"] --> B["Test 1 Runs"]
    B --> C["afterEach: Cleanup"]
    C --> D["beforeEach: Setup"]
    D --> E["Test 2 Runs"]
    E --> F["afterEach: Cleanup"]
    F --> G["Fresh start for Test 3!"]

    style A fill:#90EE90
    style C fill:#FFB6C1
    style D fill:#90EE90
    style F fill:#FFB6C1

Why Both Are Important

🏝️ Test Isolation: Every Test is an Island

The Golden Rule

Each test should be able to run ALONE, without needing other tests!

Why Isolation Matters

Bad Example (Tests Depend on Each Other):

// Test 1 creates a user
test('create user', () => {
  createUser("Tommy")  // Creates Tommy
})

// Test 2 NEEDS the user from Test 1
test('delete user', () => {
  deleteUser("Tommy")  // Fails if Test 1 didn't run!
})

Problem: If Test 1 fails or doesn’t run first, Test 2 breaks!

Good Example (Isolated Tests):

// Test 1 is independent
test('create user', () => {
  createUser("Tommy")
  expect(userExists("Tommy")).toBe(true)
  deleteUser("Tommy")  // Clean up after yourself!
})

// Test 2 is also independent
test('delete user', () => {
  createUser("Bobby")  // Creates its own user
  deleteUser("Bobby")
  expect(userExists("Bobby")).toBe(false)
})

The Island Test

Ask yourself: “If I run ONLY this test, will it work?”

• ✅ YES = Good isolation!
• ❌ NO = Bad! Fix it!

How to Achieve Isolation

graph TD
    A["Test Isolation Rules"] --> B["Create your own data"]
    A --> C["Clean up after yourself"]
    A --> D["Never share state between tests"]
    A --> E["Use fresh mocks for each test"]

    style A fill:#FFD700
    style B fill:#98FB98
    style C fill:#98FB98
    style D fill:#98FB98
    style E fill:#98FB98

The Complete Isolation Checklist

1. ✅ Own Setup: Each test creates what it needs
2. ✅ Own Teardown: Each test cleans up what it made
3. ✅ No Shared State: No global variables that change
4. ✅ Fresh Mocks: New mock objects for each test
5. ✅ Random Order OK: Tests can run in any order

🎯 Putting It All Together

Here’s how all these concepts work together:

// FIXTURE: Pre-made test data
const gameFixture = {
  player: "Hero",
  score: 0,
  lives: 3
}

// MOCK: Fake sound system
const mockSoundSystem = {
  playedSounds: [],
  play: (sound) => {
    mockSoundSystem.playedSounds.push(sound)
  }
}

// SETUP: Before each test
beforeEach(() => {
  game = new Game(gameFixture)
  game.soundSystem = mockSoundSystem  // Use mock!
  mockSoundSystem.playedSounds = []   // Fresh mock!
})

// TEARDOWN: After each test
afterEach(() => {
  game.reset()
})

// ISOLATED TEST: Doesn't need other tests!
test('collecting coin adds score and plays sound', () => {
  game.collectCoin()

  expect(game.score).toBe(10)
  expect(mockSoundSystem.playedSounds).toContain('coin')
})

🌟 Remember This!

🚀 You’ve Got This!

Now you understand how to:

• Create fake helpers (test doubles) so you don’t need the real thing
• Use stubs for answers and drivers for testing
• Mock things that remember what happened
• Set up fixtures so you don’t repeat yourself
• Use setup and teardown like a professional
• Keep each test isolated like its own little world

Your tests will be clean, fast, and reliable!

Go forth and test with confidence! 🎉