Flaky Tests: 7 причин + решение с Mock API [99.5% стабильности]

🔴 Красные флаги нестабильности

1. "Запусти еще раз" — стандартная реакция на падающий тест
2. CI/CD pipeline красный без причины — тесты падают, но код работает
3. Игнорирование тестов — разработчики пропускают падения ("это точно flaky")
4. Retry mechanisms — тесты перезапускаются автоматически 2-3 раза
5. Quarantine tests — "проблемные" тесты отключаются "временно" (навсегда)
6. Расследование багов 3+ часов — выясняется, что это flaky test

Причина 1: Зависимость от внешних API и сервисов

Тесты, вызывающие реальные внешние API (payment gates, геолокация, аутентификация), становятся нестабильными из-за сетевых задержек, rate limits и temporary outages.

// cypress/e2e/checkout.spec.js
it('должен обработать оплату', () => {
  cy.get('[data-testid="card-number"]').type('4242424242424242');
  cy.get('[data-testid="submit-payment"]').click();

  // ❌ Вызов real Stripe API - источник flaky
  cy.wait('@stripeValidation', { timeout: 1500 });

  cy.contains('Оплата успешна').should('be.visible');
});

// cypress/e2e/checkout.spec.js
beforeEach(() => {
  // ✅ Мокируем Stripe API
  cy.intercept('POST', 'https://api.stripe.com/v1/tokens', {
    statusCode: 200,
    body: {
      id: 'tok_test_123',
      object: 'token',
      card: { last4: '4242' }
    }
  }).as('stripeValidation');
});

it('должен обработать оплату', () => {
  cy.get('[data-testid="card-number"]').type('4242424242424242');
  cy.get('[data-testid="submit-payment"]').click();

  // ✅ Детерминированный ответ, всегда 99.5% стабильности
  cy.wait('@stripeValidation');

  cy.contains('Оплата успешна').should('be.visible');
});

Причина 2: Race Conditions и Timing Issues

Асинхронные операции, setTimeout, Promise chains — все это создает timing issues. Тест иногда выполняется быстрее, чем данные загрузились, иногда медленнее.

// tests/users.test.js
test('должен отобразить список пользователей', async () => {
  render();

  // ❌ Фиксированный wait - ненадежно
  await wait(500);

  // Иногда API отвечает за 300ms, иногда за 700ms
  const users = screen.getAllByTestId('user-item');
  expect(users).toHaveLength(10);
});

// tests/users.test.js
test('должен отобразить список пользователей', async () => {
  // ✅ Mock API отвечает мгновенно и детерминированно
  mockApi.get('/users').reply(200, [
    { id: 1, name: 'User 1' },
    { id: 2, name: 'User 2' },
    // ... ровно 10 пользователей
  ]);

  render();

  // ✅ waitFor ждет appearance элементов
  const users = await waitFor(() =>
    screen.getAllByTestId('user-item')
  );

  expect(users).toHaveLength(10);
});

Причина 3: Зависимость от состояния БД и data pollution

Тесты, работающие с общей БД, создают взаимные зависимости. Тест А создает данные, тест Б их изменяет, тест В ожидает определенное состояние — и все ломается при параллельном запуске.

// tests/users.test.js
describe('User Creation', () => {
  let mockApi;

  beforeEach(() => {
    // ✅ Каждый тест получает чистое состояние
    mockApi = createMockApi({
      baseURL: 'https://test-suite-123.lightboxapi.com'
    });

    // ✅ Фиксированное начальное состояние
    mockApi.state = {
      users: [
        { id: 1, email: 'user1@example.com' },
        { id: 2, email: 'user2@example.com' },
        { id: 3, email: 'user3@example.com' },
        { id: 4, email: 'user4@example.com' },
        { id: 5, email: 'user5@example.com' }
      ]
    };
  });

  test('должен создать нового пользователя', async () => {
    const response = await api.post('/users', {
      email: 'test@example.com',
      name: 'Test User'
    });

    expect(response.status).toBe(201);
    expect(response.data.id).toBe(6); // Предсказуемо!
  });

  test('должен вернуть всех пользователей', async () => {
    const response = await api.get('/users');

    expect(response.data).toHaveLength(5); // Всегда 5!
  });
});

Причина 4: Недетерминированные данные (рандом, дата/время)

`Math.random()`, `new Date()`, UUID generation — все источники рандомности делают тесты непредсказуемыми.

test('должен отобразить активных пользователей', async () => {
  const response = await api.get('/users?active=true');

  // ❌ Backend фильтрует по lastLoginAt > now() - 30 days
  // Если сегодня 1 марта, получаем одних пользователей
  // Если завтра 2 марта, получаем других (кто-то стал inactive)
  expect(response.data).toHaveLength(10); // Flaky!
});

// Mock API конфигурация
mockApi.get('/users').reply(200, {
  users: [
    {
      id: 1,
      name: 'Active User 1',
      active: true,
      lastLoginAt: '2026-01-25T10:00:00Z' // ✅ Фиксированная дата
    },
    {
      id: 2,
      name: 'Active User 2',
      active: true,
      lastLoginAt: '2026-01-20T15:30:00Z' // ✅ Фиксированная дата
    },
    // ... ровно 10 активных пользователей
  ]
});

test('должен отобразить активных пользователей', async () => {
  const response = await api.get('/users?active=true');

  // ✅ Всегда 10 пользователей, независимо от даты запуска
  expect(response.data.users).toHaveLength(10);
});

Причина 5: Ресурсные ограничения (CPU, memory, network)

На перегруженном CI/CD сервере тесты выполняются медленнее, timeout'ы срабатывают чаще, появляются race conditions.

Причина 6: Зависимость от порядка выполнения тестов

Тест А создает глобальное состояние, тест Б на него полагается. Если запустить тест Б отдельно — он падает. Это классический anti-pattern.

Причина 7: Недостаточные ожидания и assertions

Тесты, которые не ждут completion асинхронных операций или проверяют промежуточные состояния, становятся flaky.

test('должен загрузить и отобразить данные', async () => {
  render();

  // ❌ Проверяем loading состояние
  expect(screen.getByText('Загрузка...')).toBeInTheDocument();

  // ❌ Если API ответил быстро, loading уже исчез - flaky!
  await wait(100);

  expect(screen.getByText('Данные загружены')).toBeInTheDocument();
});

test('должен загрузить и отобразить данные', async () => {
  // ✅ Mock API отвечает мгновенно
  mockApi.get('/data').reply(200, { message: 'Данные загружены' });

  render();

  // ✅ Ждем финального состояния
  await waitFor(() => {
    expect(screen.getByText('Данные загружены')).toBeInTheDocument();
  });

  // ✅ Можем дополнительно проверить отсутствие loading
  expect(screen.queryByText('Загрузка...')).not.toBeInTheDocument();
});

Шаг 1: Аудит текущих тестов (1-2 дня)

Выявите flaky tests и измерьте baseline метрики.

# Найти все упавшие тесты за последние 30 дней
cat ci-logs.txt | grep "FAILED" | sort | uniq -c | sort -rn | head -20

# Пример вывода:
# 45 test/api/users.spec.js - "should create user"
# 38 test/api/orders.spec.js - "should process payment"
# 32 test/e2e/checkout.spec.js - "should complete checkout"

# Вычислить flaky rate
echo "Flaky rate: $(echo "scale=2; (45+38+32)/500*100" | bc)%"
# Output: Flaky rate: 23.00%

Шаг 2: Приоритизация — какие тесты мигрировать первыми

Не пытайтесь мигрировать все сразу. Начните с самых проблемных.

Шаг 3: Настройка Mock API (2 часа)

Создайте Mock API из существующей OpenAPI спецификации.

# 1. Зарегистрируйтесь на lightboxapi.ru (1 минута)
# 2. Создайте workspace для вашего проекта
# 3. Импортируйте OpenAPI спецификацию (2 минуты)

# 4. Получите Mock API URL
export MOCK_API_URL="https://your-team.lightboxapi.com"

# 5. Настройте тестовое окружение
echo "API_URL=$MOCK_API_URL" >> .env.test

# Готово! Mock API работает ✅

Шаг 4-7: Миграция, мониторинг и поддержка (1 неделя)

Постепенно переводите тесты на Mock API, отслеживайте метрики, обновляйте контракты при изменениях.

Проблема

Fintech стартап (20 разработчиков, 5 QA) имел 127 автотестов, из которых 29 были flaky (23%). CI/CD pipeline проходил успешно только в 62% случаев. QA команда тратила 3.5 часа в день на расследование ложных падений.

Финансовые потери:

• Время QA на расследование: 5 человек × 3.5ч × 22 дня × 50₽/мин = 385,000₽/месяц
• Заблокированные релизы: 12 раз/месяц × 4 часа × 10 человек × 50₽/мин = 1,440,000₽/месяц
• Developer time на retry CI/CD: 20 разработчиков × 1ч/день × 50₽/мин = 660,000₽/месяц
• Итого: 2,485,000₽/месяц потерь из-за flaky tests

Решение

Внедрили LightBox API Mock для всех внешних API интеграций (банки, KYC verification, payment gateways). Миграция заняла 10 рабочих дней.

План внедрения:

1. День 1-2: Аудит flaky tests, приоритизация
2. День 3: Создание OpenAPI спецификаций для внешних API
3. День 4: Импорт в LightBox API, настройка динамических данных
4. День 5-8: Миграция 29 flaky tests на Mock API
5. День 9-10: Тестирование, мониторинг, документация

Сколько времени занимает устранение flaky tests?

Аудит и приоритизация: 1-2 дня
Настройка Mock API: 2-4 часа
Миграция тестов: 3-7 дней (зависит от количества flaky tests)
Итого: 1-2 недели для полного устранения проблемы

При этом результаты видны сразу после миграции первых 10-20 тестов (обычно день 3-4).

Какой ROI от устранения flaky tests?

При команде из 5 QA инженеров (зарплата 200,000₽/месяц):

• Экономия времени QA: 3 часа/день × 5 QA × 22 дня × 50₽/мин = 330,000₽/месяц
• Экономия developer time: 1 час/день × 20 dev × 50₽/мин = 660,000₽/месяц
• Предотвращенные блокировки: ~1,000,000₽/месяц

Итого: ~2,000,000₽/месяц экономии при инвестициях 100,000-150,000₽ (1-2 недели работы)

ROI = 1,300% за первый месяц

Нужно ли полностью отказываться от real API тестов?

Нет! Рекомендуется balanced подход:

• 70-80% тестов на Mock API: Unit, integration, большинство E2E
• 20-30% тестов на real API: Critical smoke tests, contract tests

Mock API устраняет flaky tests, ускоряет выполнение и дает детерминированность. Real API тесты обеспечивают проверку интеграции с production окружением.

Как мониторить эффективность после внедрения?

Ключевые метрики для отслеживания:

1. Flaky rate: Должен упасть до < 1%
2. CI/CD pass rate: Должен вырасти до > 95%
3. Mean time to green: Среднее время до зеленого pipeline
4. Test execution time: Должен сократиться в 5-10 раз
5. False positive rate: Должен упасть до < 1%

Используйте CI/CD дашборды (Jenkins, GitLab CI, GitHub Actions) для визуализации метрик.