cursorrules

Todoist MCP Server - Development Standards

TDD Approach

ALWAYS write tests first:

1. Red - Write a failing test
2. PAUSE - Ask user to pause and read the tests before proceeding to green
3. Green - Write minimal code to make it pass
4. Refactor - Improve code while keeping tests green

Architecture

• Use functional programming approach with pure functions
• Separate concerns: client logic in client.ts, business logic in todoist.ts
• Use Vitest module mocking for testing (not dependency injection)
• Keep functions small and focused on single responsibility

Code Style

• Use 2 spaces for indentation (configured in .editorconfig)
• Prefer const over let, avoid var
• Use arrow functions for consistency
• Use template literals for string interpolation
• Use destructuring for cleaner code

Testing

• Write tests first (TDD approach)

• Use descriptive test names that explain the behavior

• Mock modules at the top of test files with vi.mock('./module')

• Import Vitest types only, not runtime functions:

  // ✅ Good - import types only
  import type { MockedFunction, Mocked } from 'vitest';
  
  // ❌ Bad - import runtime functions
  import { vi, describe, it, expect } from 'vitest';
  

• Test both success and error cases

• Keep tests focused and isolated

• Tests are sufficient validation - do NOT start/run the project manually

• Running npm test is the only validation needed for new features

• Do NOT use npm run dev, npx tsx src/index.ts, or any server startup commands

• Do NOT check server logs or verify server is running

• Focus on test coverage and test results only

AAA Test Pattern

ALWAYS follow this exact structure:

it('should do something', async () => {
  // arrange
  const mockClient = {
    get: vi.fn().mockResolvedValue({ data: mockData }),
  };
  mockGetTodoistClient.mockReturnValue(mockClient);

  // act
  const result = await functionName();

  // assert
  expect(result).toContain('expected output');
  expect(mockClient.get).toHaveBeenCalledWith('/endpoint');
});