The Test Lifecycle - setUp() and tearDown()

diagram the order setUp, setUpClass and their teardowns actually run mermaid

  flowchart TD
  A["setUpClass  -- once"] --> B["setUp"]
  B --> C["test_a"]
  C --> D["tearDown"]
  D --> E["setUp"]
  E --> F["test_b"]
  F --> G["tearDown"]
  G --> H["tearDownClass  -- once"]
  D -.->|"runs even if the test failed"| E
  I["per-test state goes in setUp"] -.-> B
  J["expensive shared state goes in setUpClass"] -.-> A

setUp runs before every test method and tearDown after it, so each test starts from the same state. setUpClass runs once for the whole class, which is where expensive shared work goes -- and which is why anything it creates is shared, and can be polluted by one test for the next.

The observed order, with two tests in one class

text

setUpClass
  setUp, test_a, tearDown
  setUp, test_b, tearDown
tearDownClass

setUp and tearDown ran twice — once per test — and the class-level pair ran once each. tearDown runs even when the test fails, which is what makes it the right place to release resources.

The practical distinction: put anything a test may modify in setUp, so each test gets a fresh copy. Put only expensive, read-only setup in setUpClass — a database connection, a loaded fixture file. Anything mutable created there is shared between tests, and then the order they run in starts to matter, which is the beginning of a flaky suite.

When setUp/tearDown help

Use them when each test needs:

• a fresh object
• temporary files
• a test database connection (prefer fixtures/mocks for unit tests)

Example

setup_teardown.py

import unittest
 
 
class TestListOps(unittest.TestCase):
    def setUp(self):
        self.items = [1, 2, 3]
 
    def tearDown(self):
        # cleanup if needed
        self.items = []
 
    def test_append(self):
        self.items.append(4)
        self.assertEqual(self.items, [1, 2, 3, 4])
 
    def test_pop(self):
        self.items.pop()
        self.assertEqual(self.items, [1, 2])

Rule of thumb

If your setUp becomes complex, consider:

• refactoring code
• using helper factories
• switching to pytest fixtures (Phase 4)

🧪 Try It Yourself

Exercise 1 – Write a unittest TestCase

pch.exerciseTag pch.exerciseTitle

Exercise 2 – assertRaises

pch.exerciseTag pch.exerciseTitle

Exercise 3 – setUp and tearDown

pch.exerciseTag pch.exerciseTitle