CI/CD Integration

The true power of automated testing is unlocked when it runs on every commit. Because BitDive tests behave exactly like standard generic Java tests, integrating them into your existing CI/CD pipeline is seamless. You don't need new plugins, complex agents, or proprietary steps.

If your pipeline can run mvn test, it can run BitDive.

The Integration Philosophy

Your goal is to establish a Quality Gate.

Every time a developer pushes code, the pipeline should:

1. Build the application.
2. Run Unit Tests (both manual and BitDive-generated).
3. Fail the build if any regression is detected.

Since BitDive tests validation logic is deep (checking method internals), they often catch regressions that standard integration tests miss.

---

Configuration Basics

Integrating BitDive into CI/CD is simple because it leverages your existing build process.

1. Generate a Test: In the BitDive UI, generate your test and copy the Test ID.
2. Update Your Test Class: Open your project's BitDive test harness (e.g., BitDiveTest.java) and paste the new Test ID into the configuration.
3. Commit: Push the updated test file to your version control system (Git).

Standard Maven Command

Once the Test IDs are committed to your repository, your CI pipeline doesn't need any special commands. It simply runs the tests that are present in the code.

mvn test

The JUnit harness will read the committed Test IDs, connect to the BitDive server to download the Replay Plans, and execute the tests.

Environment Variables

The only configuration your CI usually needs is authentication parameters to allow the test harness to fetch the Replay Plans securely.

Variable	Description
BITDIVE_SERVER_URL	URL of your BitDive instance
BITDIVE_API_TOKEN	Authentication token

Ensure these are set as Secrets in your CI environment (GitHub Secrets, GitLab Variables, etc.).

---

Pipeline Recipes

Here are snippets for common CI providers.

1. GitHub Actions

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
      
      - name: Run BitDive Tests
        run: mvn test
        env:
            BITDIVE_API_TOKEN: ${{ secrets.BITDIVE_API_TOKEN }}
            BITDIVE_SERVER_URL: ${{ secrets.BITDIVE_SERVER_URL }}

2. GitLab CI

bitdive_tests:
  stage: test
  image: maven:3.8-openjdk-17
  script:
    - mvn test
  variables:
    BITDIVE_SERVER_URL: $BITDIVE_SERVER_URL
    BITDIVE_API_TOKEN: $BITDIVE_API_TOKEN

3. Jenkins

stage('BitDive Tests') {
    steps {
        withCredentials([string(credentialsId: 'bitdive-token', variable: 'TOKEN')]) {
            sh 'mvn test'
        }
    }
}

---

Strategic Test Execution

You usually don't want to run every test on every commit. Here is a strategy for tiered execution:

Tier 1: The "Smoke" Suite (On Every PR)

• Goal: Fast feedback (< 2 mins).
• Content: 5-10 critical "Happy Path" traces (Login, Checkout, Home Page).
• Trigger: On Pull Request creation.

Tier 2: The Regression Suite (Nightly)

• Goal: Deep validation.
• Content: All edge cases, complex reporting flows, massive trace captures.
• Trigger: Scheduled cron job at 2 AM.

Tier 3: The "Bug Farm" (On Demand)

• Goal: Verify specific fixes.
• Content: Traces captured specifically from past bug reports (e.g., "The 500 error when User ID is null").
• Trigger: Manually by developers when working on relevant modules.

Troubleshooting CI/CD

If tests pass locally but fail in CI, check these common culprits:

• Timezones: Is your local machine UTC-5 and the CI server UTC? BitDive handles time virtualization, but explicit date formatting in logs might still drift.
• JDK Versions: Ensure your CI container uses the exact same Java major version (e.g., 17 vs 21) as your local env.
• Secrets: Double-check that the BITDIVE_API_TOKEN is correctly exported in the CI environment variables.

By integrating these tests, you move from "hoping" nothing broke to "knowing" nothing broke.