test-quality-analysis — скилл для Claude Code: обзор и установка
Находит овермокинг, хрупкие ассерты и флакающие тесты в проекте. Скилл помогает при код-ревью тестовых наборов и проверке тестового покрытия.
npx skills add secondsky/claude-skills --skill test-quality-analysis -a claude-codeЧто делает test-quality-analysis
Скилл даёт агенту правила поиска проблемных тестов и антипаттернов. Он проверяет соблюдение структуры AAA (Arrange-Act-Assert) и принципов FIRST, отслеживает гонки в асинхронном коде и слишком общие проверки вроде простого утверждения о наличии объекта.
Для замеров покрытия скилл использует команды bun test --coverage с порогом от 80% строк или uv run pytest --cov для Python. Он также сверяет число моков: если в одном тесте замокано больше 3–4 зависимостей или подменяются чистые функции вместо внешних вызовов, тест признаётся перегруженным.
Правило строго ограничивает изоляцию: мокать разрешено только внешние границы ввода-вывода вроде API или баз данных. Для работы скиллу требуются системные инструменты чтения файлов и запуска терминала Bash, Read и Grep.
Какие задачи решает
- найти избыточные моки и подмену чистых функций
- выявить флакающие тесты с некорректным async/await
- заменить хрупкие DOM-селекторы на семантические
- проверить покрытие критических путей авторизации и оплаты
Примеры запросов агенту
- Проверь тесты в
src/auth/на овермокинг и хрупкие проверки. - Запусти анализ покрытия через Bun и найди непротестированные ветки логики.
- Посмотри этот флакающий тест и исправь гонку в промисах.
Как установить test-quality-analysis
1Через Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill test-quality-analysis -a claude-code2Вручную: положить файлы
~/.claude/skills/test-quality-analysis/SKILL.mdПапка скилла целиком; для одного проекта — .claude/skills/test-quality-analysis/
1Через Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill test-quality-analysis -a codex2Вручную: положить файлы
.agents/skills/test-quality-analysis/SKILL.mdДля всех проектов — ~/.agents/skills/
1Через Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill test-quality-analysis -a cursor2Вручную: положить файлы
.cursor/skills/test-quality-analysis/SKILL.mdCursor читает и .agents/skills/, и .claude/skills/
1GitHub CLI
gh skill install secondsky/claude-skills test-quality-analysis2Вручную: положить файлы
.github/skills/test-quality-analysis/SKILL.md1Через Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill test-quality-analysis -a gemini-cli2Командой платформы
gemini skills install https://github.com/secondsky/claude-skills --path plugins/test-quality-analysis/skills/test-quality-analysisВручную: положить файлы
.devin/skills/test-quality-analysis/SKILL.mdСтарый путь .windsurf/skills/ тоже читается
Через Skills CLI (Vercel)
npx skills add secondsky/claude-skills --skill test-quality-analysis -a opencodeClaude.ai
Упакуйте папку в zip и загрузите в Settings → Capabilities → Skills
По шагам, с командами для каждой платформы: Как установить скилл в Claude Code: пять способов
Вопросы о test-quality-analysis
Как установить test-quality-analysis в Claude Code?
Выполните команду npx skills add secondsky/claude-skills --skill test-quality-analysis -a claude-code. Файл спецификации сохранится в ~/.claude/skills/test-quality-analysis/SKILL.md.
Что делает test-quality-analysis?
Он ищет антипаттерны тестирования: овермокинг, проверку деталей реализации вместо поведения и слабые утверждения. Также скилл контролирует структуру Arrange-Act-Assert.
Какие критерии овермокинга использует скилл?
Тест считается перегруженным, если в нём больше 3–4 моков или мокаются чистые функции и бизнес-логика. Скилл требует мокать только границы ввода-вывода: API, базы данных и файловую систему.
Исходный текст
SKILL.md · MIT
---
name: test-quality-analysis
description: Detect test smells, overmocking, flaky tests, and coverage issues. Analyze test effectiveness, maintainability, and reliability. Use when reviewing tests or improving test quality.
allowed-tools: Bash, Read, Edit, Write, Grep, Glob, TodoWrite
license: MIT
---
# Test Quality Analysis
Expert knowledge for analyzing and improving test quality - detecting test smells, overmocking, insufficient coverage, and testing anti-patterns.
## Core Dimensions
- **Correctness**: Tests verify the right behavior
- **Reliability**: Tests are deterministic, not flaky
- **Maintainability**: Tests are easy to understand
- **Performance**: Tests run quickly
- **Coverage**: Tests cover critical code paths
- **Isolation**: Tests don't depend on external state
## Test Smells
### Overmocking
**Problem**: Mocking too many dependencies makes tests fragile.
```typescript
// ❌ BAD: Overmocked
test('calculate total', () => {
const mockAdd = vi.fn(() => 10)
const mockMultiply = vi.fn(() => 20)
// Testing implementation, not behavior
})
// ✅ GOOD: Mock only external dependencies
test('calculate order total', () => {
const mockPricingAPI = vi.fn(() => ({ tax: 0.1 }))
const total = calculateTotal(order, mockPricingAPI)
expect(total).toBe(38)
})
```
**Detection**: More than 3-4 mocks, mocking pure functions, complex mock setup.
**Fix**: Mock only I/O boundaries (APIs, databases, filesystem).
### Fragile Tests
**Problem**: Tests break with unrelated code changes.
```typescript
// ❌ BAD: Tests implementation details
await page.locator('.form-container > div:nth-child(2) > button').click()
// ✅ GOOD: Semantic selector
await page.getByRole('button', { name: 'Submit' }).click()
```
### Flaky Tests
**Problem**: Tests pass or fail non-deterministically.
```typescript
// ❌ BAD: Race condition
test('loads data', async () => {
fetchData()
await new Promise(resolve => setTimeout(resolve, 1000))
expect(data).toBeDefined()
})
// ✅ GOOD: Proper async handling
test('loads data', async () => {
const data = await fetchData()
expect(data).toBeDefined()
})
```
### Poor Assertions
```typescript
// ❌ BAD: Weak assertion
test('returns users', async () => {
const users = await getUsers()
expect(users).toBeDefined() // Too vague!
})
// ✅ GOOD: Strong, specific assertions
test('creates user with correct attributes', async () => {
const user = await createUser({ name: 'John' })
expect(user).toMatchObject({
id: expect.any(Number),
name: 'John',
})
})
```
## Analysis Tools
```bash
# Vitest coverage (prefer bun)
bun test --coverage
open coverage/index.html
# Check thresholds
bun test --coverage --coverage.thresholds.lines=80
# pytest-cov (Python)
uv run pytest --cov --cov-report=html
open htmlcov/index.html
```
## Best Practices Checklist
### Unit Test Quality (FIRST)
- [ ] **Fast**: Tests run in milliseconds
- [ ] **Isolated**: No dependencies between tests
- [ ] **Repeatable**: Same results every time
- [ ] **Self-validating**: Clear pass/fail
- [ ] **Timely**: Written alongside code
### Mock Guidelines
- [ ] Mock only external dependencies
- [ ] Don't mock business logic or pure functions
- [ ] Use real implementations when possible
- [ ] Limit to 3-4 mocks per test maximum
### Coverage Goals
- [ ] 80%+ line coverage for business logic
- [ ] 100% for critical paths (auth, payment)
- [ ] All error paths tested
- [ ] Boundary conditions tested
### Test Structure (AAA Pattern)
```typescript
test('user registration', async () => {
// Arrange
const userData = { email: '[email protected]' }
// Act
const user = await registerUser(userData)
// Assert
expect(user.email).toBe('[email protected]')
})
```
## Code Review Checklist
- [ ] Tests verify behavior, not implementation
- [ ] Assertions are specific and meaningful
- [ ] No flaky tests (timing, ordering issues)
- [ ] Proper async/await usage
- [ ] Test names clearly describe behavior
- [ ] Minimal code duplication
- [ ] Critical paths have tests
- [ ] Both happy path and error cases covered
## Common Anti-Patterns
### Testing Implementation Details
```typescript
// ❌ BAD
const spy = vi.spyOn(Math, 'sqrt')
calculateDistance()
expect(spy).toHaveBeenCalled() // Testing how, not what
// ✅ GOOD
const distance = calculateDistance({ x: 0, y: 0 }, { x: 3, y: 4 })
expect(distance).toBe(5) // Testing output
```
### Mocking Too Much
```typescript
// ❌ BAD
const mockAdd = vi.fn((a, b) => a + b)
// ✅ GOOD: Use real implementations
import { add } from './utils'
// Only mock external services
const mockPaymentGateway = vi.fn()
```
## See Also
- `vitest-testing` - TypeScript/JavaScript testing
- `playwright-testing` - E2E testing
- `mutation-testing` - Validate test effectiveness
© secondsky · MIT · secondsky/claude-skills