Как тестируешь проекты?

Мой подход к тестированию Frontend-проектов

Тестирование — это не просто этап, а непрерывный процесс, интегрированный в разработку. Моя стратегия строится на пирамиде тестирования и комбинации инструментов для разных уровней.

1. Пирамида тестирования: от фундамента к вершине

Я структурирую работу согласно классической пирамиде, адаптированной для фронтенда:

Unit Testing (Модульное тестирование)

• Цель: Проверить отдельные функции, компоненты, утилиты в изоляции.
• Инструменты: Для React/Vue компонентов — Jest + React Testing Library / Vue Test Utils. Для чистого JS — Jest.
• Пример:

// Компонент Button.jsx
export const Button = ({ label, onClick }) => {
  return <button onClick={onClick}>{label}</button>;
};

// Тест Button.test.jsx
import { render, screen, fireEvent } from '@testing-library/react';
import { Button } from './Button';

describe('Button component', () => {
  it('renders the correct label', () => {
    render(<Button label="Submit" />);
    expect(screen.getByText('Submit')).toBeInTheDocument();
  });

  it('calls onClick handler when clicked', () => {
    const handleClick = jest.fn();
    render(<Button label="Click me" onClick={handleClick} />);
    fireEvent.click(screen.getByText('Click me'));
    expect(handleClick).toHaveBeenCalledTimes(1);
  });
});

• Ключевое: Тестируем логику и поведение, не внутреннюю реализацию.

Integration Testing (Интеграционное тестирование)

• Цель: Проверить взаимодействие нескольких компонентов, модулей или с внешними сервисами (API).
• Инструменты: Jest, Cypress (для компонентной интеграции), моки для API.
• Пример: Тестирование формы, которая включает Input, Button и взаимодействует с хуком для отправки данных. Проверяем, что при заполнении и submit данные корректно собираются и отправляются (мок запроса).

End-to-End (E2E) Testing

• Цель: Проверить ключевые пользовательские сценарии в реальной или близкой к реальной браузерной среде.
• Инструменты: Cypress (мощный и удобный) или Playwright (для кросс-браузерных сложных сценариев).
• Пример: Тест регистрации пользователя:

// Cypress тест
describe('User Registration', () => {
  it('should successfully register a new user', () => {
    cy.visit('/register');
    cy.get('[data-testid="email-input"]').type('test@example.com');
    cy.get('[data-testid="password-input"]').type('securePass123');
    cy.get('[data-testid="submit-button"]').click();
    cy.url().should('include', '/dashboard');
    cy.contains('Welcome, test@example.com').should('be.visible');
  });
});

2. Дополнительные критически важные виды тестирования

• Статический анализ (Static Testing): Использование ESLint и TypeScript для предотвращения ошибок на этапе написания кода.
• Тестирование доступности (A11y Testing): Инструменты axe-core (интегрированный в Jest или Cypress) и ручная проверка с screen reader для обеспечения соответствия WCAG.
• Тестирование производительности (Performance Testing): Мониторинг метрик с помощью Lighthouse CI, проверка времени загрузки, размера бандлов.
• Visual Regression Testing: Для сложных UI библиотек иногда использую Storybook + Chromatic или Playwright для сравнения скриншотов.

3. Процесс и интеграция в разработку

• Предкоммитное тестирование: Настройка pre-commit hooks (например, через husky) для запуска lint и unit тестов.
• CI/CD Pipeline: Вся пирамида запускается автоматически в GitHub Actions, GitLab CI или Jenkins на каждом PR и перед деплоем. E2E тесты часто выполняются в отдельном, более "тяжелом" шаге.
• Моки и фикстуры: Создаю централизованные фикстуры для данных и моки для API (с помощью MSW — Mock Service Worker) чтобы тесты были стабильными и не зависели от бэкенда.
• Тестовая культура: Начинаю с тестов для нового функционала (TDD для сложной логики), поддерживаю тестовое покрытие >80% для бизнес-логики, но не стремлюсь к 100% — это часто неэффективно.

4. Практические принципы

1. Тестируй поведение, не имплементацию. Это делает тесты устойчивыми к рефакторингу.
2. Избегай тестов, зависящих от другого теста. Каждый тест должен быть независимым.
3. Используй четкие и описательные названия (it и describe). Это документация.
4. Мокируй всё внешнее: API, localStorage, таймеры. Контролируем окружение.
5. E2E тесты — дорогие. Пиши их только для самых критичных пользовательских путей.

Итог: Моя цель — создать автоматизированный, многоуровневый щит, который быстро обнаруживает проблемы, дает уверенность при рефакторинге и позволяет безопасно и часто деплоить изменения. Это требует инвестиций в инфраструктуру, но многократно окупается в долгосрочной разработке сложных приложений.