home / skills / hotovo / aider-desk / writing-tests

writing-tests skill

safe

This skill helps you write reliable Vitest tests for unit, component, and mock patterns across your codebase, boosting confidence and maintainability.

npx playbooks add skill hotovo/aider-desk --skill writing-tests

Review the files below or copy the command above to add this skill to your agents.

Files (9)

SKILL.md

1.7 KB

---
name: Writing Tests
description: Comprehensive guide for writing unit tests, integration tests, and component tests in AiderDesk using Vitest. Use when creating new tests, configuring mocks, or organizing test files.
---

# Writing Tests

Write effective tests using Vitest and React Testing Library.

## Quick Start

Create a unit test in `src/common/__tests__/utils/math.test.ts`:

```typescript
import { describe, it, expect } from 'vitest';
import { add } from '../../utils/math';

describe('math utility', () => {
  it('adds two numbers correctly', () => {
    expect(add(1, 2)).toBe(3);
  });
});
```

Run tests with `npm run test`.

## Core Patterns

### Unit Testing
Focus on pure functions and logic in `src/main` or `src/common`. Use `vi.mock()` for dependencies.
- [references/unit-testing-examples.md](references/unit-testing-examples.md)

### Component Testing
Test React components in `src/renderer`. Focus on user interactions and props.
- [references/component-testing-patterns.md](references/component-testing-patterns.md)

### Mocking
Use centralized mock factories for consistent testing across components and contexts.
- [references/mocking-guide.md](references/mocking-guide.md) - Mock factories and API patterns

## Advanced Usage

For detailed information:
- [references/test-organization.md](references/test-organization.md) - Directory structure and naming
- [references/running-tests.md](references/running-tests.md) - CLI commands and coverage
- [references/best-practices.md](references/best-practices.md) - Principles and patterns
- [references/test-patterns.md](references/test-patterns.md) - Code templates
- [assets/test-checklist.md](assets/test-checklist.md) - Pre-flight checklist

Overview

This skill is a practical guide for writing unit, integration, and component tests in AiderDesk using Vitest and React Testing Library. It explains where to place tests, how to mock dependencies, and how to run test suites. The goal is to help engineers create reliable, maintainable tests that verify logic and user interactions.

How this skill works

It inspects code structure and recommends patterns for unit tests (pure functions), component tests (React UI and user events), and integration tests that span modules. It shows when to use vi.mock and centralized mock factories and points to organization and CLI practices for running tests and collecting coverage. Examples include basic test templates and file naming conventions for TypeScript projects.

When to use it

When adding tests for pure functions in src/common or src/main
When testing React components and user interactions in src/renderer
When configuring mocks for external modules or APIs
When organizing test files and naming conventions for scalability
When setting up CI test runs and coverage reports

Best practices

Keep unit tests focused on pure logic; avoid heavy DOM setup
Use React Testing Library for component behavior and accessibility assertions
Centralize mock factories so mocks are consistent across tests
Name test files near the code they cover and follow a predictable directory structure
Run tests locally with npm run test and include coverage checks in CI

Example use cases

Add a unit test for a math utility function that verifies edge cases
Write a component test to assert button clicks trigger expected callbacks
Mock an API client with a factory to simulate success and error responses
Organize tests into __tests__ folders next to their modules for discoverability
Create an integration test that verifies data flows across modules

FAQ

Should I mock everything in component tests?

No. Mock external dependencies that are slow or brittle, but prefer real behavior for internal modules when it improves confidence in the UI.

Where do I put new tests?

Place unit tests next to their module in src/common or src/main. Put component tests in src/renderer and follow the project naming conventions for discoverability.