Какие знаешь виды автотестов?

Виды автотестов в Frontend-разработке

В современной Frontend-разработке существует несколько основных категорий автотестов, которые образуют "пирамиду тестирования". Эта пирамида отражает оптимальное соотношение количества, скорости и стоимости тестов.

1. Unit-тесты (Модульные тесты)

Это тесты отдельных, изолированных частей кода (юнитов) — обычно функций, компонентов или классов.

Характеристики:

• Проверяют самую маленькую единицу кода.
• Выполняются очень быстро (миллисекунды).
• Должны быть полностью изолированы (зависимости мокаются или стабаются).
• Составляют основу пирамиды — их должно быть больше всего.

Используются для:

• Проверки бизнес-логики, утилитарных функций.
• Проверки реактивности компонентов (изменение состояния, вызов коллбэков).
• Санитарной проверки (smoke test) компонентов.

Пример для React-компонента с Jest и Testing Library:

// Component
function WelcomeMessage({ userName, isLoggedIn }) {
  if (!isLoggedIn) return <p>Пожалуйста, войдите в систему</p>;
  return <h1 data-testid="welcome-title">Добро пожаловать, {userName}!</h1>;
}

// Test
import { render, screen } from '@testing-library/react';

describe('WelcomeMessage component', () => {
  test('отображает приветствие для авторизованного пользователя', () => {
    render(<WelcomeMessage userName="Анна" isLoggedIn={true} />);
    const titleElement = screen.getByTestId('welcome-title');
    expect(titleElement).toBeInTheDocument();
    expect(titleElement).toHaveTextContent('Добро пожаловать, Анна!');
  });

  test('отображает сообщение о входе для неавторизованного пользователя', () => {
    render(<WelcomeMessage userName="Анна" isLoggedIn={false} />);
    expect(screen.getByText(/пожалуйста, войдите/i)).toBeInTheDocument();
    expect(screen.queryByTestId('welcome-title')).not.toBeInTheDocument();
  });
});

2. Integration-тесты (Интеграционные тесты)

Проверяют взаимодействие нескольких модулей или систем друг с другом. Во Frontend это часто тесты на взаимодействие компонентов, компонента с сервисом или состоянием (например, Redux, MobX).

Характеристики:

• Проверяют "швы" между модулями.
• Выполняются медленнее, чем юнит-тесты.
• Требуют настройки среды (например, моки API, работа с контекстом).
• Их количество меньше, чем юнит-тестов.

Используются для:

• Проверки работы целой функциональности (например, форма отправляет данные, обновляет состояние и показывает уведомление).
• Тестирования маршрутизации (роутинга).
• Проверки интеграции с глобальным состоянием.

Пример интеграционного теста с моком API:

// Тестируем, что при отправке формы компонент взаимодействует с сервисом
import { render, screen, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { ApiService } from '../services/api';
import { SubmitForm } from '../SubmitForm';

jest.mock('../services/api'); // Мокаем сервис

describe('SubmitForm интеграция с API', () => {
  test('успешная отправка формы показывает сообщение об успехе', async () => {
    const mockSubmitData = jest.fn().mockResolvedValue({ success: true });
    ApiService.prototype.submitData = mockSubmitData;

    render(<SubmitForm />);

    await userEvent.type(screen.getByLabelText(/имя/i), 'Иван');
    await userEvent.click(screen.getByRole('button', { name: /отправить/i }));

    await waitFor(() => {
      expect(mockSubmitData).toHaveBeenCalledWith({ name: 'Иван' });
      expect(screen.getByText(/данные успешно отправлены/i)).toBeInTheDocument();
    });
  });
});

3. E2E-тесты (End-to-End тесты, сквозные тесты)

Имитируют поведение реального пользователя в полном окружении (браузер, бэкенд, база данных). Это тесты самого высокого уровня.

Характеристики:

• Максимально близки к реальному пользовательскому сценарию.
• Самые медленные и нестабильные (хрупкие).
• Самые дорогие в написании и поддержке.
• Их должно быть меньше всего (вершина пирамиды).

Используются для:

• Критичных пользовательских сценариев (покупка товара, регистрация, основной workflow).
• Проверки межсистемного взаимодействия.

Пример E2E-теста с использованием Cypress:

// Cypress тест для сценария покупки товара
describe('Сценарий покупки товара', () => {
  it('Пользователь может добавить товар в корзину и оформить заказ', () => {
    // 1. Посещение страницы каталога
    cy.visit('/products');
    // 2. Поиск и клик по товару
    cy.contains('.product-card', 'Ноутбук').within(() => {
      cy.get('[data-cy="add-to-cart-btn"]').click();
    });
    // 3. Переход в корзину
    cy.get('[data-cy="cart-icon"]').click();
    // 4. Проверка наличия товара
    cy.contains('.cart-item', 'Ноутбук').should('be.visible');
    // 5. Начало оформления заказа
    cy.contains('Оформить заказ').click();
    // 6. Заполнение формы
    cy.get('[data-cy="checkout-email"]').type('test@example.com');
    cy.get('[data-cy="checkout-submit"]').click();
    // 7. Проверка успешного завершения
    cy.url().should('include', '/order-success');
    cy.contains('Ваш заказ подтвержден').should('be.visible');
  });
});

Дополнительные специализированные виды

• Снапшот-тесты (Snapshot tests): Сравнивают текущий рендер компонента (HTML, Virtual DOM) с сохранённым эталоном ("снимком"). Полезны для предотвращения непреднамеренных изменений в UI. Используются в связке с Jest.
• Визуальные регрессионные тесты (Visual regression tests): Более продвинутый аналог снапшот-тестов, который сравнивает не DOM, а фактическое изображение (скриншот) компонента или страницы. Инструменты: Percy, Applitools, Loki.
• Тесты производительности (Performance tests): Автоматизированная проверка метрик производительности (Time to Interactive, First Contentful Paint). Могут быть частью CI/CD пайплайна с использованием Lighthouse CI или Web Vitals.

Ключевые принципы организации

1. Пирамида тестирования: Много быстрых и дешёвых unit-тестов в основании, меньше интеграционных тестов в середине и минимальное количество медленных E2EIf-тестов на вершине.
2. Изоляция: Чем ниже уровень теста, тем выше должна быть изоляция от внешних зависимостей (сеть, файловая система, браузерное API).
3. Стоимость и скорость: Рост уровня теста ведёт к экспоненциальному росту времени выполнения и сложности отладки.

Правильный выбор и баланс между этими видами тестов позволяют создать устойчивую, поддерживаемую и быстро развивающуюся codebase, обеспечивая высокое качество продукта при оптимальных затратах на поддержку тестов.