Integration testing framework
This document outlines a comprehensive external integration testing framework for the VisualSign parser that enables testing against real blockchain transactions from multiple chains.Overview
The framework supports three testing modes:- Fixture mode - Recorded API responses (VCR-style)
- Live API mode - Direct calls to blockchain explorers
- Fork mode - Local blockchain forks (Surfpool/Anvil)
Problem statement
We need to:- Test parser implementations against real-world blockchain transactions
- Support multiple chains (Solana, Ethereum, Sui, Tron)
- Enable testing without API keys in CI/CD
- Maintain reproducible test results
- Test against both historical and current blockchain state
Architecture
Testing modes
1. Fixture mode (default)
Uses recorded API responses (VCR-style):- Fast and deterministic
- No API keys required
- Ideal for CI/CD and regular test runs
2. Live API mode
Direct calls to blockchain explorers (Helius, Etherscan, etc.):- Validates against current blockchain state
- Requires API keys
- Used for recording new fixtures and validation
3. Fork mode
Local blockchain forks using Surfpool (Solana) or Anvil (Ethereum):- Full blockchain state testing
- Enables transaction simulation
- Consistent pattern across chains
Key components
VCR implementation
A minimal recording layer built on wiremock:- Leverages wiremock’s reliability
- Provides simple JSON cassettes (easy to inspect/edit)
- Has minimal maintenance burden
Fork manager interface
- SurfpoolManager - Solana mainnet fork
- AnvilManager - Ethereum mainnet fork
- Future: Sui, Tron equivalents
Test environment factory
Testing workflow
Development workflow
CI/CD workflow
Configuration
Benefits
| Benefit | Description |
|---|---|
| Multi-mode testing | Fixtures for fast CI/CD, live API for validation, forks for deep integration |
| Chain agnostic | Consistent patterns across chains, easy to add new chains |
| Developer experience | Simple commands to record fixtures, fast local testing |
| Maintainability | Uses well-tested libraries, clear module boundaries |
| Cost effective | Minimal API calls (only when recording), no API keys for most runs |
Risks and mitigations
| Risk | Mitigation |
|---|---|
| API rate limits | Use fixtures by default, limit live tests |
| Fixture staleness | Nightly job to validate and update |
| Fork tool availability | Graceful degradation, skip if unavailable |
| Large fixture files | Compress, store only essential data |
Success metrics
- All parser tests pass with fixtures
- Less than 30 second test execution time with fixtures
- Greater than 95% success rate against live API
- Support for at least 2 chains (Solana, Ethereum)
- No API keys required for PR checks
Related documentation
- Best Practices - Contribution guidelines
- Project Structure - Architecture overview
- Parser CLI - Command-line testing tool