Юнит-тесты: проверяем код автоматически

Представьте, что вы разработали сложную функцию для расчета скидок в интернет-магазине. Код работает отлично, но через месяц коллега вносит небольшие изменения в другую часть приложения — и внезапно ваши расчеты начинают выдавать неверные результаты. Как вовремя обнаружить такую проблему? Ответ прост: юнит-тесты.

Что такое юнит-тесты

Юнит-тесты (unit tests) — это автоматические проверки небольших участков кода, обычно отдельных функций или методов. Они работают как контрольные точки, которые постоянно проверяют, что ваш код ведет себя именно так, как задумано.

Основная идея проста: вы пишете код, который вызывает вашу функцию с известными входными данными и проверяет, что результат соответствует ожидаемому. Если результат правильный — тест проходит, если нет — тест падает и сообщает об ошибке.

Зачем нужны юнит-тесты

Начинающие разработчики часто задаются вопросом: зачем тратить время на написание тестов, если можно просто проверить код вручную? Причин несколько.

Первая причина — уверенность в рефакторинге. Когда у вас есть покрытие тестами, вы можете смело улучшать код, зная, что если что-то сломается, тесты сразу об этом сообщат. Это как страховочная сеть для акробата.

Вторая причина — документация. Хорошо написанные тесты показывают, как должна использоваться функция, какие входные данные она принимает и что возвращает. Это живая документация, которая всегда актуальна.

Третья причина — экономия времени в долгосрочной перспективе. Да, написание тестов требует времени сейчас, но это сэкономит часы отладки в будущем. Автоматические тесты запускаются за секунды и проверяют весь функционал, тогда как ручное тестирование может занять часы.

Простой пример

Давайте рассмотрим практический пример на JavaScript. Предположим, у нас есть функция для валидации email-адресов:

function isValidEmail(email) {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return emailRegex.test(email);
}

Теперь напишем для неё юнит-тест с использованием популярного фреймворка Jest:

describe('isValidEmail', () => {
  test('должна вернуть true для правильного email', () => {
    expect(isValidEmail('user@example.com')).toBe(true);
  });

  test('должна вернуть false для email без @', () => {
    expect(isValidEmail('userexample.com')).toBe(false);
  });

  test('должна вернуть false для email без домена', () => {
    expect(isValidEmail('user@')).toBe(false);
  });

  test('должна вернуть false для пустой строки', () => {
    expect(isValidEmail('')).toBe(false);
  });
});

Каждый тест проверяет конкретный сценарий. Если кто-то изменит регулярное выражение и случайно сломает валидацию, тесты сразу это обнаружат.

Принципы написания хороших тестов

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

Тесты должны быть быстрыми. Если запуск всех тестов занимает минуты, разработчики будут запускать их реже. Юнит-тесты должны выполняться за миллисекунды, чтобы можно было запускать их после каждого изменения кода.

Тесты должны быть понятными. Когда тест падает, вы должны сразу понимать, что именно сломалось. Используйте описательные имена тестов и четкие сообщения об ошибках.

AAA-паттерн

Популярный подход к структурированию тестов — это AAA-паттерн: Arrange, Act, Assert (Подготовка, Действие, Проверка).

test('должна правильно рассчитать скидку 10%', () => {
  // Arrange — подготовка данных
  const price = 1000;
  const discount = 10;
  
  // Act — выполнение действия
  const result = calculateDiscount(price, discount);
  
  // Assert — проверка результата
  expect(result).toBe(900);
});

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

Тестирование граничных случаев

Одна из самых важных задач юнит-тестов — проверка граничных случаев. Это ситуации, которые находятся на краю допустимых значений: пустые массивы, нулевые значения, максимальные числа, специальные символы.

describe('calculateAge', () => {
  test('должна вернуть 0 для новорожденного', () => {
    const today = new Date();
    expect(calculateAge(today)).toBe(0);
  });

  test('должна обработать високосный год', () => {
    const birthDate = new Date('2000-02-29');
    expect(calculateAge(birthDate)).toBeGreaterThan(0);
  });

  test('должна выбросить ошибку для даты в будущем', () => {
    const futureDate = new Date('2030-01-01');
    expect(() => calculateAge(futureDate)).toThrow();
  });
});

Именно граничные случаи чаще всего становятся источником багов в production.

Моки и стабы

Часто функция зависит от внешних сервисов: баз данных, API, файловой системы. Для юнит-тестов мы не хотим использовать реальные внешние ресурсы — это медленно и ненадежно. Вместо этого используются моки (mocks) и стабы (stubs).

// Функция, которую тестируем
async function getUserData(userId) {
  const response = await fetch(`/api/users/${userId}`);
  return response.json();
}

// Тест с моком
test('должна получить данные пользователя', async () => {
  // Создаем мок для fetch
  global.fetch = jest.fn(() =>
    Promise.resolve({
      json: () => Promise.resolve({ id: 1, name: 'Алексей' })
    })
  );

  const userData = await getUserData(1);
  
  expect(userData.name).toBe('Алексей');
  expect(fetch).toHaveBeenCalledWith('/api/users/1');
});

Моки позволяют изолировать тестируемый код и проверить, что функция правильно взаимодействует с внешними зависимостями.

Покрытие кода тестами

Покрытие кода (code coverage) показывает, какой процент вашего кода выполняется во время тестов. Большинство инструментов тестирования могут генерировать отчеты о покрытии.

Однако важно понимать, что 100% покрытие не гарантирует отсутствие багов. Покрытие показывает, что код был выполнен, но не гарантирует, что он был проверен на все возможные сценарии. Стремитесь к разумному покрытию критически важных частей кода.

Тестирование в разных языках

Концепция юнит-тестов универсальна, но инструменты различаются в зависимости от языка программирования.

В Python популярны фреймворки pytest и unittest. Они предоставляют простой синтаксис для написания тестов и множество встроенных утилит для проверок.

В JavaScript и TypeScript используются Jest, Mocha, Jasmine. Jest особенно популярен благодаря встроенной поддержке моков и удобному API.

Во Vue.js приложениях часто применяется Vue Test Utils в связке с Jest, что позволяет тестировать компоненты в изоляции, проверять их отрисовку и взаимодействие с пользователем.

В Java традиционно используется JUnit, а для PHP — PHPUnit. Каждый из этих инструментов адаптирован под особенности своего языка, но основные принципы остаются одинаковыми.

TDD: разработка через тестирование

Некоторые команды практикуют TDD (Test-Driven Development) — подход, при котором тесты пишутся до написания основного кода. Процесс выглядит так: сначала вы пишете падающий тест, описывающий желаемое поведение, затем пишете минимальный код, чтобы тест прошел, и наконец, рефакторите код, сохраняя тесты зелеными.

Такой подход помогает лучше продумать архитектуру и гарантирует, что весь код покрыт тестами. Однако TDD требует дисциплины и не всегда подходит для экспериментальных проектов.

Когда не нужны юнит-тесты

Честно говоря, не весь код нуждается в юнит-тестах. Простые геттеры и сеттеры, тривиальные функции форматирования, UI-компоненты без логики — всё это может обойтись без тестов или покрываться интеграционными тестами.

Сосредоточьтесь на тестировании бизнес-логики, сложных алгоритмов, функций с условной логикой и кода, который критичен для работы приложения. Именно здесь тесты принесут максимальную пользу.

Хотите глубже изучить тестирование и другие практики профессиональной разработки?

Приложение Кодик предлагает интерактивные курсы по Python, JavaScript и многим другим технологиям. Обучение построено от простого к сложному с практическими заданиями и реальными примерами.

Присоединяйтесь к нашему Telegram-каналу, где вы найдете активное сообщество разработчиков, готовых помочь с любыми вопросами, поделиться опытом и поддержать на пути изучения программирования!