BitDive Glossary
Key terms used across BitDive documentation. If you are new to trace-based testing or deterministic verification, start here.
A
AI Code Verification
The process of verifying that AI-generated code changes meet real-world production behavior. BitDive provides this by letting AI agents compare execution traces before and after a code change via MCP. Related: AI Runtime Context
API Regression
A change in inter-service API behavior after a code modification that was not intended or expected. May include altered request payloads, missing headers, changed status codes, modified error responses, or different call sequences. BitDive detects API regressions by comparing real HTTP exchanges captured in traces before and after the change. Related: Before/After Trace Comparison
Auto-Mocking
BitDive automatically creates mock responses from captured runtime data. External dependencies (databases, APIs, message queues) are isolated using real recorded responses instead of manually written Mockito scripts.
Automated Quality Gate
An automated checkpoint in a Kubernetes environment or CI/CD pipeline that uses captured pod interactions to verify a new deployment. It acts as an autonomous gatekeeper for cloud-native releases.
Automated Test Creation
The ability to create comprehensive test suites without writing any manual test code. BitDive turns captured runtime traces into runnable JUnit tests automatically. Previously called: Automated Automation
Autonomous Quality Loop
A 6-step workflow where AI agents use BitDive to verify their own code changes:
- Fetch real runtime context via MCP
- Run baseline tests
- Make code changes based on real data
- Compare before/after traces
- Run full regression
- Report trace diffs as proof
B
Before/After Trace Comparison
Comparing execution traces captured before and after a code change to detect behavioral differences. Unchanged methods should produce identical results. Changed methods show exactly what shifted. This is the core of deterministic verification. Previously called: Semantic Diffing, Dual-Trace Inspection
Behavioral Change Detection
Detecting unexpected changes in application behavior by comparing runtime traces captured before and after a code change. BitDive identifies these changes by triggering the same API call on the updated service, capturing a new trace, and comparing it against the recorded baseline. Previously called: Semantic Divergence, Behavioral Divergence
Bytecode Instrumentation
The process of modifying Java class files at runtime to inject monitoring logic. BitDive uses a Java Agent to perform this with minimal overhead (0.5-5%), enabling deep observability without source code changes.
C
CI/CD Gate
A quality checkpoint in the delivery pipeline. BitDive blocks Pull Requests that fail behavioral verification against recorded production traces. Runs as part of standard mvn test in any CI environment.
Consumer-Driven Contracts (CDC)
A testing methodology where API consumers define expected provider behavior. BitDive automates this by analyzing real traffic to create implicit contracts based on actual behavior.
D
Deterministic Replay
The core mechanism where captured production traces (SQL, API calls, method state) are replayed against code in a controlled test environment. The execution environment exactly matches the recorded session, providing stable, non-flaky regression tests.
Deterministic Verification
Verifying code by replaying real captured data so the same input always produces the same output, regardless of environment. It replaces manual Mockito scripts with tests built from real runtime data. See comparison: BitDive vs. Diffblue (Static Analysis) Deep Dive: How Deterministic Replay Works
Distributed Tracing
Tracking a single request as it propagates through microservices. BitDive provides distributed tracing with deep, method-level visibility in each service, connecting service spans to actual Java code. Related: Distributed Tracing Guide
I
Integration Test
A test that boots the full Spring ApplicationContext. All internal beans, transactions, security filters, and validation are real. Only external dependencies (other microservices, 3rd-party APIs, databases in Replay mode) are stubbed or replayed from captured traces. Spring defines any test that loads an ApplicationContext as an integration test. BitDive supports two modes: Replay mode (all deps replayed, zero infrastructure) and Testcontainers mode (real DB via Testcontainers, external APIs replayed). Related: Integration Tests (Replay) | Testcontainers Integration Tests
J
Java Agent
A specialized tool that uses the Java Instrumentation API to modify bytecode. BitDive's Java Agent captures deep execution context with no manual code changes required. Setup: Infrastructure Deployment
M
MCP (Model Context Protocol)
An open standard that allows AI models to interact with external tools. BitDive uses MCP to provide AI agents (Cursor, Claude Code, Windsurf) with real runtime context from the JVM.
Mockito Alternative (Mockless Testing)
BitDive serves as a modern alternative to manual mocking frameworks like Mockito. By replaying real dependency responses captured at runtime, it eliminates the maintenance burden of manually writing and updating mocks. See comparison: BitDive vs. WireMock (Manual Stubs) Related: Trace-Based Testing vs Mocking
N
N+1 Query Problem
A performance issue where an application makes multiple database queries instead of one. BitDive's SQL Inspection identifies these patterns automatically during trace analysis.
P
Performance Regression
A degradation in application response time, throughput, or resource usage caused by a recent code change. BitDive detects these automatically by comparing execution traces against baselines.
Production Traffic Capture
The process of recording real-world application behavior. This data serves as the Real Runtime Data for creating deterministic regression tests. See comparison: BitDive vs. Speedscale & Keploy (Traffic Replay) Guide: Creating Unit Tests from Traffic
R
Real Runtime Data
The captured runtime states (SQL results, API responses, method arguments) that serve as the foundation for deterministic verification. Real runtime data is what makes BitDive tests deterministic: they contain actual recorded behavior, not AI guesses or manually written mocks.
Replay-to-JUnit
The core technology that allows BitDive to convert a binary runtime trace file into a standard JUnit test class. It automatically scaffolds the test, creates the mocks, and sets the assertions from real captured data.
Runtime API Contract
The actual HTTP behavior between services as captured in execution traces. Includes endpoint, HTTP method, headers, serialized request body, response status, response body, and error responses. Unlike a static OpenAPI specification, a runtime API contract reflects what the service actually sends and receives at runtime. BitDive uses before/after trace comparison to detect when a runtime API contract changes after a code modification. Related: API Regression, Before/After Trace Comparison
Review Fatigue
A state where developers over-trust AI-generated code that appears syntactically correct, leading to logical errors. BitDive mitigates this by providing automated behavioral proof through trace comparison.
Root Cause Analysis (RCA)
Identifying the fundamental cause of failure. BitDive's deep traces and SQL inspection allow for instant RCA by showing exactly where the internal logic deviated.
Runtime Observability
A proactive quality strategy where runtime traces are not just monitored but transformed into deterministic test suites. Goes beyond traditional APM by connecting observability data directly to testing. Related: Observability vs APM vs Testing Guide
S
Service Map
A visual representation of microservices interactions. BitDive creates these automatically based on real runtime traffic. Explore: Analyzing the Service Map
SQL Inspection
Deep analysis of database queries executed by the JVM. BitDive records query parameters, execution time, and results to verify data-layer interactions without a live database.
T
Test Flakiness
Tests that fail intermittently without code changes, often due to race conditions or external dependency latency. BitDive eliminates flakiness by replacing variable network responses with deterministic replay of captured data.
Testcontainers
The management of ephemeral container lifecycles for integration testing. Testcontainers provide realism by running real databases (PostgreSQL, MongoDB, Redis) in Docker. BitDive supports two modes: Replay mode replays all dependencies (including database responses) from captured traces, requiring no infrastructure. Testcontainers mode runs a real database via Testcontainers while replaying only external API calls from traces. Database is auto-seeded from captured production data. Related: Testcontainers Integration Tests | Replay Mode Integration Tests
Trace-Based Testing
A testing approach where tests are built from real execution traces captured from a running application. Instead of writing mock data manually or using AI to predict test cases, trace-based testing records actual method calls, SQL queries, and API responses, then replays them as standard JUnit tests. Deep Dive: Full-Cycle Testing