* feat: Implement Claude orchestration provider for parallel session management - Add ClaudeWebhookProvider implementing the webhook provider interface - Create orchestration system for running multiple Claude containers in parallel - Implement smart task decomposition to break complex projects into workstreams - Add session management with dependency tracking between sessions - Support multiple execution strategies (parallel, sequential, wait_for_core) - Create comprehensive test suite for all components - Add documentation for Claude orchestration API and usage This enables super-charged Claude capabilities for the MCP hackathon by allowing multiple Claude instances to work on different aspects of a project simultaneously, with intelligent coordination and result aggregation. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * feat: Add session management endpoints for MCP integration - Add SessionHandler for individual session CRUD operations - Create endpoints: session.create, session.get, session.list, session.start, session.output - Fix Claude invocation in Docker containers using proper claude chat command - Add volume mounts for persistent storage across session lifecycle - Simplify OrchestrationHandler to create single coordination sessions - Update documentation with comprehensive MCP integration examples - Add comprehensive unit and integration tests for new endpoints - Support dependencies and automatic session queuing/starting This enables Claude Desktop to orchestrate multiple Claude Code sessions via MCP Server tools. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * fix: Update ClaudeWebhookProvider validation for session endpoints - Make project fields optional for session management operations - Add validation for session.create requiring session field - Update tests to match new validation rules - Fix failing CI tests 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * fix: Use Promise.reject for validation errors in parsePayload - Convert synchronous throws to Promise.reject for async consistency - Fixes failing unit tests expecting rejected promises 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * fix: Mock SessionManager in integration tests to avoid Docker calls in CI - Add SessionManager mock to prevent Docker operations during tests - Fix claude-webhook.test.ts to use proper test setup and payload structure - Ensure all integration tests can run without Docker dependency - Fix payload structure to include 'data' wrapper 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * fix: Mock child_process to prevent Docker calls in CI tests - Mock execSync and spawn at child_process level to prevent any Docker commands - This ensures tests work in CI environment without Docker - Tests now pass both locally and in CI Docker build 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com> * fix: Address PR review comments and fix linter warnings - Move @types/uuid to devDependencies - Replace timestamp+Math.random with crypto.randomUUID() for better uniqueness - Extract magic number into EXTRA_SESSIONS_COUNT constant - Update determineStrategy return type to use literal union - Fix unnecessary optional chaining warnings - Handle undefined labels in GitHub transformers - Make TaskDecomposer.decompose synchronous - Add proper eslint-disable comments for intentional sync methods - Fix all TypeScript and formatting issues * fix: Mock SessionManager in integration tests to prevent Docker calls in CI - Add SessionManager mocks to claude-session.test.ts - Add SessionManager mocks to claude-webhook.test.ts - Prevents 500 errors when running tests in CI without Docker - All integration tests now pass without requiring Docker runtime * fix: Run only unit tests in Docker builds to avoid Docker-in-Docker issues - Change test stage to run 'npm run test:unit' instead of 'npm test' - Skips integration tests that require Docker runtime - Prevents CI failures in Docker container builds - Integration tests still run in regular CI workflow * fix: Use Dockerfile CMD for tests in Docker build CI - Remove explicit 'npm test' command from docker run - Let Docker use the CMD defined in Dockerfile (npm run test:unit) - This ensures consistency and runs only unit tests in Docker builds --------- Co-authored-by: Claude <noreply@anthropic.com>
Claude Webhook Testing Framework
This directory contains the test framework for the Claude Webhook service. The tests are organized into three categories: unit tests, integration tests, and end-to-end (E2E) tests.
Test Organization
/test
/unit # Unit tests for individual components
/controllers # Tests for controllers
/services # Tests for services
/security # Security-focused tests
/utils # Tests for utility functions
/integration # Integration tests between components
/github # GitHub integration tests
/claude # Claude API integration tests
/aws # AWS credential tests
/e2e # End-to-end tests
/scripts # Shell scripts and helpers for E2E tests
/scenarios # Jest test scenarios for E2E testing
Running Tests
All Tests
npm test
Specific Test Types
# Run only unit tests
npm run test:unit
# Run only integration tests
npm run test:integration
# Run only E2E tests
npm run test:e2e
# Run tests with coverage
npm run test:coverage
# Run tests in watch mode (for development)
npm run test:watch
Test Types
Unit Tests
Unit tests focus on testing individual components in isolation. They use Jest's mocking capabilities to replace dependencies with test doubles. These tests are fast and reliable, making them ideal for development and CI/CD pipelines.
Chatbot Provider Tests
The chatbot provider system includes comprehensive unit tests for:
- Base Provider Interface (
ChatbotProvider.test.js): Tests the abstract base class and inheritance patterns - Discord Provider (
DiscordProvider.test.js): Tests Discord-specific webhook handling, signature verification, and message parsing - Provider Factory (
ProviderFactory.test.js): Tests dependency injection and provider management - Security Tests (
signature-verification.test.js): Tests webhook signature verification and security edge cases - Payload Tests (
discord-payloads.test.js): Tests real Discord webhook payloads and edge cases
Example:
// Test for DiscordProvider.js
describe('Discord Provider', () => {
test('should parse Discord slash command correctly', () => {
const payload = { type: 2, data: { name: 'claude' } };
const result = provider.parseWebhookPayload(payload);
expect(result.type).toBe('command');
});
});
Integration Tests
Integration tests verify that different components work together correctly. They test the interactions between services, controllers, and external systems like GitHub and AWS.
Example:
// Test for GitHub webhook processing
describe('GitHub Webhook Processing', () => {
test('should process a comment with @MCPClaude mention', async () => {
const response = await request(app).post('/api/webhooks/github').send(webhookPayload);
expect(response.status).toBe(200);
});
});
E2E Tests
End-to-end tests verify that the entire system works correctly from start to finish. These tests often involve setting up Docker containers, simulating webhook events, and verifying that Claude responds correctly.
E2E tests are organized into:
- Scripts: Helper scripts for setting up test environments
- Scenarios: Jest tests that use the helper scripts to run E2E tests
Example:
// Test for Claude container execution
describe('Container Execution E2E Tests', () => {
test('Should process a simple Claude request', async () => {
const response = await axios.post('/api/claude', {
command: 'Hello Claude',
repoFullName: 'test-org/test-repo'
});
expect(response.status).toBe(200);
});
});
Shell Scripts
The original shell scripts in /test are being gradually migrated to the new testing framework. Several one-off and debug scripts have been removed to clean up the codebase. The remaining shell scripts serve two purposes:
-
E2E Infrastructure Tests: Scripts that test container/environment configurations and will remain as separate scripts:
test-claude-direct.sh- Tests direct Claude container executiontest-firewall.sh- Tests firewall initializationtest-container-privileged.sh- Tests container privilegestest-full-flow.sh- Tests complete workflow
-
Helper Scripts: Scripts that are used by the E2E Jest tests:
test-basic-container.sh- Used by setupTestContainer.jstest-claude-no-firewall.sh- Used by setupTestContainer.js
Writing New Tests
When writing new tests:
- Determine the appropriate test type (unit, integration, or E2E)
- Place the test in the correct directory
- Follow the naming convention:
*.test.js - Use Jest's mocking capabilities to isolate the component under test
- Write clear, descriptive test names
- Keep tests focused and maintainable
Test Coverage
Run npm run test:coverage to generate a coverage report. The report will show which parts of the codebase are covered by tests and which are not.
CI/CD Integration
The tests are designed to run in a CI/CD pipeline. The Jest configuration includes support for JUnit output via jest-junit, which can be used by CI systems like Jenkins, GitHub Actions, or CircleCI.