3e61d26235
* fix: resolve path resolution issues in parse-prd and analyze-complexity commands This commit fixes critical path resolution regressions where commands were requiring files they create to already exist. ## Changes Made: ### 1. parse-prd Command (Lines 808, 828-835, 919-921) **Problem**: Command required tasks.json to exist before it could create it (catch-22) **Root Cause**: Default value in option definition meant options.output was always set **Fixes**: - Removed default value from --output option definition (line 808) - Modified initTaskMaster to only include tasksPath when explicitly specified - Added null handling for output path with fallback to default location ### 2. analyze-complexity Command (Lines 1637-1640, 1673-1680, 1695-1696) **Problem**: Command required complexity report file to exist before creating it **Root Cause**: Default value in option definition meant options.output was always set **Fixes**: - Removed default value from --output option definition (lines 1637-1640) - Modified initTaskMaster to only include complexityReportPath when explicitly specified - Added null handling for report path with fallback to default location ## Technical Details: The core issue was that Commander.js option definitions with default values always populate the options object, making conditional checks like `if (options.output)` always true. By removing default values from option definitions, we ensure paths are only included in initTaskMaster when users explicitly provide them. This approach is cleaner than using boolean flags (true/false) for required/optional, as it eliminates the path entirely when not needed, letting initTaskMaster use its default behavior. ## Testing: - parse-prd now works on fresh projects without existing tasks.json - analyze-complexity creates report file without requiring it to exist - Commands maintain backward compatibility when paths are explicitly provided Fixes issues reported in PATH-FIXES.md and extends the solution to other affected commands. * fix: update expand-task test to match context gathering fix The test was expecting gatheredContext to be a string, but the actual implementation returns an object with a context property. Updated the ContextGatherer mock to return the correct format and added missing FuzzyTaskSearch mock. --------- Co-authored-by: Ben Vargas <ben@example.com>
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