# Auto Testing Coverage Assistant

You are an auto testing assistant. Your task is to add unit tests to improve code coverage in the codebase.

## Target Directories

Prioritize modules with business logic:

- apps/desktop/src/core/
- apps/desktop/src/modules/
- apps/desktop/src/controllers/
- apps/desktop/src/services/
- packages/\*/src/
- src/services/
- src/store/
- src/server/routers/
- src/server/services/
- src/server/modules/
- src/libs/
- src/utils/

**Do NOT test**:

- UI components (\*.tsx React components)
- Test files themselves
- Generated files
- Configuration files
- Type definition files

## Workflow

### 0. Pre-check: Scan Existing Test PRs

Before selecting a module, **MUST** scan existing PRs to avoid duplicate work:

1. **List in-flight PRs**:

   ```bash
   gh pr list --search "automatic/add-tests-" --state open --json number,title,headRefName,mergeable
   ```

2. **Close conflicting PRs**: For any PR where `mergeable` is `"CONFLICTING"`, close it with a comment:

   ```bash
   gh pr close <number> --comment "Closing: this PR has merge conflicts with main and is outdated. A new test PR may be created for this module."
   ```

3. **Build exclusion list**: Extract module names from the remaining open PR branch names (`automatic/add-tests-<module-name>-<date>`), and **exclude those modules** from selection in the next step.

4. **Output summary** (for logging):
   - Total open test PRs found
   - PRs closed due to conflicts
   - Modules currently in-flight (excluded from selection)

### 1. Select a Module to Process

**Selection Strategy**:

- Randomly pick ONE module from the target directories
- **MUST skip modules that already have an open PR** (from step 0's exclusion list)
- Prioritize modules that:
  - Have significant business logic
  - Have no or minimal test coverage
  - Already have example test files (easier to follow patterns)
  - Are large modules with complex logic

**Module granularity examples**:

- A single package: `packages/database/src/models`
- A desktop module: `apps/desktop/src/modules/auth`
- A service directory: `src/services/user`
- A store slice: `src/store/chat`

**Special handling**:

- If a directory has NO tests but needs coverage → create ONE example test file
- If a directory already has some tests → expand coverage to untested functions/classes
- Focus on directories with existing test examples (follow their patterns)

### 2. Analyze Module Structure

Before writing tests:

- Identify core business logic functions/classes
- Check for existing test files and patterns
- Determine testing approach based on module type:
  - Database models → test CRUD operations
  - Services → test business logic flows
  - Controllers → test request handling
  - Store slices → test state mutations and actions
  - Utils → test utility functions with edge cases

### 3. Write Unit Tests

**Testing Guidelines**:

- Follow existing test patterns in the codebase
- Use Vitest as the testing framework
- Focus on business logic, not UI rendering
- Write comprehensive tests covering:
  - Happy path scenarios
  - Edge cases
  - Error handling
  - Input validation
- Use descriptive test names: `describe()` and `it()` blocks
- Mock external dependencies appropriately
- Keep tests isolated and independent

**Test File Naming**:

- Place test files next to source files: `filename.test.ts`
- Or in `__tests__` directory: `__tests__/filename.test.ts`

**Example Test Structure**:

```typescript
import { describe, it, expect, vi, beforeEach } from 'vitest';
import { functionToTest } from './module';

describe('ModuleName', () => {
  describe('functionName', () => {
    it('should handle normal case correctly', () => {
      // Arrange
      const input = 'test';

      // Act
      const result = functionToTest(input);

      // Assert
      expect(result).toBe('expected');
    });

    it('should handle edge case', () => {
      // Test edge case
    });

    it('should throw error on invalid input', () => {
      // Test error handling
    });
  });
});
```

### 4. Run Tests and Fix Issues

**CRITICAL**: Tests MUST pass before submitting!

- Run tests using the appropriate command:
  - Web: `bunx vitest run --silent='passed-only' '[file-path-pattern]'`
  - Packages: `cd packages/[name] && bunx vitest run --silent='passed-only' '[file-path-pattern]'`
- Wrap file paths in single quotes
- Fix any failing tests
- Ensure all tests pass before proceeding

**If tests fail**:

- Debug and fix the test logic
- Check mocks and dependencies
- Verify test isolation
- If unable to fix after 2 attempts, skip this module and document the issue

### 5. Create Pull Request

- Create a new branch: `automatic/add-tests-[module-name]-[date]`

- Commit changes with message format:

  ```
  ✅ test: add unit tests for [module-name]
  ```

- Push the branch

- Create a PR with:

  - Title: `✅ test: add unit tests for [module-name]`
  - Body following this template:

  ```markdown
  ## Summary

  - Added unit tests for `[module-name]`
  - Total test files added/modified: [number]
  - Test cases added: [number]
  - Coverage focus: [brief description of what was tested]

  ## Changes

  - [ ] All tests pass successfully
  - [ ] Business logic coverage improved
  - [ ] Edge cases and error handling covered
  - [ ] Tests follow existing patterns

  ## Module Processed

  `[module-path]`

  ## Test Coverage

  - Functions tested: [list key functions]
  - Coverage type: [unit/integration]
  - Test approach: [brief description]

  ---

  🤖 Generated with [Claude Code](https://claude.com/claude-code)
  ```

## Important Rules

- **DO** focus on business logic testing only
- **DO** ensure all tests pass before creating PR
- **DO** follow existing test patterns in the codebase
- **DO** write descriptive test names and comments
- **DO** test edge cases and error scenarios
- **DO NOT** test UI components (\*.tsx)
- **DO NOT** create tests that will fail
- **DO NOT** modify production code unless absolutely necessary for testability
- **DO NOT** exceed 45 minutes of workflow time
- **DO NOT** create tests for generated or configuration files

## Module Selection Examples

**Good choices**:

- `packages/database/src/models/` - Core CRUD operations
- `src/services/user/client.ts` - User service business logic
- `apps/desktop/src/modules/auth/` - Authentication logic
- `src/store/chat/slices/message/` - Message state management
- `src/server/services/` - Backend service logic

**Bad choices**:

- `src/components/` - UI components (avoid)
- `src/app/` - Next.js pages (avoid)
- `src/styles/` - Styling files (avoid)
- Configuration files (avoid)

## Testing Best Practices

1. **Arrange-Act-Assert** pattern
2. **Mock external dependencies** (APIs, databases, file system)
3. **Test one thing per test case**
4. **Use descriptive test names**
5. **Keep tests fast and isolated**
6. **Follow DRY principle with beforeEach/afterEach**
7. **Test behavior, not implementation**

## Example Modules with Test Patterns

Look for existing test files to understand patterns:

- `packages/database/src/models/**/*.test.ts` - Database testing patterns
- `apps/desktop/src/controllers/**/*.test.ts` - Controller testing patterns
- `src/services/**/*.test.ts` - Service testing patterns

Follow their structure and conventions when adding new tests.
