Test Framework
ClawControl uses Vitest as its test framework. Vitest is a fast, Vite-native unit test framework with a Jest-compatible API.Configuration
Test configuration is defined invitest.config.ts:
Key Settings
- globals: true - Import
describe,it,expect, etc. without explicit imports - environment: “node” - Tests run in a Node.js environment (not browser)
- include - Only files matching
tests/**/*.test.tsare executed
Running Tests
Run All Tests
vitest run.
Watch Mode
For development with auto-rerun on file changes:Run Specific Tests
Run tests matching a pattern:Coverage
Generate coverage report:Test Organization
Tests are located in thetests/ directory, mirroring the src/ structure:
File Naming Convention
Test files follow the pattern:hetzner.test.ts- Tests forsrc/providers/hetzner/api.tsdigitalocean.test.ts- Tests forsrc/providers/digitalocean/api.ts
Test Structure
Tests use thedescribe/it structure from Vitest:
Example Tests
Provider API Tests
Tests for cloud provider API clients mock HTTP requests usingvi.fn():
Hetzner Client Test (tests/providers/hetzner.test.ts)
DigitalOcean Client Test (tests/providers/digitalocean.test.ts)
Testing Async Operations
Many provider operations are asynchronous. Useasync/await in tests:
Testing Error Handling
Test that errors are properly thrown and handled:Mocking
Mock Functions
Usevi.fn() to create mock functions:
Mock Implementations
Provide custom implementations for mocks:Mock Global fetch
Provider tests mockglobalThis.fetch:
Test Coverage
Current test coverage focuses on:Provider APIs
-
Hetzner Cloud API (
tests/providers/hetzner.test.ts)- API key validation
- SSH key management (create, list, delete)
- Server operations (create, get, delete, wait for ready)
- Server types and locations
- Action polling
- Error handling
-
DigitalOcean API (
tests/providers/digitalocean.test.ts)- API token validation
- SSH key management
- Droplet operations (create, get, delete, wait for active)
- Power actions (power on/off, reboot, shutdown)
- Sizes and regions
- Error handling
Future Test Coverage
Areas to expand test coverage:- Services layer - Config management, SSH operations, deployment orchestration
- Components - View rendering and interactions (requires TUI testing utilities)
- Integration tests - Full deployment workflow
- E2E tests - CLI commands and user flows
Writing New Tests
For Provider APIs
- Create
tests/providers/{provider}.test.ts - Import the client class
- Mock
globalThis.fetchinbeforeEach - Test each method:
- Happy path (success)
- Error cases (4xx, 5xx)
- Edge cases (timeouts, retries)
- Restore mocks in
afterEach
For Services
- Create
tests/services/{service}.test.ts - Mock file system operations if needed (
vi.mock('node:fs')) - Test business logic in isolation
- Verify function calls and return values
Best Practices
- Test one thing per test - Each
it()block should test a single behavior - Use descriptive names - Test names should explain what is being tested
- Arrange, Act, Assert - Structure tests with setup, execution, verification
- Mock external dependencies - Don’t make real API calls or file system changes
- Clean up after tests - Restore mocks and clear state in
afterEach - Test error paths - Don’t just test the happy path
Continuous Integration
When setting up CI/CD:Next Steps
- Set up your Development Environment
- Understand the Architecture
- Contribute tests for uncovered areas
- Check the CLI Reference for command implementation details