MongoDB Regression Testing with BitDive

Testing MongoDB applications in Java usually involves a trade-off:

• Fongo / Mock Objects: Fast, but doesn't support complex Aggregations or newer Mongo features.
• Testcontainers: Realistic, but slow and requires Docker cleanup.

BitDive takes a different approach: trace replay. All MongoDB interactions (queries, aggregations, writes) are captured from your running application and replayed deterministically in tests. No live database needed.

Strategy 1: Pure Replay (Current, Shipped)

For both read-heavy and write-heavy logic, BitDive replays the exact MongoDB responses from captured traces.

During the test:

1. Your code executes the aggregate() or save() call.
2. BitDive intercepts the MongoDB driver call.
3. BitDive returns the exact BSON documents captured during recording.

This works for complex Aggregation Pipelines, reporting services, and write-heavy logic. No Docker, no Testcontainers, no infrastructure. Just mvn test.

Strategy 2: Hybrid State Verification (Testcontainers Mode)

For scenarios where you need to verify real database state changes against an actual MongoDB instance, use Testcontainers mode:

1. BitDive initializes a Testcontainer with a known dataset (auto-seeded from captured production data).
2. Your code executes repository.save() against the real MongoDB.
3. BitDive asserts that the document in the Testcontainer matches the expected state.
4. External API calls are still replayed from traces. No flakiness from 3rd-party services.

This catches schema drift, index issues, and MongoDB-specific behavior (aggregation pipeline edge cases, BSON type handling) that replay mode cannot.

Why drop Fongo?

Fongo (Fake Mongo) is a re-implementation of MongoDB in Java. It is often behind the official Mongo server versions. BitDive doesn't re-implement Mongo; it captures real responses from the actual driver interactions and replays them deterministically.

Next Steps

Integration Tests: Replay Mode | Integration Tests: Testcontainers Mode