Introduction

Yes, most test frameworks provide a way to run setup code once before the entire test suite, a test class, or a test collection. The exact hook depends on the framework, but the idea is always the same: perform expensive initialization once, share the prepared state carefully, and clean it up after the suite finishes.

Use the Framework’s Suite-Level Setup Hook

The correct solution is framework-specific. You should use the lifecycle feature built into the test runner rather than inventing a global flag or manual singleton.

In pytest, a session-scoped fixture runs once for the entire test session.

1import pytest
2
3
4@pytest.fixture(scope="session", autouse=True)
5def setup_test_environment():
6    print("Preparing test environment once")
7    data = {"base_url": "http://localhost:5000"}
8    yield data
9    print("Cleaning up once after all tests")

Because the fixture is session-scoped, it is created a single time and then torn down after the last test completes.

JUnit Example with @BeforeAll

In JUnit 5, use @BeforeAll for code that should run once before all tests in a class.

1import org.junit.jupiter.api.BeforeAll;
2import org.junit.jupiter.api.Test;
3
4class RepositoryTests {
5    @BeforeAll
6    static void setupOnce() {
7        System.out.println("Initialize shared resources");
8    }
9
10    @Test
11    void firstTest() {
12    }
13
14    @Test
15    void secondTest() {
16    }
17}

This is class-level, not necessarily whole-suite level across every test class. If you need broader setup, you typically use build-tool hooks, test containers, or framework-specific extensions.

Choose the Smallest Safe Scope

Not every setup task should run once for the whole test run. Scope matters.

Use per-test setup when tests must remain fully isolated. Use class-level setup when the state is safe to share inside one class. Use suite-level or session-level setup only when the initialized resource is expensive and does not create hidden coupling between tests.

For example, starting one disposable database container for the entire suite can be reasonable. Reusing mutable test data across all tests without resetting it is usually not.

Teardown Matters Too

If you run code once before all tests, you usually also need a matching once-after-all cleanup hook. A setup that opens sockets, creates files, or starts containers without teardown can leave the environment dirty and make later test runs unreliable.

The yield form of a pytest fixture is good because setup and teardown live in one place. Other frameworks offer similar paired hooks such as @AfterAll.

That cleanup step is part of correctness, not just tidiness. A suite-level setup without a suite-level teardown often creates the hardest test failures to diagnose.

Avoid Manual Global State

A common anti-pattern is writing a global boolean like initialized = True and checking it inside tests. That bypasses the test framework, breaks under parallel execution, and makes lifecycle behavior hard to reason about.

The runner already knows when the session starts and ends. Let it manage setup order and cleanup order.

Common Pitfalls

• Assuming “before all tests” means the same scope in every framework.
• Sharing mutable state across tests and then debugging order-dependent failures.
• Forgetting teardown for resources created during one-time setup.
• Using manual global flags instead of built-in fixture or lifecycle hooks.
• Running tests in parallel without checking whether the shared resource is safe for concurrent use.

Summary

• Yes, most frameworks support code that runs once before all tests.
• Use the framework’s lifecycle hook such as a session fixture or @BeforeAll.
• Pick the narrowest scope that still avoids redundant setup work.
• Pair one-time setup with one-time teardown.
• Avoid manual global initialization patterns that fight the test runner.