Evaluate Testcontainers integration: recommend selective adoption for local dev and SDK tests

[Copilot]

Comprehensive evaluation of Testcontainers for managing MongoDB/Redis dependencies in integration tests. Current approach relies on manual Docker Compose startup and shared service instances across tests.

Key Findings

Recommend selective adoption (not full replacement):

• ✅ High ROI: Local developer tests, SDK contract tests, database migration tests
• ⚠️ Keep existing: CI/CD pipeline (Docker Compose already optimized)
• ❌ Don't use: Browser automation (Chrome Launcher optimized), E2E tests (MockSiteLauncher sufficient)

Quantified benefits:

• Zero-config testing (eliminates manual docker compose up)
• Developer onboarding: 30min → 5min
• Test isolation: independent containers per test class
• Multi-version testing (MongoDB 5.0/6.0/7.0)

Costs:

• Container startup: +5-10s per test class (optimizable to ~0s with reuse)
• Docker requirement for all developers
• 3 additional test dependencies

Deliverables

Evaluation Reports (5 docs, ~60KB)

• Full analysis (testcontainers-evaluation.md, testcontainers-evaluation.en.md): Current architecture, benefits/costs, scenario evaluation, implementation roadmap
• Quick reference (testcontainers-evaluation.quick-ref.md): Decision tables, ROI matrix, common patterns
• Visual comparison (testcontainers-evaluation.visual-comparison.md): Workflow diagrams, decision trees
• Documentation index (testcontainers-evaluation.INDEX.md): Reading guide by role

Proof of Concept (4 files)

• Base class (AbstractMongoDBTestcontainerTest.kt): Spring Boot integration with dynamic property injection
• Example test (WebPagePersistenceIT.kt): 4 integration test scenarios
• Maven config (pom.xml.example): BOM setup, dependencies, profiles
• POC guide (README.md): Quick start, performance tuning, troubleshooting

POC Example

@SpringBootTest
@Testcontainers
@Tag("Integration")
@Tag("RequiresDocker")
class WebPagePersistenceIT : AbstractMongoDBTestcontainerTest() {
    
    @Autowired
    lateinit var session: PulsarSession
    
    @Test
    fun testPagePersistence() {
        // MongoDB automatically started and configured
        val page = session.load("https://example.com")
        assertNotNull(page.persistentId)
    }
}

Container lifecycle managed automatically. Connection details injected via @DynamicPropertySource.

Implementation Path

1. Pilot (1-2 weeks): Trial 2-3 tests in pulsar-it-tests, measure performance
2. Expand (2-3 weeks): Extend to sdks/kotlin-sdk-tests if successful
3. Document (1 week): Update TESTING.md, team training

Do not: Replace CI/CD Docker Compose, use for browser tests, or mandate for all tests.

Architecture Integration

Browser4 Testing Strategy (Hybrid Approach)
├─ Unit Tests → JUnit 5 only
├─ Integration Tests
│  ├─ Local Dev → Testcontainers (auto-managed)
│  ├─ CI/CD → Docker Compose (keep existing)
│  └─ SDK Tests → Testcontainers (isolated env)
└─ E2E Tests → MockSiteLauncher + Chrome Launcher (keep existing)

Coexistence with current JUnit 5 Tags taxonomy (@Tag("RequiresDocker")).

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.