@tamyla/clodo-framework 4.0.13 → 4.0.14

package/docs/MIDDLEWARE_MIGRATION_SUMMARY.md

@@ -0,0 +1,121 @@
+# Middleware Architecture Migration Summary (v4.1)
+
+## 📌 Purpose
+This document captures the design decisions, implementation details, assumptions, tests, migration steps, and next actions for the contract-first middleware migration (v4.1): moving from per-service concrete middleware implementations (`createServiceMiddleware`) to lightweight middleware contracts with a shared runtime (Registry + Composer).
+
+---
+
+## 🔧 What was implemented
+- Default approach: **contract-first** middleware generation with opt-in `legacy` strategy.
+- New runtime primitives (framework-level):
+  - `src/middleware/Registry.js` - central registry API used in tests and tooling.
+  - `src/middleware/Composer.js` - middleware composer that executes middleware chains with short-circuiting and post-processing.
+  - `src/middleware/types.d.ts` - TypeScript types describing `IServiceMiddleware` and `IMiddlewareChain`.
+  - `src/middleware/shared/` - framework shared middleware: `cors`, `logging`, `basicAuth` (exports in `index.js`).
+- Generator changes:
+  - `ServiceMiddlewareGenerator` now emits either:
+    - A minimal contract class + `registerMiddleware` helper (contract strategy), or
+    - A legacy `createServiceMiddleware` factory (legacy strategy).
+  - Generator also emits a self-contained `src/middleware/runtime.js` and a `src/middleware/shared/` folder when generating services (for self-containment).
+- Worker entry updates:
+  - `WorkerIndexGenerator` updated to import middleware runtime and compose pipeline using `MiddlewareComposer` + `MiddlewareRegistry`.
+  - Worker fetch runtime supports both contract registration and legacy factory via an adapter.
+- Migration tools & tests:
+  - `scripts/migration/migrate-middleware-legacy-to-contract.js` (basic codemod to convert legacy factories to contract skeletons + `registerMiddleware`).
+  - Unit tests added for `Registry`, `Composer`, `shared/cors`, generator outputs, and migration script.
+- CLI:
+  - `cli/commands/create.js` adds `--middleware-strategy <strategy>` CLI flag (default `contract`).
+- Docs & changelog updated:
+  - `docs/HOWTO_CONSUME_CLODO_FRAMEWORK.md` updated to describe the new approach.
+  - `CHANGELOG.md` mentions the v4.1 middleware architecture change.
+
+---
+
+## ✅ Files added / modified (high-level)
+- Added:
+  - `src/middleware/Registry.js`
+  - `src/middleware/Composer.js`
+  - `src/middleware/types.d.ts`
+  - `src/middleware/shared/{cors.js,logging.js,basicAuth.js,index.js}`
+  - `scripts/migration/migrate-middleware-legacy-to-contract.js`
+  - `docs/MIDDLEWARE_MIGRATION_SUMMARY.md` (this file)
+  - Tests: `test/utils/middleware/{Registry,Composer,cors}.test.js`, generator tests and migration test
+- Modified (generators & templates):
+  - `src/service-management/generators/code/ServiceMiddlewareGenerator.js` (now emits contract or legacy output and service-local runtime/shared stubs)
+  - `src/service-management/generators/code/WorkerIndexGenerator.js` (loads middleware using dynamic import and composes pipeline; includes legacy adapter)
+  - `src/service-management/GenerationEngine.js` (passes `middlewareStrategy` through context)
+  - `src/service-management/ServiceOrchestrator.js` & `src/simple-api.js` (accept middleware strategy)
+  - `cli/commands/create.js` (new `--middleware-strategy` option)
+
+---
+
+## 🧭 Key assumptions made
+1. Default strategy is `contract` (opt-in `legacy`).
+2. Generated services are self-contained by default (runtime + shared stubs added into generated service) to work standalone.
+3. Legacy factory shape expected to return object with `processRequest(request)` and `processResponse(response)` methods.
+4. Runtime dynamic import is acceptable in Worker code (`await import('../middleware/service-middleware.js')`).
+5. TypeScript users will later add TS skeletons or `.d.ts` files if they require compile-time checks.
+
+If any of these assumptions are not desirable for your environment, they require small changes (see "Nuances and review points").
+
+---
+
+## ⚠️ Nuances & review points (actionable)
+- Registry duplication:
+  - There are both framework-level `Registry.js` and a service-local `runtime.js` (generated by the generator). Decide whether you want a single shared runtime or per-service runtime. If you prefer a single runtime, update the generator to import the framework runtime rather than generate a local copy.
+- Bundler behavior & dynamic imports:
+  - The dynamic import pattern must be tested with your bundler (esbuild/wrangler). Ensure bundler includes generated middleware files in the built artifact.
+- Adapter coverage:
+  - The legacy adapter covers the common `createServiceMiddleware` factory shape. If your legacy services used other shapes, extend the adapter logic accordingly.
+- TypeScript support:
+  - Generated skeletons are JavaScript; if you primarily use TypeScript, consider adding `.ts` templates and `.d.ts` exports for better DX.
+- Migration tool limitations:
+  - The codemod is intentionally conservative and may require manual editing for complex legacy middleware logic.
+- Security/logging:
+  - The example `logging` middleware uses `console.log` directly—avoid logging sensitive headers. Consider adding redaction configuration.
+
+---
+
+## 🔁 Migration steps (recommended)
+1. Try generating a new service with default (contract) strategy to validate the new flow:
+   - `npx clodo-service create --middleware-strategy contract` (or omit flag — default is `contract`).
+2. To generate an old-style output for a single new service for comparison: `npx clodo-service create --middleware-strategy legacy`.
+3. For existing services using legacy middleware:
+   - Run `node scripts/migration/migrate-middleware-legacy-to-contract.js <servicePath> [serviceName]`.
+   - Review the converted skeleton and verify imports and custom logic—make adjustments as required.
+4. Update tests and CI to include a smoke test that deploys/loads the generated service (both contract and legacy flows).
+
+---
+
+## ✅ Tests & QA to add (if not already present)
+- Integration tests that:
+  - Generate a service with `contract` strategy and verify `registerMiddleware` is invoked and runtime pipeline executes correctly.
+  - Generate a service with `legacy` strategy and verify the legacy adapter path executes `createServiceMiddleware`.
+- Bundle-size smoke test that measures the generated artifact size between legacy and contract strategies.
+- Migration tests on representative real-world legacy middleware shapes.
+
+---
+
+## 📋 Next steps & open todos
+- Complete migration of tests and e2e fixtures that currently rely on legacy middleware.
+- Add TypeScript skeleton templates (optional, recommended for TS-first projects).
+- Decide on runtime model: service-local runtime (current) vs centralized runtime (change generator behavior if you prefer central runtime).
+- Add more robust adapter patterns if you encounter edge-case legacy middleware shapes in the wild.
+
+---
+
+## 📎 Helpful quick references
+- Generator: `src/service-management/generators/code/ServiceMiddlewareGenerator.js`
+- Worker: `src/service-management/generators/code/WorkerIndexGenerator.js`
+- Migration: `scripts/migration/migrate-middleware-legacy-to-contract.js`
+- Runtime: `src/middleware/{Registry.js,Composer.js}`
+- Tests: `test/utils/middleware/*`, `test/service-management/generators/*`, `test/scripts/migration/*`
+
+---
+
+If you'd like, I can now:
+- Finish updating tests/fixtures and add the bundle-size smoke test, or
+- Add TypeScript templates for generated services, or
+- Replace per-service runtime with a centralized runtime (if you prefer that model).
+
+Pick one of the bullets above and I’ll proceed. If you'd like further edits to this summary, I can fold them into this document.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tamyla/clodo-framework",
-  "version": "4.0.13",
+  "version": "4.0.14",
   "description": "Reusable framework for Clodo-style software architecture on Cloudflare Workers + D1",
   "type": "module",
   "sideEffects": [
@@ -31,6 +31,7 @@
     "./security/cli": "./dist/security/SecurityCLI.js",
     "./service-management": "./dist/service-management/index.js",
     "./service-management/create": "./dist/service-management/ServiceCreator.js",
+    "./middleware": "./dist/middleware/index.js",
     "./modules/security": "./dist/modules/security.js"
   },
   "bin": {
@@ -51,6 +52,8 @@
     "docs/overview.md",
     "docs/SECURITY.md",
     "docs/api-reference.md",
+    "docs/MIDDLEWARE_MIGRATION_SUMMARY.md",
+    "scripts",
     "README.md",
     "CHANGELOG.md",
     "LICENSE"

package/scripts/DEPLOY_COMMAND_NEW.js

@@ -0,0 +1,128 @@
+// Deploy command - Smart minimal input for service projects only
+import { program } from 'commander';
+import chalk from 'chalk';
+import { join } from 'path';
+
+program
+  .command('deploy')
+  .description('Deploy a Clodo Framework service to Cloudflare Workers')
+  .option('-e, --env <environment>', 'Target environment (development, staging, production)')
+  .option('--token <token>', 'Cloudflare API token (uses CLOUDFLARE_API_TOKEN env var if not provided)')
+  .option('--account-id <id>', 'Cloudflare account ID (uses CLOUDFLARE_ACCOUNT_ID env var if not provided)')
+  .option('--zone-id <id>', 'Cloudflare zone ID (auto-discovered if not provided)')
+  .option('--dry-run', 'Simulate deployment without making changes')
+  .action(async (options) => {
+    try {
+      const { readFileSync, existsSync } = await import('fs');
+      
+      console.log(chalk.cyan('\n🚀 Clodo Service Deployment'));
+      console.log(chalk.gray('─'.repeat(60)));
+      
+      // ===== STEP 1: SERVICE DETECTION =====
+      // Check if this is a Clodo service project (has clodo-service-manifest.json)
+      const manifestPath = join(process.cwd(), 'clodo-service-manifest.json');
+      
+      if (!existsSync(manifestPath)) {
+        console.error(chalk.red('\n❌ Not a Clodo Framework service project!\n'));
+        console.error(chalk.white('This command must be run from within a service created by the framework.\n'));
+        console.error(chalk.yellow('To create a new service:\n'));
+        console.error(chalk.white('  npx @tamyla/clodo-framework create\n'));
+        console.error(chalk.cyan('To deploy an existing service:\n'));
+        console.error(chalk.white('  1. cd into your service project directory\n'));
+        console.error(chalk.white('  2. Set Cloudflare credentials:\n'));
+        console.error(chalk.white('     export CLOUDFLARE_API_TOKEN=your_token\n'));
+        console.error(chalk.white('     export CLOUDFLARE_ACCOUNT_ID=your_account_id\n'));
+        console.error(chalk.white('  3. Run: npx clodo-service deploy --env production\n'));
+        process.exit(1);
+      }
+      
+      let manifest;
+      try {
+        manifest = JSON.parse(readFileSync(manifestPath, 'utf8'));
+      } catch (err) {
+        console.error(chalk.red(`\n❌ Invalid service manifest: ${err.message}\n`));
+        process.exit(1);
+      }
+      
+      console.log(chalk.green(`✅ Service detected: ${chalk.bold(manifest.serviceName)}`));
+      console.log(chalk.white(`   Type:      ${manifest.serviceType}`));
+      console.log(chalk.white(`   Framework: ${manifest.framework}\n`));
+      
+      // ===== STEP 2: SMART CREDENTIAL GATHERING =====
+      // Gather credentials: from flags > env vars > ask if missing
+      console.log(chalk.cyan('📋 Gathering Deployment Credentials'));
+      console.log(chalk.gray('─'.repeat(60)));
+      
+      // Get environment: from flag > manifest > default to production
+      const environment = options.env || manifest.configuration?.environment || 'production';
+      console.log(chalk.white(`Target environment: ${chalk.bold(environment)}`));
+      
+      // Get Cloudflare token: from flag > env var
+      let token = options.token || process.env.CLOUDFLARE_API_TOKEN;
+      if (!token) {
+        console.error(chalk.red('\n❌ Cloudflare API token required\n'));
+        console.error(chalk.white('Provide via:\n'));
+        console.error(chalk.white('  • Command: npx clodo-service deploy --token <token>\n'));
+        console.error(chalk.white('  • Environment: export CLOUDFLARE_API_TOKEN=<token>\n'));
+        process.exit(1);
+      }
+      console.log(chalk.green(`✅ Cloudflare token: ${token.substring(0, 20)}...`));
+      
+      // Get Cloudflare account ID: from flag > env var
+      let accountId = options.accountId || process.env.CLOUDFLARE_ACCOUNT_ID;
+      if (!accountId) {
+        console.error(chalk.red('\n❌ Cloudflare account ID required\n'));
+        console.error(chalk.white('Provide via:\n'));
+        console.error(chalk.white('  • Command: npx clodo-service deploy --account-id <id>\n'));
+        console.error(chalk.white('  • Environment: export CLOUDFLARE_ACCOUNT_ID=<id>\n'));
+        process.exit(1);
+      }
+      console.log(chalk.green(`✅ Account ID: ${accountId.substring(0, 8)}...`));
+      
+      // Get Cloudflare zone ID: from flag > env var (can be auto-discovered later)
+      let zoneId = options.zoneId || process.env.CLOUDFLARE_ZONE_ID;
+      if (zoneId) {
+        console.log(chalk.green(`✅ Zone ID: ${zoneId.substring(0, 8)}...`));
+      } else {
+        console.log(chalk.yellow('⚠️  Zone ID: Will be auto-discovered from domain'));
+      }
+      
+      // Set environment variables for downstream components
+      process.env.CLOUDFLARE_API_TOKEN = token;
+      process.env.CLOUDFLARE_ACCOUNT_ID = accountId;
+      if (zoneId) {
+        process.env.CLOUDFLARE_ZONE_ID = zoneId;
+      }
+      
+      console.log(chalk.gray('─'.repeat(60)));
+      
+      // ===== STEP 3: INTEGRATION WITH MODULAR DEPLOYER =====
+      // TODO: Import and call ModularEnterpriseDeployer here
+      // For now, show what would happen
+      
+      console.log(chalk.cyan('\n📋 Deployment Plan:'));
+      console.log(chalk.white(`   Service:      ${manifest.serviceName}`));
+      console.log(chalk.white(`   Type:         ${manifest.serviceType}`));
+      console.log(chalk.white(`   Environment:  ${environment}`));
+      console.log(chalk.white(`   Account:      ${accountId.substring(0, 8)}...`));
+      
+      if (options.dryRun) {
+        console.log(chalk.yellow('\n✅ Dry run complete - deployment validated\n'));
+      } else {
+        console.log(chalk.yellow('\n⚠️  Deployment integration with modular deployer pending'));
+        console.log(chalk.white('   See: DEPLOYMENT_SYSTEMS_ANALYSIS.md for architecture\n'));
+      }
+      
+      console.log(chalk.green('✅ Deployment preparation complete\n'));
+      
+    } catch (error) {
+      console.error(chalk.red(`\n❌ Deployment failed: ${error.message}\n`));
+      
+      if (process.env.DEBUG) {
+        console.error(chalk.gray('Stack trace:'));
+        console.error(chalk.gray(error.stack));
+      }
+      
+      process.exit(1);
+    }
+  });

package/scripts/README-automated-testing-suite.md

@@ -0,0 +1,356 @@
+# Clodo Framework Automated Testing Suite
+
+A comprehensive automated testing system for the entire clodo-framework that tests all CLI commands, deployment processes, service lifecycle, integrations, performance, and prevents regressions.
+
+## Overview
+
+The automated testing suite provides systematic testing across multiple categories with **comprehensive coverage of the `clodo-service deploy` command's 3-level input processing**:
+
+- **CLI Tests**: All `clodo-service` commands and help systems
+- **Deployment Tests**: Complete `clodo-service deploy` command validation (Service Detection → Credential Gathering → Configuration Extraction)
+- **Lifecycle Tests**: Complete service create → validate → deploy → update cycle
+- **Integration Tests**: Cross-component functionality and build processes
+- **Performance Tests**: Build and test execution timing
+- **Regression Tests**: Prevention of known issues
+
+## Quick Start
+
+```bash
+# Run all tests (recommended)
+node scripts/automated-testing-suite.js
+
+# Run specific test categories
+node scripts/automated-testing-suite.js cli deployment
+
+# Run with verbose output
+node scripts/automated-testing-suite.js --verbose
+
+# Run only CLI tests
+node scripts/automated-testing-suite.js cli
+```
+
+## Test Categories
+
+### CLI Tests (`cli`)
+Tests all command-line interface functionality:
+- Help commands and usage information
+- Command availability and error handling
+- Option parsing and validation
+
+### Deployment Tests (`deployment`)
+Comprehensive testing of the `clodo-service deploy` command covering all **3 levels of input processing**:
+
+#### Level 1: Service Detection
+- Validates presence of `clodo-service-manifest.json`
+- Tests error handling when manifest is missing
+- Verifies service type and configuration detection
+
+#### Level 2: Credential Gathering
+- Tests credential priority: command flags → environment variables → failure
+- Validates credential validation and error messages
+- Tests different credential input methods (flags, env vars)
+
+#### Level 3: Configuration Extraction
+- Tests manifest parsing and configuration extraction
+- Validates domain, environment, and deployment settings
+- Tests deployment plan generation and validation
+
+**Test Coverage**: 8 deployment tests including real service manifests, credential scenarios, and error conditions.
+
+### Lifecycle Tests (`lifecycle`)
+Tests complete service lifecycle:
+- Service creation with different types
+- Service validation
+- Deployment dry-run testing
+- Service updates and management
+
+### Integration Tests (`integration`)
+Tests cross-component functionality:
+- Full npm test suite execution
+- Build and type checking
+- Linting and unit test integration
+- Dependency validation
+
+### Performance Tests (`performance`)
+Measures system performance:
+- Build execution time
+- Test suite performance
+- Resource usage monitoring
+
+### Regression Tests (`regression`)
+Prevents known issues from reoccurring:
+- Missing dependency detection
+- Build completeness validation
+- CLI command availability
+- Framework integrity checks
+
+## Command Line Options
+
+| Option | Description | Default |
+|--------|-------------|---------|
+| `--test-dir <path>` | Directory for test artifacts | `./test-automation` |
+| `--verbose` | Detailed logging and output | `false` |
+| `--no-clean` | Keep test artifacts after run | `false` (cleans by default) |
+| `--parallel` | Run tests in parallel | `false` (future feature) |
+| `--categories <list>` | Comma-separated categories | `all` |
+| `--timeout <ms>` | Individual test timeout | `300000` (5 minutes) |
+| `--help` | Show help message | - |
+
+## Usage Examples
+
+### Development Testing
+```bash
+# Quick CLI validation during development
+node scripts/automated-testing-suite.js cli --verbose
+
+# Test deployment logic
+node scripts/automated-testing-suite.js deployment
+
+# Full integration test
+node scripts/automated-testing-suite.js integration
+```
+
+### CI/CD Integration
+```bash
+# Run all tests in CI environment
+node scripts/automated-testing-suite.js --verbose --no-clean
+
+# Quick smoke test for PR validation
+node scripts/automated-testing-suite.js cli deployment --timeout 60000
+
+# Performance regression testing
+node scripts/automated-testing-suite.js performance
+```
+
+### Debugging and Investigation
+```bash
+# Isolate failing tests
+node scripts/automated-testing-suite.js cli --verbose
+
+# Test specific functionality
+node scripts/automated-testing-suite.js lifecycle --test-dir ./debug-tests
+
+# Full diagnostic run
+node scripts/automated-testing-suite.js all --verbose --no-clean
+```
+
+## Test Output and Reports
+
+### Console Output
+The suite provides real-time feedback:
+```
+[14:23:15] 🚀 Starting Clodo Framework Automated Testing Suite
+[14:23:15] 🧪 Test Directory: C:\path\to\test-automation
+[14:23:15] 🧪 Categories: all
+[14:23:15] 🧪 Parallel Execution: false
+
+[14:23:15] 🚀 Running CLI Command Tests
+[14:23:15] 🧪 Running: clodo-service --help
+[14:23:15] ✅ clodo-service --help (45ms)
+[14:23:15] 🧪 Running: clodo-service list-types
+[14:23:15] ✅ clodo-service list-types (23ms)
+...
+[14:23:20] 🎉 Automated Testing Suite Complete
+
+📊 Test Summary:
+  Total Tests: 24
+  Passed: 22
+  Failed: 2
+  Skipped: 0
+  Duration: 4521ms
+
+📋 Category Results:
+  cli: ✅ 5/5 passed
+  deployment: ✅ 4/4 passed
+  lifecycle: ❌ 2/3 passed
+  integration: ✅ 3/3 passed
+  performance: ✅ 2/2 passed
+  regression: ✅ 4/4 passed
+```
+
+### Detailed Report
+A JSON report is automatically saved to `test-automation/test-report.json`:
+```json
+{
+  "timestamp": "2025-10-27T14:23:20.000Z",
+  "summary": {
+    "total": 24,
+    "passed": 22,
+    "failed": 2,
+    "skipped": 0,
+    "duration": 4521
+  },
+  "categories": {
+    "cli": {
+      "tests": [...],
+      "passed": 5,
+      "failed": 0
+    }
+  },
+  "failures": [...],
+  "options": {...},
+  "environment": {...}
+}
+```
+
+## Test Environment
+
+### Automatic Setup
+- Creates isolated test directory (`./test-automation` by default)
+- Builds framework if needed
+- Manages temporary test services
+- Cleans up after completion (unless `--no-clean`)
+
+### Test Isolation
+- Each test runs in clean environment
+- Temporary services are tracked and removed
+- No interference with development environment
+- Safe for parallel development
+
+## Integration with Development Workflow
+
+### Pre-commit Hooks
+```bash
+# Add to package.json scripts
+"pre-commit": "node scripts/automated-testing-suite.js cli --timeout 30000"
+```
+
+### CI/CD Pipeline
+```yaml
+# GitHub Actions example
+- name: Run Automated Tests
+  run: node scripts/automated-testing-suite.js --verbose --no-clean
+
+- name: Upload Test Results
+  uses: actions/upload-artifact@v3
+  with:
+    name: test-results
+    path: test-automation/
+```
+
+### Development Scripts
+```json
+{
+  "scripts": {
+    "test:automated": "node scripts/automated-testing-suite.js",
+    "test:cli": "node scripts/automated-testing-suite.js cli",
+    "test:deployment": "node scripts/automated-testing-suite.js deployment",
+    "test:smoke": "node scripts/automated-testing-suite.js cli deployment --timeout 30000"
+  }
+}
+```
+
+## Extending the Test Suite
+
+### Adding New Test Categories
+```javascript
+async runCustomTests() {
+  this.log('Running Custom Tests', 'phase');
+  const category = 'custom';
+  this.testResults.categories[category] = { tests: [], passed: 0, failed: 0 };
+
+  const customTests = [
+    {
+      name: 'my-custom-test',
+      command: 'node my-custom-test.js',
+      expectSuccess: true,
+      description: 'Custom test description'
+    }
+  ];
+
+  for (const test of customTests) {
+    await this.runIndividualTest(category, test);
+  }
+}
+```
+
+### Adding New Tests to Existing Categories
+```javascript
+const cliTests = [
+  // existing tests...
+  {
+    name: 'new-cli-command',
+    command: 'node bin/clodo-service.js new-command --help',
+    expectSuccess: true,
+    description: 'Test new CLI command'
+  }
+];
+```
+
+## Troubleshooting
+
+### Common Issues
+
+**Tests timing out**
+- Increase timeout: `--timeout 600000`
+- Check for hanging processes
+- Run individual categories to isolate
+
+**Permission errors**
+- Ensure script has execute permissions
+- Check file system permissions for test directory
+- Run as appropriate user
+
+**Build failures in tests**
+- Ensure dependencies are installed: `npm install`
+- Check Node.js version compatibility
+- Verify build scripts in package.json
+
+**Test directory conflicts**
+- Use `--test-dir ./custom-test-dir`
+- Remove conflicting directories manually
+- Use `--no-clean` to preserve for debugging
+
+### Debugging Failed Tests
+```bash
+# Run with maximum verbosity
+node scripts/automated-testing-suite.js --verbose --no-clean
+
+# Test individual categories
+node scripts/automated-testing-suite.js cli --verbose
+
+# Check detailed report
+cat test-automation/test-report.json | jq '.failures'
+```
+
+## Performance Considerations
+
+### Test Execution Time
+- **Full suite**: ~3-5 minutes
+- **CLI only**: ~30 seconds
+- **Individual categories**: ~1-2 minutes
+
+### Resource Usage
+- **Memory**: ~100-200MB peak
+- **Disk**: ~50-100MB for test artifacts
+- **Network**: Minimal (mock deployments)
+
+### Optimization Tips
+- Run specific categories for faster feedback
+- Use `--no-clean` during development
+- Parallel execution support (future feature)
+- CI caching for dependencies
+
+## Related Files
+
+- `scripts/test-clodo-deployment.js` - Individual deployment testing
+- `test/` - Unit and integration tests
+- `package.json` - Test scripts and configuration
+- `jest.config.js` - Test framework configuration
+
+## Contributing
+
+When adding new functionality:
+1. Add corresponding tests to the automated suite
+2. Update this documentation
+3. Ensure tests pass in CI/CD
+4. Consider performance impact
+
+## Future Enhancements
+
+- Parallel test execution
+- Web dashboard for results
+- Historical trend analysis
+- Performance regression detection
+- Automated issue creation for failures
+- Integration with external monitoring tools