Config Structure Changes and Gateway Integration ## Configuration Structure Changes - Restructured .taskmasterconfig to use 'account' section for user settings - Moved userId, userEmail, mode, telemetryEnabled from global to account section - API keys remain isolated in .env file (not accessible to AI) - Enhanced getUserId() to always return value, never null (sets default '1234567890') ## Gateway Integration Enhancements - Updated registerUserWithGateway() to accept both email and userId parameters - Enhanced /auth/init endpoint integration for existing user validation - API key updates automatically written to .env during registration process - Improved user identification and validation flow ## Code Updates for New Structure - Fixed config-manager.js getter functions for account section access - Updated user-management.js to use config.account.userId/mode - Modified telemetry-submission.js to read from account section - Added getTelemetryEnabled() function with proper account section access - Enhanced telemetry configuration reading with new structure ## Comprehensive Test Updates - Updated integration tests (init-config.test.js) for new config structure - Fixed unit tests (config-manager.test.js) with updated default config - Updated telemetry tests (telemetry-submission.test.js) for account structure - Added missing getTelemetryEnabled mock to ai-services-unified.test.js - Fixed all test expectations to use config.account.* instead of config.global.* - Removed references to deprecated config.subscription object ## Configuration Access Consistency - Standardized configuration access patterns across entire codebase - Clean separation: user settings in account, API keys in .env, models/global in respective sections - All tests passing with new configuration structure - Maintained backward compatibility during transition Changes support enhanced telemetry system with proper user management and gateway integration while maintaining security through API key isolation.
Task Master Test Suite
This directory contains tests for the Task Master CLI. The tests are organized into different categories to ensure comprehensive test coverage.
Test Structure
unit/: Unit tests for individual functions and componentsintegration/: Integration tests for testing interactions between componentse2e/: End-to-end tests for testing complete workflowsfixtures/: Test fixtures and sample data
Running Tests
To run all tests:
npm test
To run tests in watch mode (for development):
npm run test:watch
To run tests with coverage reporting:
npm run test:coverage
Testing Approach
Unit Tests
Unit tests focus on testing individual functions and components in isolation. These tests should be fast and should mock external dependencies.
Integration Tests
Integration tests focus on testing interactions between components. These tests ensure that components work together correctly.
End-to-End Tests
End-to-end tests focus on testing complete workflows from a user's perspective. These tests ensure that the CLI works correctly as a whole.
Test Fixtures
Test fixtures provide sample data for tests. Fixtures should be small, focused, and representative of real-world data.
Mocking
For external dependencies like file system operations and API calls, we use mocking to isolate the code being tested.
- File system operations: Use
mock-fsto mock the file system - API calls: Use Jest's mocking capabilities to mock API responses
Test Coverage
We aim for at least 80% test coverage for all code paths. Coverage reports can be generated with:
npm run test:coverage