e90f822bdd
Overhauls the project root detection system with a hierarchical precedence mechanism that intelligently locates tasks.json and identifies project roots. This improves user experience by reducing the need for explicit path parameters and enhances cross-platform compatibility. Key Improvements: - Implement hierarchical precedence for project root detection: * Environment variable override (TASK_MASTER_PROJECT_ROOT) * Explicitly provided --project-root parameter * Cached project root from previous successful operations * Current directory with project markers * Parent directory traversal to find tasks.json * Package directory as fallback - Create comprehensive PROJECT_MARKERS detection system with 20+ common indicators: * Task Master specific files (tasks.json, tasks/tasks.json) * Version control directories (.git, .svn) * Package manifests (package.json, pyproject.toml, Gemfile, go.mod, Cargo.toml) * IDE/editor configurations (.cursor, .vscode, .idea) * Dependency directories (node_modules, venv, .venv) * Configuration files (.env, tsconfig.json, webpack.config.js) * CI/CD files (.github/workflows, .gitlab-ci.yml, .circleci/config.yml) - DRY refactoring of path utilities: * Centralize path-related functions in core/utils/path-utils.js * Export PROJECT_MARKERS as a single source of truth * Add caching via lastFoundProjectRoot for performance optimization - Enhanced user experience: * Improve error messages with specific troubleshooting guidance * Add detailed logging to indicate project root detection source * Update tool parameter descriptions for better clarity * Add recursive parent directory searching for tasks.json Testing: - Verified in local dev environment - Added unit tests for the progress bar visualization - Updated "automatically detected" description in MCP tools This commit addresses Task #38: Implement robust project root handling for file paths.
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