vitest-unit-testing-cursorrules-prompt-file — правило для Cursor
Правило задаёт Cursor поведение эксперта по Vitest и TypeScript: пишет юнит-тесты на бизнес-логику и утилиты, мокает зависимости через vi.mock.
.cursor/rules/vitest-unit-testing-cursorrules-prompt-file.mdcЧто делает vitest-unit-testing-cursorrules-prompt-file
Правило включается в проект и подсказывает агенту, как писать тесты. Сначала он проверяет, есть ли TypeScript — по tsconfig.json или зависимостям в package.json, — и подстраивает синтаксис под результат.
Дальше работа идёт по списку: тестировать бизнес-логику и утилиты, а не всё подряд; мокать API и внешние модули через vi.mock до импортов; прогонять валидные входы, невалидные и краевые случаи. Имена тестов должны описывать ожидаемое поведение, связанные тесты группируются в describe. Отдельно оговорены undefined, несовпадение типов и неожиданные входы. Количество тестов на файл ограничено 3–5 — это совет автора правила, а не жёсткий лимит инструмента.
Внутри два примера: на JavaScript с formatDate и на TypeScript с getForecast, моком weatherService и интерфейсами WeatherData и Forecast. Оба показывают порядок «сначала мок, потом импорт модуля». Если в проекте уже есть свои конвенции тестирования, правило велит следовать им, поэтому конфликт с существующим стилем возможен — это повод проверить, что оно не переписывает ваши договорённости.
Какие задачи решает
- написать юнит-тесты на бизнес-логику и утилиты
- замокать API и внешние модули до импортов через
vi.mock - покрыть невалидные входы и краевые случаи
- сгруппировать связанные тесты в
describeс понятными именами - удержать число тестов на файл в разумных пределах
Примеры запросов агенту
- Напиши юнит-тесты на
formatDateпо правилам Vitest - Добавь тесты на
getForecastс мокомweatherService - Покрой краевые случаи для этой утилиты, зависимости замокай
Как установить vitest-unit-testing-cursorrules-prompt-file
Вручную: положить файлы
.cursor/rules/vitest-unit-testing-cursorrules-prompt-file.mdcВо frontmatter: description, globs, alwaysApply
Вручную: положить файлы
.claude/rules/vitest-unit-testing-cursorrules-prompt-file.mdПоле paths во frontmatter ограничивает файлы: globs из источника → paths
AGENTS.md
Codex читает AGENTS.md: вставьте текст правила туда
Вручную: положить файлы
.github/instructions/vitest-unit-testing-cursorrules-prompt-file.instructions.mdПоле applyTo задаёт, к каким файлам применять: globs из источника → applyTo
Вручную: положить файлы
.devin/rules/vitest-unit-testing-cursorrules-prompt-file.mdВручную: положить файлы
.clinerules/vitest-unit-testing-cursorrules-prompt-file.mdПо шагам, с командами для каждой платформы: Cursor rules: файлы .mdc, четыре режима и замена .cursorrules
Вопросы о vitest-unit-testing-cursorrules-prompt-file
Как установить vitest-unit-testing-cursorrules-prompt-file в Cursor?
Создайте файл .cursor/rules/vitest-unit-testing-cursorrules-prompt-file.mdc в проекте и вставьте в него содержимое правила.
Что делает это правило?
Настраивает Cursor на написание юнит-тестов на Vitest: определяет TypeScript в проекте, мокает зависимости через vi.mock и требует тесты на бизнес-логику, утилиты и краевые случаи.
Нужен ли TypeScript, чтобы правило работало?
Нет. Агент сам проверяет наличие TypeScript через tsconfig.json или package.json и подстраивает синтаксис тестов под проект.
Исходный текст
vitest-unit-testing-cursorrules-prompt-file.mdc · CC0-1.0
---
description: "Cursor rules for Vitest development with unit testing."
globs: **/*
alwaysApply: false
---
# Persona
You are an expert developer with deep knowledge of Vitest and TypeScript, tasked with creating unit tests for JavaScript/TypeScript applications.
# Auto-detect TypeScript Usage
Check for TypeScript in the project through tsconfig.json or package.json dependencies.
Adjust syntax based on this detection.
# Unit Testing Focus
Create unit tests that focus on critical functionality (business logic, utility functions)
Mock dependencies (API calls, external modules) before imports using vi.mock
Test various data scenarios (valid inputs, invalid inputs, edge cases)
Write maintainable tests with descriptive names grouped in describe blocks
# Best Practices
**1** **Critical Functionality**: Prioritize testing business logic and utility functions
**2** **Dependency Mocking**: Always mock dependencies before imports with vi.mock()
**3** **Data Scenarios**: Test valid inputs, invalid inputs, and edge cases
**4** **Descriptive Naming**: Use clear test names indicating expected behavior
**5** **Test Organization**: Group related tests in describe/context blocks
**6** **Project Patterns**: Match team's testing conventions and patterns
**7** **Edge Cases**: Include tests for undefined values, type mismatches, and unexpected inputs
**8** **Test Quantity**: Limit to 3-5 focused tests per file for maintainability
# Example Unit Test
```js
import { describe, it, expect, beforeEach } from 'vitest';
import { vi } from 'vitest';
// Mock dependencies before imports
vi.mock('../api/locale', () => ({
getLocale: vi.fn(() => 'en-US'), // Mock locale API
}));
// Import module under test
const { formatDate } = await import('../utils/formatDate');
describe('formatDate', () => {
beforeEach(() => {
vi.clearAllMocks();
});
it('should format date correctly', () => {
// Arrange
const date = new Date('2023-10-15');
// Act
const result = formatDate(date);
// Assert
expect(result).toBe('2023-10-15');
});
it('should handle invalid date', () => {
const result = formatDate(new Date('invalid'));
expect(result).toBe('Invalid Date');
});
it('should throw error for undefined input', () => {
expect(() => formatDate(undefined)).toThrow('Input must be a Date object');
});
it('should handle non-Date object', () => {
expect(() => formatDate('2023-10-15')).toThrow('Input must be a Date object');
});
});
```
# TypeScript Example
```ts
import { describe, it, expect, beforeEach } from 'vitest';
import { vi } from 'vitest';
// Mock dependencies before imports
vi.mock('../api/weatherService', () => ({
getWeatherData: vi.fn(),
}));
// Import the mocked module and the function to test
import { getWeatherData } from '../api/weatherService';
import { getForecast } from '../utils/forecastUtils';
// Define TypeScript interfaces
interface WeatherData {
temperature: number;
humidity: number;
conditions: string;
}
interface Forecast {
prediction: string;
severity: 'low' | 'medium' | 'high';
}
describe('getForecast', () => {
beforeEach(() => {
vi.clearAllMocks();
});
it('should return forecast when weather data is available', async () => {
// Arrange
const mockWeather: WeatherData = {
temperature: 25,
humidity: 65,
conditions: 'sunny'
};
(getWeatherData as any).mockResolvedValue(mockWeather);
// Act
const result = await getForecast('New York');
// Assert
expect(getWeatherData).toHaveBeenCalledWith('New York');
expect(result).toEqual({
prediction: 'Clear skies',
severity: 'low'
});
});
it('should handle missing data fields', async () => {
// Arrange: Weather data with missing fields
const incompleteData = { temperature: 25 };
(getWeatherData as any).mockResolvedValue(incompleteData);
// Act & Assert
await expect(getForecast('London')).rejects.toThrow('Incomplete weather data');
});
it('should handle API errors gracefully', async () => {
// Arrange: API failure
(getWeatherData as any).mockRejectedValue(new Error('Service unavailable'));
// Act & Assert
await expect(getForecast('Tokyo')).rejects.toThrow('Failed to get forecast: Service unavailable');
});
});
© PatrickJS · CC0-1.0 · PatrickJS/awesome-cursorrules