Skip to main content

Component Testing with Deterministic Replay

Component testing in BitDive goes far beyond simple "Mockito + Stubs." Instead of manually mocking individual beans, BitDive allows you to execute real business scenarios by spinning up your actual application components (Spring Context) while virtualizing the "outside world" with production-grounded data. This extends the unit testing approach to full Spring contexts.

BitDive ensures that all external boundaries, SQL, HTTP, Kafka, and gRPC, are placed in Replay Mode, turning your complex microservice logic into a predictable, isolated, and high-speed test case.

BitDive Service Map - Visualizing microservices interdependencies for deterministic component testing

What Component Tests Catch That Unit Tests Miss​

The most expensive production bugs typically happen not in logic, but at integration seams. These are the classes of issues that unit tests are structurally unable to detect:

  • JSON contract breaks — A DTO field is renamed and the API response silently changes shape.
  • Configuration binding failures — @ConfigurationProperties stops binding after a key rename; the app starts with default values.
  • Transaction proxy bypass — A @Transactional method called from within the same bean skips the proxy, so the transaction never opens.
  • Repository query vs schema drift — A JPQL or native query is valid in theory but fails against the actual database schema after a migration.
  • Security filter misconfiguration — Spring Security rules block valid requests after a filter chain update.
  • Serialization mismatches — ObjectMapper serializes dates or enums in an unexpected format, breaking downstream consumers.

Unit tests remain green because they mock the very infrastructure where these bugs live. Component tests exercise the real Spring context and real data access, catching these issues before they reach production.

Deep Dive Unit vs Component Tests in Spring: Where the Boundary Lies

How BitDive Component Testing Works​

The system follows a sophisticated internal pipeline to transform a production trace into a "grown-up" component test:

  1. Normalization of Boundaries: BitDive identifies the entry point (e.g., a REST Controller) and "cuts" the execution chain at the component borders.
  2. Cassette Formation: External interactions are converted into "cassettes":
    • HTTP: Request fingerprint (Method/URL/Body) map to recorded Responses.
    • SQL: Normalized queries + bind parameters map to recorded ResultSets.
    • Kafka: Topics and keys map to recorded payloads.
  3. Deterministic Injection: Sources of non-determinism like Instant.now(), UUID.randomUUID(), and Random are "taped" to return the exact sequence of values recorded during the original execution.

Selecting Java Traces - Choosing production execution paths for virtualized component test replay

The Replay Test Architecture​

BitDive provides a powerful, reusable harness for component tests. The goal is "Minimum Code, Maximum Verification."

1. The Replay Harness (ReplayTestBase)​

By extending ReplayTestBase, your test classes become simple pointers to scenarios, eliminating thousands of lines of boilerplate setup.

class PolicyControllerReplayTest extends ReplayTestBase {

    @Override
    protected List<ReplayTestConfiguration> getTestConfigurations() {
        return ReplayTestUtils.fromRestApiWithJsonContentConfigFile(
                Arrays.asList("0d46c175-4926-4fb6-ad2f-866acdc72996")
        );
    }
}

2. Internal Execution Flow​

When you trigger mvn test, the internal BitDive harness performs the following:

  • Spring Boot Context: Loads the actual Spring Context (or a specific test profile).
  • Replay Beans Registration: Injects interceptors for HTTP/SQL/Kafka and stabilizers for Time/UUID.
  • Cassette Matching: During execution, when your code calls a database or a downstream API, BitDive's matcher returns the recorded response instead of hitting a live resource.
  • Invariant Verification: The test fails if the code makes an unexpected external call or if the contract of a recorded call changes.

BitDive Trace Drilldown - Verifying method-level inputs and return values in a component test context

Key Benefits of the Abstract Approach​

Using BitDive's ReplayTestBase provides several strategic advantages over traditional integration testing:

1. Production Bug Reproducibility​

If a bug occurs in production, you can simply take the scenarioId, add it to your getTestConfigurations() list, and you instantly have a regression test that reproduces the exact failure locally.

2. "Strict Mode" Safety Net​

Traditional tests often pass even if the code starts making unnecessary extra database calls. BitDive's "Strict Mode" can be configured to fail the test if any unrecorded external interaction occurs, catching hidden performance regressions.

3. Zero Flakiness​

By fixing UUIDs, Timestamps, and Random values, the test becomes environmentally independent. It will run identically on your laptop, a CI runner, or a colleague's machine, regardless of the time of day.

4. White-Box + Black-Box Verification​

BitDive doesn't just check the final API response (Black-Box). It observes the entire internal call chain and external effects (White-Box), providing full observability around your business logic.

Next Steps: Scaling Your Coverage​

You can easily scale coverage by adding batches of scenarios to a single test class or using parameterization to run hundreds of production-grade checks in seconds.

Unit Testing Guide - Learn how to create method-level tests.

CI/CD Integration Guide - Automate your component tests for every release.

Configuration Guide - Advanced settings for matcher policies and masking.

Last updated on by turmyshevd