Testing

MongoDB has three primary kinds of test:

1. C++ unit tests (*_test.cpp under src/mongo/).
2. JavaScript integration tests (jstests/).
3. Specialized suites — concurrency, FSM, fuzz, golden-data, replay, dbcheck, encryption, and more.

All of them are driven by the resmoke Python test runner.

Resmoke

buildscripts/resmoke.py is the top-level entry point. The runner understands "suites" defined under buildscripts/resmokeconfig/suites/. Each suite specifies which tests to run, which fixture (standalone, replica set, sharded cluster) to start, and which JS hooks to attach.

# List suites
buildscripts/resmoke.py list-suites

# Run a single test in the core suite
buildscripts/resmoke.py run --suites=core jstests/core/find/find1.js

# Run all replica-set tests
buildscripts/resmoke.py run --suites=replica_sets

# Run the C++ unit tests
buildscripts/resmoke.py run --suites=unittests

The src/mongo/resmoke/ directory contains the C++ side of resmoke — fixtures and helpers exposed to tests.

C++ unit tests

C++ tests live next to the code they exercise, named *_test.cpp. They use the MongoDB unittest framework defined in src/mongo/unittest/ and documented in docs/unit_test.md. The framework provides:

• TEST(suite, name) and TEST_F(fixture, name) macros.
• ASSERT_* macros that map to Status, BSONObj, and other MongoDB types.
• BenchmarkFixture for *_bm.cpp benchmarks built on Google Benchmark.
• A ServiceContextTest fixture that wires up a ServiceContext, an OperationContext, and the standard storage and replication mocks.

There are 1,713 *_test.cpp files in the tree as of the last snapshot. Each BUILD.bazel declares a mongo_cc_unit_test (or wrapper) target that pulls in the right dependencies.

To run a single C++ test target via Bazel:

bazel test //src/mongo/db:operation_context_test

To run the test under a debugger:

bazel build //src/mongo/db:operation_context_test
gdb bazel-bin/src/mongo/db/operation_context_test

JavaScript tests (jstests/)

jstests/ contains 7,000+ JavaScript files organized into directories that loosely correspond to suites:

Directory	Purpose
jstests/core/	Single-node standalone tests. The largest suite.
jstests/core_sharding/	Tests that target a sharded cluster topology.
jstests/core_standalone/	Variants that must run on a standalone (not replica set).
jstests/replsets/	Replica-set behavior tests.
jstests/sharding/	Sharding-specific tests.
jstests/concurrency/	FSM-based concurrency tests using the FSM library.
jstests/aggregation/	Aggregation pipeline tests.
jstests/change_streams/	Change-stream tests.
jstests/fle2/	Queryable Encryption tests.
jstests/disk/	Storage engine and durability tests.
jstests/multiVersion/	Mixed-version cluster tests.
jstests/noPassthrough/	Tests that customize the fixture (for example, custom CLI flags).
jstests/query_golden/	Golden data tests for query plan stability.

Tests are written in JavaScript and run inside jstestshell. Helpers are in jstests/libs/.

Suites and hooks

Suites stitch tests, fixtures, and hooks together. A "fixture" is a topology — standalone, replica set, sharded cluster — that resmoke spins up before running tests. A "hook" runs between tests to do work like:

• CheckReplDBHash — verify all replica-set nodes have the same data.
• ValidateCollections — run validate on every collection.
• CheckOrphansDeleted — verify no orphan documents linger after sharding migrations.
• RunDBCheckInBackground — run dbcheck concurrently with the workload.

Hooks live under buildscripts/resmokelib/testing/hooks/ and are referenced by name in suite YAML files.

Specialized suites

Suite family	What it does
concurrency_*	FSM-driven workloads under jstests/concurrency/fsm_workloads/.
fuzz, op_msg_fuzzer*	Randomized command and BSON fuzzers using libFuzzer (docs/libfuzzer.md, docs/fuzztest.md).
replay	Replay traffic captured by the traffic recorder.
dbcheck	Online consistency check (src/mongo/db/repl/dbcheck/).
query_golden*	Pin query plan output. Updates require explicit acknowledgment.
change_stream_fsm	Change streams under FSM workloads.
multiversion_*	Mixed-version replica sets and clusters.

Fail points

Most non-trivial tests use fail points to inject delays, errors, or branches at well-known points in the server. The mechanism is documented in docs/fail_points.md. Fail points are enabled at runtime via the configureFailPoint command and inspected via getParameter.

Coverage and Evergreen

evergreen/bazel_coverage.sh runs the unit tests under coverage instrumentation. Coverage results are uploaded as Evergreen task artifacts; there is no in-repo dashboard.

Local quickstart

# Build the test shell + binaries
bazel build install-devcore

# Run a small suite to smoke-test the build
buildscripts/resmoke.py run --suites=core --jobs=4 jstests/core/find/find1.js

For larger work, prefer running a suite slice (--filter or --shuffle plus --num-jobs-per-test) or scheduling an Evergreen patch build for the platform matrix.