Skip to content

CLAUDE.md

Latest commit

 

History

History
51 lines (41 loc) · 2.4 KB

CLAUDE.md

File metadata and controls

51 lines (41 loc) · 2.4 KB

Agent Guidelines for Workflow Project

Build & Test Commands

  • Build: npm run build (TypeScript compilation with clean)
  • Type Check: npm run typecheck (no emit, type checking only)
  • Test: npm test (runs borp test runner on all packages)
  • Single Test: cd packages/<package> && npm test <file>.spec.ts

Project Structure

  • Monorepo with workspaces in packages/ (core, engine-mongodb, engine-rabbitmq, engine-redis, fastify)
  • TypeScript with composite project references
  • Each package has its own package.json and tsconfig.json

Code Style

  • TypeScript: Strict mode enabled, ES2023 target, CommonJS modules
  • Imports: Use named imports, organize by external/internal
  • Types: Explicit typing, use interfaces for objects, type aliases for unions
  • Naming: camelCase for variables/functions, PascalCase for types/classes
  • Files: kebab-case for files, .spec.ts for tests
  • Error Handling: Use Result types or explicit error handling patterns
  • Testing: Use borp test runner, descriptive test names

Key Patterns

  • Plugin-based architecture with dependency injection
  • Workflow state management with storage abstraction
  • Type-safe step definitions with context passing

Resilience Testing Rules

Test Structure

  • Use Given/When/Then structure for clear test organization and readability
  • Test naming: Use should be able to [capability] format (e.g., "should be able to produce in the queue after connection was lost")

Connection Loss Simulation

  • Always use toxiproxy for simulating network outages/connection issues
  • Never stop/start containers for connection simulation as it prevents test parallelization
  • Create individual proxies for each test case to ensure proper isolation
  • Use toxics (bandwidth limitation, latency injection, etc.) for realistic network failure simulation

Test Execution

  • Ensure parallelizability - tests must be able to run concurrently
  • Proper cleanup - always clean up proxies and toxics in test teardown
  • Extended timeouts - account for container startup and network simulation delays

Benefits of This Approach

  • Faster test execution (no container restarts)
  • Better CI/CD performance through parallel execution
  • More realistic network failure scenarios
  • Better test isolation and reliability

These rules will be applied to all future resilience and network failure testing scenarios.