- Add PathUtils for cross-platform path normalization and validation - Add ErrorMessages with context-aware, actionable error messages - Update all tool implementations with enhanced path handling - Improve tool descriptions for AI agents with detailed guidance - Add Jest testing infrastructure with 43 passing tests - Add comprehensive documentation (Tool Selection Guide, error improvements) - Fix cross-platform path issues (Windows backslashes, case sensitivity) - Fix delete folder error message (clear 'cannot delete folders' message) - Fix parent folder detection with specific error messages - All changes backward compatible with v1.0.0 New files: - src/utils/path-utils.ts - Path normalization utilities - src/utils/error-messages.ts - Enhanced error messages - tests/__mocks__/obsidian.ts - Mock Obsidian API - tests/path-utils.test.ts - 43 unit tests - tests/README.md - Testing guide - jest.config.js - Jest configuration - docs/TOOL_SELECTION_GUIDE.md - Comprehensive tool guide - docs/ERROR_MESSAGE_IMPROVEMENTS.md - Error message documentation - docs/TOOL_DESCRIPTION_IMPROVEMENTS.md - AI agent improvements - PHASE_1.1_IMPLEMENTATION.md - Implementation summary - RELEASE_NOTES_v1.1.0.md - Release notes Updated: - CHANGELOG.md - Add v1.1.0 entry - ROADMAP.md - Mark Phase 1.1 complete, add Phase 1.5 proposal - manifest.json - Bump to v1.1.0 - package.json - Bump to v1.1.0, add test scripts - src/tools/index.ts - Enhanced tool descriptions - src/tools/note-tools.ts - Use PathUtils and ErrorMessages - src/tools/vault-tools.ts - Use PathUtils and ErrorMessages
3.2 KiB
3.2 KiB
Tests
This directory contains unit and integration tests for the Obsidian MCP Server plugin.
Current Status
The test files are currently documentation of expected behavior. To actually run these tests, you need to set up a testing framework.
Setting Up Jest (Recommended)
- Install Jest and related dependencies:
npm install --save-dev jest @types/jest ts-jest
- Create a
jest.config.jsfile in the project root:
module.exports = {
preset: 'ts-jest',
testEnvironment: 'node',
roots: ['<rootDir>/tests'],
testMatch: ['**/*.test.ts'],
moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
collectCoverageFrom: [
'src/**/*.ts',
'!src/**/*.d.ts',
],
};
- Add test script to
package.json:
{
"scripts": {
"test": "jest",
"test:watch": "jest --watch",
"test:coverage": "jest --coverage"
}
}
- Run tests:
npm test
Test Files
path-utils.test.ts
Tests for the PathUtils class, covering:
- Path normalization (cross-platform)
- Path validation
- File/folder resolution
- Path manipulation utilities
Key Test Categories:
- normalizePath: Tests for handling leading/trailing slashes, backslashes, drive letters
- isValidVaultPath: Tests for path validation rules
- Cross-platform: Tests for Windows, macOS, and Linux path handling
Mocking Obsidian API
Since these tests run outside of Obsidian, you'll need to mock the Obsidian API:
// Example mock setup
jest.mock('obsidian', () => ({
App: jest.fn(),
TFile: jest.fn(),
TFolder: jest.fn(),
TAbstractFile: jest.fn(),
// ... other Obsidian types
}));
Running Tests Without Jest
If you prefer not to set up Jest, you can:
- Use the test files as documentation of expected behavior
- Manually test the functionality through the MCP server
- Use TypeScript's type checking to catch errors:
npm run build
Future Improvements
- Set up Jest testing framework
- Add integration tests with mock Obsidian vault
- Add tests for error-messages.ts
- Add tests for tool implementations
- Add tests for MCP server endpoints
- Set up CI/CD with automated testing
- Add code coverage reporting
Test Coverage Goals
- PathUtils: 100% coverage (critical for cross-platform support)
- ErrorMessages: 100% coverage (important for user experience)
- Tool implementations: 80%+ coverage
- Server/middleware: 70%+ coverage
Writing New Tests
When adding new features, please:
- Write tests first (TDD approach recommended)
- Test both success and error cases
- Test edge cases and boundary conditions
- Test cross-platform compatibility where relevant
- Add descriptive test names that explain the expected behavior
Example test structure:
describe('FeatureName', () => {
describe('methodName', () => {
test('should handle normal case', () => {
// Arrange
const input = 'test';
// Act
const result = method(input);
// Assert
expect(result).toBe('expected');
});
test('should handle error case', () => {
expect(() => method(null)).toThrow();
});
});
});