Skip to main content

Testing Philosophy

Autonome follows a pragmatic testing approach focused on:
  • Critical path coverage: Test core trading logic, calculations, and data integrity
  • No bandaid fixes: Tests should validate real behavior, not workarounds
  • Edge case exhaustion: Think through failure scenarios before finalizing code
  • Type safety first: Strict TypeScript and Zod validation catch many issues at compile time
From AGENTS.md: “Before finalizing any code, strictly ‘stress test’ your solution mentally. Recursively generate failure scenarios and fix them immediately. Do not stop until you cannot find a way for the code to fail.”

Test Framework

Autonome uses Vitest as its test runner, chosen for:
  • Native ESM support
  • Fast execution with Bun runtime
  • Compatible with Vite ecosystem
  • Jest-like API for familiarity
  • Built-in TypeScript support

Running Tests

Test Structure

Tests are colocated with source code using the .test.ts or .test.tsx suffix:

Testing Patterns

Unit Tests: Trading Calculations

Test pure functions with deterministic outputs:

Integration Tests: Database Operations

Test repository patterns and database queries:

Component Tests: React Testing Library

Test UI components with React Testing Library:

Testing Critical Business Logic

Trading Calculations

These functions are critical and require comprehensive test coverage:
  • calculateUnrealizedPnl() - Position P&L calculation
  • calculateSharpeRatio() - Risk-adjusted return metrics
  • calculateMaxDrawdown() - Portfolio risk measurement
  • calculateWinRate() - Trading performance metrics
  • calculateExpectancy() - Expected value per trade
Test cases must include:
  • Positive and negative values
  • Zero/empty inputs
  • Edge cases (division by zero, very large numbers)
  • Different position sides (BUY/SELL)
  • Precision handling for monetary values

Data Validation

Use Zod schemas for input validation:

Manual QA Workflow

Pre-Deployment Checklist

Before deploying changes, perform manual testing:

1. Environment Validation

2. Simulated Trading Test

Test scenarios:
  • Create positions via simulator
  • Verify position appears in dashboard
  • Check P&L calculations update with price changes
  • Test exit plan execution (stop loss, take profit)
  • Confirm trade history records closed positions

3. Database Schema Verification

Verify:
  • Table names use quoted identifiers ("Models", "Orders")
  • Monetary fields stored as TEXT
  • IDs are TEXT (UUID format)
  • Exit plans stored as JSONB
  • Foreign key relationships intact

4. API Endpoint Testing

Test oRPC procedures:

5. Real-Time Updates (SSE)

Verify Server-Sent Events:
Verify:
  • Position updates stream every 3 seconds
  • New trades trigger immediate events
  • Frontend invalidates TanStack Query cache on events

Browser Testing

Test in multiple browsers:
  • Chrome/Chromium (primary)
  • Firefox (secondary)
  • Safari (if on macOS)
Test key flows:
  1. Dashboard loads with portfolio summary
  2. Position filters work (All/Apex/Trendsurfer/Contrarian/Sovereign)
  3. Charts render correctly (portfolio history, drawdown)
  4. Model chat tab shows AI reasoning
  5. Exit plans display stop/target/invalidation levels
  6. Dark mode toggle works

Performance Testing

Check for regressions:
Metrics to monitor:
  • Initial page load < 2s
  • Time to Interactive (TTI) < 3s
  • SSE update latency < 100ms
  • TanStack Query cache hit rate > 80%

Testing Best Practices

Do’s

✅ Test behavior, not implementation
✅ Use descriptive test names
✅ Test edge cases explicitly
✅ Use test data builders

Don’ts

❌ Don’t write defensive tests for non-issues
❌ Don’t test external libraries
❌ Don’t use mocks unless necessary
❌ Don’t skip cleanup in integration tests

CI/CD Integration

GitHub Actions Workflow

Coverage Goals

Coverage is not a goal in itself. Focus on testing critical paths and edge cases rather than chasing 100% coverage everywhere.

Debugging Tests

Debug in VS Code

Add to .vscode/launch.json:

Console Logging

Isolate Failing Tests

Next Steps

  • Write your first test: Follow the patterns above to add tests for new features
  • Run tests regularly: Use bun run test --watch during development
  • Learn code style: See Code Style for Biome configuration
  • Contribute: Review Contributing Guidelines for the full workflow
When in doubt, ask yourself: “What could break?” Then write a test that proves it won’t.