code-ai-installer 3.0.0 → 4.0.0

package/domains/development/.agents/skills/testing-strategy-js/SKILL.md

@@ -1,11 +1,46 @@
 ---
 name: testing-strategy-js
-description: Стратегия тестирования для JS/TS проектов — unit (Vitest), integration (API/DB), e2e (Playwright). AAA-паттерн, Vitest конфиг, React Testing Library, моки внешних сервисов, coverage thresholds, naming conventions, CI pipeline. Активируй при написании новых тестов, рефакторинге существующих, или при вопросах «как правильно тестировать X».
+description: "Стратегия тестирования для JS/TS проектов — unit (Vitest), integration (API/DB), e2e (Playwright). AAA-паттерн, Vitest конфиг, React Testing Library, моки внешних сервисов, coverage thresholds, naming conventions, CI pipeline. Активируй при написании новых тестов, рефакторинге существующих, или при вопросах «как правильно тестировать X»."
+type: discretionary
+domain: development
+owners:
+  - senior_full_stack
+gates:
+  - DEV
+tech: []
+topic:
+  - general
+  - testing
+triggers:
+  - стратегия тестов
+  - unit тесты JS
+  - integration тесты
+  - Vitest конфиг
+  - coverage threshold
+  - AAA паттерн
+  - моки сервисов
+related:
+  - testing-strategy-js-reference
+  - tdd-workflow
+  - tdd-workflow-reference
+  - qa-e2e-playwright
+  - tests-quality-review
+  - qa-test-integrity-audit
+  - qa-mutation-testing
+  - qa-browser-testing
+  - node-express-beast-practices
+  - mongodb-mongoose-best-practices
+  - es2025-beast-practices
+  - es2025-beast-practices-reference
+  - dev-reference-snippets
+budget_lines: 320
+schema_version: 1
 ---
 
+
 # Skill: Testing Strategy (JS/TS)
 
-Конкретные паттерны, шаблоны и DO/DON'T для написания надёжных тестов.
+Decision rules + canonical tables для написания надёжных тестов. Полные DO/DON'T кодовые примеры — в `$testing-strategy-js-reference`.
 
 **Разделы:**
 1. [Пирамида тестов и границы](#1-пирамида-тестов)
@@ -45,472 +80,129 @@ description: Стратегия тестирования для JS/TS проек
 
 ## 2. Unit-тесты
 
-### ✅ DO: AAA-паттерн (Arrange → Act → Assert)
-
-```js
-import { describe, it, expect } from 'vitest';
-import { calculateDiscount } from './pricing.js';
-
-describe('calculateDiscount', () => {
-  it('should apply percentage discount to base price', () => {
-    // Arrange
-    const basePrice = 100;
-    const discountPercent = 20;
-
-    // Act
-    const result = calculateDiscount(basePrice, discountPercent);
-
-    // Assert
-    expect(result).toBe(80);
-  });
-
-  it('should clamp discount at 0 (never negative price)', () => {
-    const result = calculateDiscount(50, 120);
-    expect(result).toBe(0);
-  });
-
-  it('should return original price when discount is 0', () => {
-    expect(calculateDiscount(100, 0)).toBe(100);
-  });
-
-  it('should throw on negative base price', () => {
-    expect(() => calculateDiscount(-10, 5)).toThrow('Price must be non-negative');
-  });
-});
-```
-
-### ✅ DO: тестировать edge cases явно
-
-```js
-describe('parseTimerValue', () => {
-  // Happy path
-  it('should parse "05:30" into { minutes: 5, seconds: 30 }', () => {
-    expect(parseTimerValue('05:30')).toEqual({ minutes: 5, seconds: 30 });
-  });
-
-  // Boundaries
-  it('should handle "00:00" as zero timer', () => {
-    expect(parseTimerValue('00:00')).toEqual({ minutes: 0, seconds: 0 });
-  });
-
-  it('should handle "99:59" as max timer', () => {
-    expect(parseTimerValue('99:59')).toEqual({ minutes: 99, seconds: 59 });
-  });
-
-  // Error paths
-  it('should throw on invalid format "abc"', () => {
-    expect(() => parseTimerValue('abc')).toThrow();
-  });
-
-  it('should throw on seconds > 59', () => {
-    expect(() => parseTimerValue('01:60')).toThrow();
-  });
-
-  // Null / undefined
-  it('should throw on null input', () => {
-    expect(() => parseTimerValue(null)).toThrow();
-  });
-});
-```
+**Правила:**
+- **AAA-паттерн** (Arrange → Act → Assert) с комментариями в коде или пустыми строками-разделителями
+- **Edge cases явно** — happy path + boundaries (min/max) + error paths + null/undefined
+- **Custom hooks через `renderHook` + `act`** из `@testing-library/react`
+- **Один `it` — один концепт** — не группируй несвязанные assertions
+- **Чистые функции = чистые тесты** — никакого I/O, моков, fakeTimers (если функция не использует Date.now)
 
-### ✅ DO: тестировать custom hooks через renderHook
-
-```js
-import { renderHook, act } from '@testing-library/react';
-import { useCounter } from './useCounter.js';
-
-describe('useCounter', () => {
-  it('should initialize with default value 0', () => {
-    const { result } = renderHook(() => useCounter());
-    expect(result.current.count).toBe(0);
-  });
-
-  it('should initialize with custom value', () => {
-    const { result } = renderHook(() => useCounter(10));
-    expect(result.current.count).toBe(10);
-  });
-
-  it('should increment count', () => {
-    const { result } = renderHook(() => useCounter());
-    act(() => result.current.increment());
-    expect(result.current.count).toBe(1);
-  });
-
-  it('should not go below 0', () => {
-    const { result } = renderHook(() => useCounter(0));
-    act(() => result.current.decrement());
-    expect(result.current.count).toBe(0);
-  });
-});
-```
+> Полный код AAA + edge cases + hooks → `$testing-strategy-js-reference` §2.
 
 ---
 
 ## 3. React-компоненты (RTL)
 
-### ✅ DO: тестировать поведение, а не реализацию
-
-```js
-import { render, screen, fireEvent } from '@testing-library/react';
-import userEvent from '@testing-library/user-event';
-import { SearchInput } from './SearchInput.jsx';
-
-describe('SearchInput', () => {
-  it('should call onSearch with query when button clicked', async () => {
-    const user = userEvent.setup();
-    const onSearch = vi.fn();
-
-    render(<SearchInput onSearch={onSearch} />);
-
-    await user.type(screen.getByRole('textbox', { name: /search/i }), 'laptop');
-    await user.click(screen.getByRole('button', { name: /search/i }));
+**Правила:**
+- **Тестируй поведение, не реализацию** — через DOM, не через internal state
+- **`userEvent.setup()`** в каждом тесте (не shared) — изолированный пользовательский ввод
+- **`screen.getByRole`** — приоритет №1
+- **`screen.findBy*`** для async DOM (auto-retry с timeout)
+- ❌ **Не используй `container.querySelector`** — это implementation detail
+- ❌ **Не проверяй `result.current` для UI** — это hook test, не component test
 
-    expect(onSearch).toHaveBeenCalledWith('laptop');
-    expect(onSearch).toHaveBeenCalledTimes(1);
-  });
+### RTL Query priority (от лучшего к худшему)
 
-  it('should show error message for empty query', async () => {
-    const user = userEvent.setup();
-    render(<SearchInput onSearch={vi.fn()} />);
+| Приоритет | Метод | Когда использовать |
+|---|---|---|
+| 1 | `getByRole` | Семантические элементы (button, textbox, heading) |
+| 2 | `getByLabelText` | Формы |
+| 3 | `getByPlaceholderText` | Поля без label (редко) |
+| 4 | `getByText` | Статический текст |
+| 5 | `getByDisplayValue` | Filled form |
+| 6 | `getByAltText` / `getByTitle` | Картинки / hover hints |
+| 7 | `getByTestId` | Last resort (нет семантики) |
 
-    await user.click(screen.getByRole('button', { name: /search/i }));
-
-    expect(screen.getByRole('alert')).toHaveTextContent(/enter a query/i);
-  });
-
-  it('should disable button while loading', () => {
-    render(<SearchInput onSearch={vi.fn()} isLoading />);
-
-    expect(screen.getByRole('button', { name: /search/i })).toBeDisabled();
-  });
-});
-```
-
-### ❌ DON'T: тестировать детали реализации
-
-```js
-// ❌ Плохо: зависимость от внутреннего state
-it('should set state to true', () => {
-  const { result } = renderHook(() => useToggle());
-  act(() => result.current[1]());
-  // Проверяем internal state — хрупко
-  expect(result.current[0]).toBe(true);
-});
-
-// ✅ Хорошо: проверяем поведение через DOM
-it('should show content after toggle click', async () => {
-  const user = userEvent.setup();
-  render(<Accordion title="Details">Content</Accordion>);
-
-  expect(screen.queryByText('Content')).not.toBeInTheDocument();
-  await user.click(screen.getByRole('button', { name: /details/i }));
-  expect(screen.getByText('Content')).toBeVisible();
-});
-```
-
-### ✅ DO: RTL queries по приоритету
-
-```js
-// Приоритет запросов (от лучшего к худшему):
-// 1. getByRole     — семантические роли (лучше всего)
-// 2. getByLabelText — формы
-// 3. getByText     — статический текст
-// 4. getByTestId   — последний resort
-
-// ✅ По роли — устойчиво к изменению вёрстки
-screen.getByRole('button', { name: /save/i });
-screen.getByRole('textbox', { name: /email/i });
-screen.getByRole('heading', { level: 2 });
-
-// ✅ По label — формы
-screen.getByLabelText(/password/i);
-
-// ⚠️ По тексту — менее устойчиво к i18n
-screen.getByText(/no templates found/i);
-
-// 🔧 По testid — когда нет семантики
-screen.getByTestId('popup-container');
-```
+> Полный код RTL + behavior testing + queries → `$testing-strategy-js-reference` §3.
 
 ---
 
 ## 4. Integration-тесты
 
-### ✅ DO: API handler тесты с supertest
-
-```js
-import { describe, it, expect, beforeAll, afterAll } from 'vitest';
-import request from 'supertest';
-import { createApp } from '../app.js';
-
-describe('POST /api/products', () => {
-  let app;
-
-  beforeAll(() => {
-    app = createApp({ db: testDb });
-  });
-
-  afterAll(async () => {
-    await testDb.cleanup();
-  });
-
-  it('should create product and return 201', async () => {
-    const res = await request(app)
-      .post('/api/products')
-      .send({ name: 'Summer Hat', price: 25, category: 'accessories' })
-      .expect(201);
-
-    expect(res.body).toMatchObject({
-      name: 'Summer Hat',
-      price: 25,
-      category: 'accessories',
-    });
-    expect(res.body).toHaveProperty('id');
-    expect(res.body).toHaveProperty('createdAt');
-  });
-
-  it('should reject duplicate product name with 409', async () => {
-    await request(app)
-      .post('/api/products')
-      .send({ name: 'Unique Widget', price: 10, category: 'tools' });
-
-    await request(app)
-      .post('/api/products')
-      .send({ name: 'Unique Widget', price: 20, category: 'tools' })
-      .expect(409);
-  });
-
-  it('should reject invalid price with 400 and error details', async () => {
-    const res = await request(app)
-      .post('/api/products')
-      .send({ name: 'Bad Item', price: -5, category: 'tools' })
-      .expect(400);
-
-    expect(res.body.error).toMatch(/price/i);
-  });
-});
-```
+**Правила:**
+- **`supertest`** для API handler тестов — реальный Express через `request(app)`
+- **`beforeAll` для setup**, **`afterAll` для cleanup** (BD, fixtures)
+- **Тесты контрактов** — `expect.objectContaining({ ... })` + `expect.any(String)` для shape без бизнес-логики
+- **Изолируй DB** — testDb отдельная от dev/prod; truncate/cleanup между прогонами
+- **Statuses в ассертах** — `.expect(201)` / `.expect(409)` / `.expect(400)`
 
-### ✅ DO: тесты контрактов (проверяем форму ответа, не бизнес-логику)
-
-```js
-describe('GET /api/templates', () => {
-  it('should match API contract shape', async () => {
-    const res = await request(app)
-      .get('/api/templates')
-      .expect(200);
-
-    expect(res.body).toEqual(
-      expect.arrayContaining([
-        expect.objectContaining({
-          id: expect.any(String),
-          name: expect.any(String),
-          category: expect.any(String),
-          thumbnail: expect.stringMatching(/^https?:\/\//),
-        }),
-      ])
-    );
-  });
-});
-```
+> Полный код supertest + contract testing → `$testing-strategy-js-reference` §4.
 
 ---
 
 ## 5. Моки и Test Doubles
 
-### ✅ DO: мокать внешние границы, не внутреннюю логику
+### Boundary Mocking Rule (главное правило)
 
-```js
-// ✅ Мокаем внешний HTTP API
-vi.mock('../services/openai.js', () => ({
-  generateText: vi.fn().mockResolvedValue('Mocked AI response'),
-}));
+**Мокать ТОЛЬКО на границе своей системы.** Граница — это всё что:
+- **Не управляется твоим кодом** — внешние API, сторонние SDK, OS-сервисы
+- **Не детерминированно** — время, рандом, сеть, конкурентность
+- **Имеет нежелательные побочные эффекты в тесте** — FS, prod DB, оплата, email
 
-// ✅ Мокаем таймеры
-import { vi, beforeEach, afterEach } from 'vitest';
+**Внутри границы — реальный код, без моков.** Тест должен ловить регрессии в твоей логике, а не подтверждать что моки настроены правильно.
 
-beforeEach(() => vi.useFakeTimers());
-afterEach(() => vi.useRealTimers());
+### Decision tree: mock или real?
 
-it('should expire item after timeout', () => {
-  const onExpire = vi.fn();
-  startTimer(onExpire, 5000);
-
-  vi.advanceTimersByTime(5000);
-
-  expect(onExpire).toHaveBeenCalledOnce();
-});
 ```
-
-### ✅ DO: фабрики тестовых данных вместо хардкода
-
-```js
-// test-utils/factories.js
-
-/**
- * Создаёт тестовый объект продукта с возможностью override.
- * @param {Partial<Product>} overrides - поля для переопределения.
- * @returns {Product} тестовый продукт.
- */
-function createProduct(overrides = {}) {
-  return {
-    id: crypto.randomUUID(),
-    name: 'Test Product',
-    price: 29.99,
-    category: 'widgets',
-    active: true,
-    createdAt: new Date().toISOString(),
-    ...overrides,
-  };
-}
-
-// Использование в тестах:
-it('should deactivate expired product', () => {
-  const product = createProduct({ active: true, expiresAt: '2024-01-01' });
-  const result = deactivateExpired(product);
-  expect(result.active).toBe(false);
-});
+Зависимость к чему?
+│
+├─ Внешний HTTP API / SDK / cloud service ────► MOCK (граница)
+├─ Время / рандом / crypto.randomUUID ────────► MOCK (детерминизм)
+├─ File system / process / env ───────────────► MOCK (изоляция)
+├─ Production DB / Stripe / Email service ────► MOCK (побочные эффекты)
+├─ Твой собственный модуль / утилита ─────────► REAL (твоя логика)
+├─ Чистая трансформация данных ───────────────► REAL (без зависимостей)
+├─ Router / навигация / state в integration ──► REAL (поведение системы)
+└─ testDb (isolated) в integration ───────────► REAL (контракт DB-слоя)
 ```
 
-### ❌ DON'T: чрезмерные моки
-
-```js
-// ❌ Замокали всё — тест ничего не проверяет
-vi.mock('../db.js');
-vi.mock('../validator.js');
-vi.mock('../logger.js');
-vi.mock('../event-bus.js');
+**Правила приоритета:**
+- Если можно протестировать с реальной зависимостью без побочек — **НЕ мокай**
+- Если мокаешь, но не уверен зачем — **выкинь мок и попробуй с реальным**
+- Mock count в одном тесте >5 — **пересмотри границы** (тест на не той абстракции)
 
-it('should save product', async () => {
-  db.save.mockResolvedValue({ id: 1 });
-  validator.validate.mockReturnValue(true);
+### Integration patterns на границах системы
 
-  await saveProduct({ name: 'Widget' });
+| Граница | Мокать (transport) | Оставить реальным (transformation) |
+|---|---|---|
+| HTTP fetch к внешнему API | `fetch` global / axios instance | Парсинг ответа, error mapping, retry logic |
+| DB через ORM (Mongoose/Prisma) | Connection / driver | Schema validation, query builders, transformers |
+| LLM/AI service (OpenAI, Anthropic) | API client `.chat.completions.create` | Prompt assembly, response parsing, fallback |
+| Email/SMS provider (Stripe, Twilio) | Provider SDK | Template rendering, recipient validation, dry-run output |
 
-  expect(db.save).toHaveBeenCalled(); // мы проверяем моки, не логику
-});
+**Принцип:** мокается **transport** (что уходит в сеть/сторонний сервис), а **transformation** (твоя логика подготовки данных и обработки ответа) тестируется реально.
 
-// ✅ Интеграционный тест проверяет реальный flow
-it('should save valid product to DB', async () => {
-  const result = await saveProduct({ name: 'Premium Widget', price: 29.99, category: 'digital' });
-  expect(result.id).toBeDefined();
+### Базовые правила
 
-  const stored = await db.findById(result.id);
-  expect(stored.name).toBe('Premium Widget');
-});
-```
-
-### Что мокать, а что нет
+- **Фабрики тестовых данных** (`createProduct({ ...overrides })`) вместо хардкода
+- **`vi.useFakeTimers()` / `vi.useRealTimers()`** в `beforeEach` / `afterEach`
+- **`vi.mocked(fn).mockResolvedValue(...)`** для type-safe моков
 
-| Мокать ✅ | НЕ мокать ❌ |
-|----------|-------------|
-| HTTP API (fetch, axios) | Собственные утилиты |
-| Внешние сервисы (OpenAI, Stripe, Redis) | Простые трансформации данных |
-| Таймеры (setTimeout, setInterval) | Router / навигация (если не E2E) |
-| File system (fs) | Внутренние модули (теряется смысл integration) |
-| crypto.randomUUID (детерминизм) | — |
+> Полный код моков + фабрик + decision tree examples → `$testing-strategy-js-reference` §5.
+> Детектирование gaming-паттернов в тестах (моки замаскированные под behavior) → `$qa-test-integrity-audit`.
 
 ---
 
 ## 6. Naming и структура
 
-### Организация файлов
-
-```
-src/
-├── utils/
-│   ├── pricing.js
-│   └── pricing.test.js          # Unit — рядом с кодом
-├── hooks/
-│   ├── useTimer.js
-│   └── useTimer.test.js         # Unit — рядом с кодом
-├── components/
-│   ├── SearchInput.jsx
-│   └── SearchInput.test.jsx     # RTL — рядом с компонентом
-├── api/
-│   ├── products.handler.js
-│   └── products.integration.test.js  # Integration — рядом с маршрутом
-└── e2e/                          # E2E — отдельная папка
-    └── specs/
-```
-
-### ✅ DO: describe/it naming convention
-
-```js
-// Формат: describe('[Unit/Module]') → it('should [ACTION] when [CONDITION]')
-describe('InputValidator', () => {
-  describe('validate', () => {
-    it('should return valid for correct input value', () => { /* ... */ });
-    it('should return invalid when value is empty', () => { /* ... */ });
-    it('should return invalid when value exceeds max length', () => { /* ... */ });
-  });
-
-  describe('isExpired', () => {
-    it('should return true when expiresAt is in the past', () => { /* ... */ });
-    it('should return false when expiresAt is in the future', () => { /* ... */ });
-    it('should return false when expiresAt is null (never expires)', () => { /* ... */ });
-  });
-});
-```
-
-### Чеклист для каждого тестируемого модуля
+**Правила:**
+- **Файлы тестов рядом с кодом** — `pricing.js` + `pricing.test.js`
+- **`describe('[Unit/Module]') → it('should [ACTION] when [CONDITION]')`**
+- **Integration-тесты** — `*.integration.test.js` (для фильтрации в CI)
+- **E2E** — отдельная папка `src/e2e/specs/`
+- **Чеклист для каждого модуля**: happy path + edge cases + boundaries + error paths + async (если применимо)
 
-- [ ] Happy path (основной сценарий)
-- [ ] Edge cases (0, null, undefined, пустая строка, пустой массив)
-- [ ] Boundaries (min/max значения)
-- [ ] Error paths (невалидный ввод, сетевые ошибки)
-- [ ] Async (таймауты, race conditions — если применимо)
+> Полный пример file tree + describe convention → `$testing-strategy-js-reference` §6.
 
 ---
 
 ## 7. Coverage и CI
 
-### Vitest конфиг
-
-```js
-// vitest.config.js
-import { defineConfig } from 'vitest/config';
-import react from '@vitejs/plugin-react';
-
-export default defineConfig({
-  plugins: [react()],
-  test: {
-    globals: true,
-    environment: 'jsdom',
-    setupFiles: ['./src/test-setup.js'],
-    include: ['src/**/*.test.{js,jsx,ts,tsx}'],
-    coverage: {
-      provider: 'v8',
-      reporter: ['text', 'html', 'lcov'],
-      include: ['src/**/*.{js,jsx,ts,tsx}'],
-      exclude: [
-        'src/**/*.test.*',
-        'src/**/*.spec.*',
-        'src/**/index.{js,ts}',     // barrel files
-        'src/test-utils/**',
-        'src/**/*.d.ts',
-      ],
-      thresholds: {
-        statements: 80,
-        branches: 75,
-        functions: 80,
-        lines: 80,
-      },
-    },
-  },
-});
-```
-
-### Setup файл
-
-```js
-// src/test-setup.js
-import '@testing-library/jest-dom/vitest';
-
-// Глобальный cleanup (RTL >= v14 делает это автоматически)
-// import { cleanup } from '@testing-library/react';
-// afterEach(cleanup);
-```
+**Правила:**
+- **Vitest config** — globals, jsdom, setupFiles, coverage provider v8
+- **Coverage exclude** — `*.test.*`, `*.spec.*`, `index.{js,ts}` (barrel), `test-utils/**`, `*.d.ts`
+- **CI запускает `vitest run --coverage`** — fail при пробое thresholds
+- **`@testing-library/jest-dom/vitest`** в setup для matchers (`toBeVisible`, `toHaveTextContent`)
 
 ### Coverage thresholds
 
@@ -521,97 +213,40 @@ import '@testing-library/jest-dom/vitest';
 | Functions | 70% | 80% | 90%+ |
 | Lines | 70% | 80% | 90%+ |
 
-### Scripts в package.json
-
-```json
-{
-  "scripts": {
-    "test": "vitest run",
-    "test:watch": "vitest",
-    "test:coverage": "vitest run --coverage",
-    "test:ui": "vitest --ui"
-  }
-}
-```
-
----
-
-## 8. Anti-patterns
+### Mutation testing и tier-based thresholds
 
-### ❌ DON'T: тесты зависят от порядка выполнения
+Coverage показывает что строки выполнились — но не что тест реально ловит баг. **Mutation testing** меняет код (мутации) и проверяет что хотя бы один тест падает — реальный показатель качества теста.
 
-```js
-// ❌ Плохо: второй тест зависит от первого
-let sharedState;
+Tier-based модель (Test Integrity Defense):
 
-it('should create item', () => {
-  sharedState = createItem({ name: 'test' });
-  expect(sharedState.id).toBeDefined();
-});
+| Tier | Что это | Mutation score | Coverage fallback |
+|---|---|---|---|
+| **Tier 1** | Critical paths — auth, billing, payments, security, crypto | ≥ 80% | n/a |
+| **Tier 2** | Default — бизнес-логика | ≥ 60% | n/a |
+| **Tier 3** | Low-risk — UI shell, fixtures, scaffolding | optional | ≥ 70% |
 
-it('should update item', () => {
-  updateItem(sharedState.id, { name: 'updated' }); // sharedState из предыдущего теста
-});
+Heuristic auto-tier-1 для путей: `src/auth/**`, `src/billing/**`, `src/security/**`, `src/payments/**`, `src/crypto/**`. Override через JSDoc `@tier N` комментарий в модуле.
 
-// ✅ Хорошо: каждый тест создаёт свои данные
-it('should update item', () => {
-  const item = createItem({ name: 'test' });
-  const updated = updateItem(item.id, { name: 'updated' });
-  expect(updated.name).toBe('updated');
-});
-```
+> Setup Stryker (JS/TS) / mutmut (Python) + tier thresholds + CI integration → `$qa-mutation-testing`.
 
-### ❌ DON'T: snapshot-тесты без осмысления
-
-```js
-// ❌ Бессмысленный snapshot — любое изменение ломает тест
-it('renders correctly', () => {
-  const { container } = render(<ComplexForm />);
-  expect(container).toMatchSnapshot(); // 500 строк snapshot, никто не ревьюит
-});
-
-// ✅ Snapshot только для стабильного output
-it('should render error boundary fallback', () => {
-  const { container } = render(<ErrorFallback error={new Error('Oops')} />);
-  expect(container).toMatchInlineSnapshot(`
-    <div class="error-fallback">
-      <p>Something went wrong: Oops</p>
-    </div>
-  `);
-});
-```
+> Полный `vitest.config.js` + setup + scripts → `$testing-strategy-js-reference` §7.
 
-### ❌ DON'T: «магические» значения без пояснений
+---
 
-```js
-// ❌ Что за 42? Почему 3?
-expect(result).toBe(42);
-expect(items).toHaveLength(3);
+## 8. Anti-patterns
 
-// ✅ Значения понятны из контекста
-const BASE_PRICE = 100;
-const DISCOUNT = 58;  // 58% discount
-const EXPECTED_PRICE = 42; // 100 - 58
+**Правила (DON'T):**
+- ❌ **Тесты зависят от порядка** — `let sharedState` между `it`-блоками. Каждый тест создаёт свои данные.
+- ❌ **Snapshot без осмысления** — `toMatchSnapshot()` на 500 строк. Используй `toMatchInlineSnapshot` для коротких стабильных outputs.
+- ❌ **Магические значения** — `expect(result).toBe(42)`. Объясняй через именованные константы.
+- ❌ **Async без await** — `it('...', () => { fetchData().then(...) })`. Всегда `async` + `await`.
+- ❌ **Чрезмерные моки** — замокать всё → тест проверяет моки, не код.
+- ❌ **Тесты для приватных методов** — тестируй public API, приватное покрывается через него.
+- ❌ **`any` / `// @ts-ignore` в тестах** — рушит type safety тестового кода.
+- ❌ **Mock-driven testing** — тест задаёт `mock.returns(X)`, затем asserts `result === X`. Это проверка что мок работает, а не что код работает. См. `$qa-test-integrity-audit` для детектирования.
+- ❌ **Тест следует за кодом без обоснования** — изменил код → подкрутил тест до зелёного, без явного объяснения почему новое поведение корректно. Self-confirming тест, AI-gaming паттерн.
 
-expect(calculatePrice(BASE_PRICE, DISCOUNT)).toBe(EXPECTED_PRICE);
-```
-
-### ❌ DON'T: async без await
-
-```js
-// ❌ Тест проходит всегда — assertion не выполняется
-it('should fetch data', () => {
-  fetchData().then(data => {
-    expect(data).toBeDefined(); // никогда не выполнится как assertion
-  });
-});
-
-// ✅ Правильно: await + async
-it('should fetch data', async () => {
-  const data = await fetchData();
-  expect(data).toBeDefined();
-});
-```
+> Полные bad-example блоки + corrections → `$testing-strategy-js-reference` §8.
 
 ---
 
@@ -625,12 +260,19 @@ it('should fetch data', async () => {
 - [ ] Фабрики для тестовых данных (если повторяются)
 - [ ] Coverage ≥ 80% statements
 - [ ] Нет `any`, нет `// @ts-ignore` в тестах
+- [ ] Моки только на границах системы (Boundary Mocking Rule §5)
 
 ---
 
 ## См. также
-- `$tests-quality-review` — ревью качества тестов
+- `$testing-strategy-js-reference` — полный справочник DO/DON'T кода тестов
+- `$tdd-workflow` — RED→GREEN→REFACTOR (написание тестов до кода)
 - `$qa-e2e-playwright` — E2E через Playwright
+- `$tests-quality-review` — ревью качества тестов
+- `$qa-test-integrity-audit` — детектирование gaming-паттернов и mock-to-real ratio
+- `$qa-mutation-testing` — Stryker (JS/TS) / mutmut (Python) + tier-based thresholds + CI integration
 - `$qa-browser-testing` — визуальное тестирование в Antigravity
-- `$es2025-beast-practices` — современный JS для написания чистого кода
-- `$dev-reference-snippets` — TDD, React, API примеры
+- `$node-express-beast-practices` — тестируемая структура backend
+- `$mongodb-mongoose-best-practices` — тестирование DB-слоя
+- `$es2025-beast-practices` — современный JS для чистого кода тестов
+- `$dev-reference-snippets` — TDD, React, API примеры