> Тестирование кода для разработчика: юнит-тесты, итеграционные и E2E

Тестирование кода давно перестало быть опциональным навыком. На собеседованиях всё чаще спрашивают алгоритмы, структуры данных и подходы к проверке собственного кода. Вопросы вида "какие тесты вы пишете и почему" звучат на позициях от junior до senior, при этом у многих кандидатов есть разрыв между теорией и практикой: они знают определения, но не могут объяснить, когда какой вид тестов уместен и как не превратить тесты в источник постоянной боли.

Разница между видами тестов: юнит, интеграционные, E2E

Любой тест отвечает на вопрос "работает ли система так, как ожидается?". Но уровень этой проверки различается. Юнит-тесты проверяют изолированный фрагмент кода - функцию, метод, класс. Интеграционные тесты проверяют взаимодействие нескольких модулей, например, кода с базой данных или внешним API. E2E (end-to-end) тесты воспроизводят полный сценарий пользователя через интерфейс приложения.

Граница между видами не всегда жёсткая. Например, тест, который вызывает метод репозитория и проверяет запрос к базе - это уже интеграционный, хотя формально он может жить в том же файле, что и юнит-тесты. Важно понимать цель: юнит-тест ловит ошибку в логике конкретной функции, интеграционный - в согласованности интерфейсов, E2E - в том, что пользовательский сценарий действительно работает.

Когда использовать каждый вид

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

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

E2E-тесты - самые дорогие и хрупкие. Они запускают браузер или полноценное приложение и проходят по сценарию: пользователь открывает страницу, вводит данные, нажимает кнопку, видит результат. E2E нужны для критически важных путей - регистрация, оплата, вход в систему. Их не должно быть много, иначе поддержка превращается в постоянную борьбу с таймаутами и селекторами. Обычно достаточно 5-10 E2E-тестов на ключевые сценарии, а всё остальное покрывается нижними уровнями.

Как писать эффективные тесты

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

Принципы полезных тестов

• Тестируйте поведение. Вместо проверки того, что метод вызван с определёнными аргументами, проверяйте, что результат корректен. Например, для функции calculateTotal не нужно проверять, что внутри вызывается applyDiscount - достаточно проверить итоговую сумму.

• Изолируйте внешние зависимости. Юнит-тест не должен ходить в сеть или читать файлы. Для этого используют моки и стабы. Это делает тесты быстрыми и детерминированными.

• Пишите тесты на граничные случаи. Пустые строки, нулевые значения, отрицательные числа, максимальные значения - именно там прячутся баги. Один тест на "счастливый путь" недостаточен.

• Поддерживайте читаемость. Тест - это документация. Название должно описывать ожидаемое поведение: test_apply_discount_when_total_above_threshold понятнее, чем test_calc_1.

• Не гонитесь за 100% покрытием. Покрытие - метрика, а не цель. Лучше 70% покрытия на важной логике, чем 95% на тривиальных геттерах и сеттерах.

Частые ошибки новичков

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

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

Инструменты и подходы

Выбор инструмента зависит от языка и стека. В JavaScript-экосистеме стандарт - Jest, в Python - pytest, для E2E часто используют Selenium или Playwright. Рассмотрим каждый.

Jest для юнит-тестов в JavaScript

Jest - фреймворк от Facebook, который включает в себя тест-раннер, ассерты, моки и покрытие. Он работает с React, Node.js и TypeScript. Пример простого юнит-теста:

JAVASCRIPT
// calculate.js
export function calculateTotal(items, discount = 0) {
  const subtotal = items.reduce((sum, item) => sum + item.price, 0);
  return subtotal * (1 - discount);
}

// calculate.test.js
import { calculateTotal } from './calculate';

test('calculateTotal returns subtotal when no discount', () => {
  const items = [{ price: 100 }, { price: 200 }];
  expect(calculateTotal(items)).toBe(300);
});

test('calculateTotal applies discount correctly', () => {
  const items = [{ price: 100 }, { price: 200 }];
  expect(calculateTotal(items, 0.1)).toBe(270);
});

test('calculateTotal handles empty items', () => {
  expect(calculateTotal([])).toBe(0);
});

Jest удобен тем, что моки встроены: jest.fn(), jest.mock(). Например, чтобы замокать модуль работы с API:

JAVASCRIPT
jest.mock('./api', () => ({
  fetchUser: jest.fn(() => Promise.resolve({ id: 1, name: 'Alice' })),
}));

pytest для Python

pytest - гибкий и лаконичный фреймворк. Он поддерживает фикстуры, параметризацию и плагины. Пример:

PYTHON
# calculator.py
def calculate_total(items, discount=0):
    subtotal = sum(item['price'] for item in items)
    return subtotal * (1 - discount)

# test_calculator.py
import pytest
from calculator import calculate_total

def test_no_discount():
    items = [{'price': 100}, {'price': 200}]
    assert calculate_total(items) == 300

def test_discount_applied():
    items = [{'price': 100}, {'price': 200}]
    assert calculate_total(items, 0.1) == 270

@pytest.mark.parametrize('items,expected', [
    ([], 0),
    ([{'price': 50}], 50),
])
def test_edge_cases(items, expected):
    assert calculate_total(items) == expected

pytest позволяет писать тесты без классов, что сокращает код. Фикстуры помогают подготовить окружение, например, временную базу данных:

PYTHON
@pytest.fixture
def db_connection():
    conn = create_connection(':memory:')
    yield conn
    conn.close()

Selenium и альтернативы для E2E

Selenium - классический инструмент для автоматизации браузера. Он поддерживает Java, Python, JavaScript и другие языки. Пример на Python:

PYTHON
from selenium import webdriver
from selenium.webdriver.common.by import By

def test_login():
    driver = webdriver.Chrome()
    driver.get('https://example.com/login')
    driver.find_element(By.NAME, 'username').send_keys('testuser')
    driver.find_element(By.NAME, 'password').send_keys('secret')
    driver.find_element(By.CSS_SELECTOR, 'button[type="submit"]').click()
    assert driver.find_element(By.CLASS_NAME, 'welcome').is_displayed()
    driver.quit()

Selenium гибок, но требует аккуратной работы с ожиданиями. Часто используют явные ожидания, чтобы избежать гонок:

PYTHON
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)
wait.until(EC.presence_of_element_located((By.CLASS_NAME, 'welcome')))

В современных проектах Selenium часто заменяют Playwright или Cypress - они быстрее и стабильнее, но Selenium остаётся стандартом для легаси и мультиязычных команд.

Практические примеры из подготовки к собеседованиям

На собеседованиях часто дают задачу на написание тестов для функции или класса. Например, просят покрыть тестами функцию validateEmail. Кандидат, который пишет только один тест на валидный email, показывает слабое понимание. Сильный ответ включает проверки на отсутствие @, на точки в неправильных местах, на пустую строку, на длину.

Другой типичный вопрос: "Как бы вы протестировали API-эндпоинт?". Здесь важно упомянуть интеграционные тесты с реальной базой или моком, проверку статус-кодов, валидацию ответа, обработку ошибок. Например, для эндпоинта POST /users нужно проверить: успешное создание (201), невалидные данные (400), конфликт с существующим пользователем (409).

Также на собеседованиях спрашивают про стратегию тестирования в проекте. Хороший ответ - пирамида: много юнит-тестов, меньше интеграционных, ещё меньше E2E. Объяснение: юнит-тесты быстрые и дешёвые, E2E медленные и хрупкие, поэтому их количество должно быть минимальным.

Пример: тестирование функции расчёта скидки

Возьмём функцию, которая рассчитывает скидку в зависимости от суммы заказа. Задача - написать тесты, которые покрывают все ветки.

JAVASCRIPT
function getDiscount(total) {
  if (total >= 1000) return 0.2;
  if (total >= 500) return 0.1;
  return 0;
}

Тесты должны включать:

• total = 1000 → 0.2

• total = 999 → 0.1

• total = 500 → 0.1

• total = 499 → 0

• total = 0 → 0

• total = -100 → 0 (или ошибка, если так задумано)

Такой набор проверяет границы условий, что и есть суть юнит-тестирования.

Как интегрировать тесты в рабочий процесс

Тесты полезны, когда они запускаются регулярно. В идеале - в CI/CD на каждый коммит. Для этого нужно настроить скрипты: npm test, pytest, mvn test и так далее. В CI можно разделить запуск: быстрые юнит-тесты на каждый пуш, интеграционные и E2E - на pull request или перед деплоем.

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

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

Рекомендации для подготовки к собеседованию

Чтобы уверенно отвечать на вопросы о тестировании, стоит:

• Написать юнит-тесты для нескольких функций из своего портфолио, используя Jest или pytest.

• Разобрать, как тестировать взаимодействие с базой данных: на реальной тестовой БД или с моком.

• Попрактиковаться в написании E2E-сценария на простом сайте, например, на собственном pet-проекте.

• Изучить, как работает покрытие кода, и уметь объяснять, почему 100% не всегда хорошо.

• Подготовить примеры из реального опыта: когда тесты помогли найти баг, как вы рефакторили код под тесты.

Также полезно знать термины: mock, stub, fixture, параметризация, TDD (test-driven development). TDD - подход, при котором тесты пишутся до кода. На собеседовании могут спросить отношение к TDD; стоит дать сбалансированный ответ: TDD полезен для сложной логики, но не всегда обязателен.

Заключение

Тестирование - это навык, который развивается практикой. Начать стоит с юнит-тестов на ключевых функциях, затем добавить интеграционные для взаимодействия с внешними системами, и только потом - E2E для критических сценариев. Инструменты вроде Jest и pytest делают процесс простым, а понимание принципов - поведенческое тестирование, изоляция зависимостей, граничные случаи - помогает писать тесты, которые действительно защищают код.

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