Three ways to trigger all 42+ SDKs:
1. Set CI variable TEST_ALL_SDKS=true
2. Include [test-all] in commit message
3. Push a tag (releases test everything)
- Build C CLI binary for testing all SDKs through unsandbox
- test-sdk.sh runs: build/un → unsandbox → SDK → unsandbox → test code
- Each SDK is tested for --help and code execution
- No local language interpreters needed on build server
Add per-client Makefiles for C, Python, and Go with:
- CLI mode: Tests --help, arg parsing, syntax validation
- Library mode: Unit tests, import verification
- Integration mode: API contract validation (with credentials)
- Functional mode: Real-world scenario tests
C client:
- 22 library tests (SHA-256, HMAC-SHA256, detect_language)
- Full unsandbox.c implementation with examples
Python client (sync + async):
- Delegates to sync/ and async/ subdirectories
- pytest-based test suites with coverage
- Examples for concurrent execution, streaming
Go client:
- Delegates to sync/ and async/ subdirectories
- go test integration with vet and fmt
Also update detect-changes.sh to detect changes in
both root-level un.* files AND clients/ directory.
Add comprehensive testing infrastructure for UN clients:
1. Smart Change Detection (detect-changes.sh)
- Detects changes in BOTH root-level (un.py, un.go) AND clients/ directory
- Maps file extensions and directory names to languages
- Triggers test_all when infrastructure changes
2. Language-Specific CI Matrix (generate-matrix.sh compatible)
- Only runs tests for languages with changes
- Example: modify clients/python/ → pytest runs, Go/Ruby skipped
3. Testing Strategy Document (TESTING-STRATEGY.md)
- Complete testing matrix by language tier (compiled, interpreted, inception)
- Unit, integration, embedding, and parity tests
- Inception pattern for languages without local interpreters
- Common failures and fixes
- Rollout schedule for client/ migration
4. Makefile Targets
- 'make test-python', 'make test-go', etc. for local development
- 'make test-all' for comprehensive testing
- 'make test-integration' for API contract validation
- 'make test-ci-locally' to simulate CI pipeline
5. Updated CLAUDE.md
- Documents SDK architecture (in growth state)
- Explains three purposes: CLI, library, embeddable
- References TESTING-STRATEGY.md for details
This enables:
✓ Per-language testing (only run what changed)
✓ Local developer workflow (make test-LANG)
✓ 42+ language feature parity validation
✓ Cross-language integration testing
- Implement detect-changes stage: identifies which SDKs changed
- Implement generate-matrix stage: creates dynamic test matrix based on changes
- Only test SDKs that changed (5x faster than testing all 42)
- Parallel test execution via GitLab matrix strategy
- Science jobs for pool burning: validate-examples, lint-all-sdks, benchmark-clients
- Zero cost execution: uses warm pool + idle capacity
- Comprehensive reporting with JUnit XML and markdown summaries
Pipeline flow:
detect-changes → generate-matrix → build → test (parallel) → science → report
The unfair advantage:
- GitLab sees changes, tests only what's needed
- GitHub shows traditional Actions (external view)
- Internal: 5x faster, $0 per execution
- External: looks normal (strategic asymmetry)
