Introduction

Yes, Bazel can be made to run tests serially, but the right flag depends on what you mean by "serially." Sometimes you only want test execution limited to one test at a time, while other times you want the entire Bazel action graph, including builds, to be reduced to one job.

Limit Test Concurrency Specifically

If the goal is "run one local test at a time," the most targeted knob is the local test concurrency setting:

bazel test --local_test_jobs=1 //...

This tells Bazel not to run multiple local tests concurrently. It is a good choice when:

• tests interfere with each other
• the machine is resource-constrained
• you want cleaner logs while debugging

This is more precise than limiting every kind of Bazel action.

Use --jobs=1 When You Want Everything Serialized

If you want to reduce the entire Bazel execution graph to one job at a time, use:

bazel test --jobs=1 //...

This affects far more than tests. It also limits build and analysis actions that Bazel would normally run in parallel. That can be useful for deterministic debugging, but it is usually slower than necessary if your real issue is test concurrency only.

So the distinction is:

• '--local_test_jobs=1 focuses on local test execution'
• '--jobs=1 constrains Bazel more broadly'

Mark Specific Tests as Exclusive

If only a few tests need exclusive execution, you do not have to serialize the entire test suite. Bazel supports marking tests as exclusive in the BUILD file:

1sh_test(
2    name = "database_integration_test",
3    srcs = ["database_integration_test.sh"],
4    tags = ["exclusive"],
5)

This is useful when most tests are safe in parallel, but a few integration tests need isolated access to shared ports, temporary directories, or external systems.

That is often a better long-term solution than globally forcing the whole suite to run serially forever.

Think About Why the Tests Need Serialization

If tests fail only when run in parallel, the test suite may be hiding shared-state problems such as:

• fixed port usage
• shared temp-file paths
• static mutable state
• external dependency collisions

Running serially can be a practical short-term workaround, but it is also a signal that the tests may need better isolation.

A good workflow is:

• use serial execution while debugging
• identify the shared-state conflict
• restore parallelism where possible

That keeps Bazel fast for the long term instead of normalizing slow builds as the default.

If you are working in CI, it can also be useful to make the serial flag explicit in the job configuration rather than hiding it in a wrapper script, so everyone can see that the suite is intentionally trading speed for isolation.

One detail to keep in mind is that --local_test_jobs=1 is specifically about local test execution. If your setup involves remote execution or remote test strategies, review the rest of the Bazel configuration as well so you do not assume the local flag controls every execution path.

Common Pitfalls

• Using --jobs=1 when the real need was only to serialize tests, not all Bazel work.
• Forcing the whole test suite to be serial because of one or two problematic tests.
• Assuming serial execution is the final fix instead of investigating shared-state bugs.
• Forgetting that exclusive tests can be tagged individually in the build definition.
• Debugging flaky tests without first deciding whether the flakiness is caused by concurrency or by something else entirely.

Summary

• Bazel can run tests serially.
• Use --local_test_jobs=1 when you want local tests to run one at a time.
• Use --jobs=1 only when you want to serialize the broader Bazel action graph.
• Tag individual tests as exclusive if only certain tests must not run alongside others.
• Prefer fixing shared-state test problems over making global serialization the permanent default.