Тесты для новичка: зачем и с чего начать

Зачем это в учебном проекте

Первая мысль новичка: «Проект маленький, я и так вижу, что всё работает». Пока проект на двести строк — правда. Дальше начинается интересное.

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

Тесты — это документация, которая не врёт. Комментарий может устареть, тест — нет: он либо проходит, либо падает.

Наличие тестов заметно на собеседовании. Проект с тестами выделяется среди сотен без них, потому что показывает: человек думает о последствиях своих изменений.

Какие бывают

Модульные. Проверяют одну функцию отдельно. Быстрые, их много.

Интеграционные. Проверяют, что несколько частей работают вместе: обработчик запроса дошёл до базы и вернул правильное.

Сквозные. Имитируют действия человека в браузере от начала до конца. Медленные, их мало.

Разумная пропорция для маленького проекта: много модульных, несколько интеграционных, два-три сквозных на главные сценарии.

С чего начинать

Не с покрытия всего подряд. С трёх мест:

1. Логика, где легко ошибиться. Расчёты, обработка дат, разбор строк, проверка вводимых данных. Именно тут ошибки живут дольше всего.

2. То, что уже ломалось. Нашли ошибку — напишите тест, который её воспроизводит, потом чините. Так она не вернётся.

3. Главный сценарий. Один сквозной тест: человек зашёл, сделал основное действие, увидел результат. Если он проходит, проект жив.

Как выглядит тест

Три части: подготовили данные, выполнили действие, проверили результат.

def test_short_text_not_cut():
    result = shorten("Привет", 10)
    assert result == "Привет"

def test_long_text_cut_with_ellipsis():
    result = shorten("Очень длинный текст", 10)
    assert result.endswith("…")
    assert len(result) == 11

Важно: одно название теста — одна проверяемая мысль. По имени должно быть понятно, что сломалось, без чтения кода.

Что проверять обязательно

Крайние случаи — там, где ошибки:

• пустой ввод;
• один элемент;
• очень большое значение;
• отрицательное число, где ждали положительное;
• отсутствующие данные.

Правило: если функция принимает список, тест на пустой список нужен всегда.

Про покрытие

Показатель покрытия — сколько строк выполнилось при прогоне тестов. Полезен как ориентир и вреден как цель.

Стопроцентное покрытие бессмысленных проверок хуже, чем тридцать процентов осмысленных. Гнаться за цифрой — распространённая ошибка.

Чего не надо тестировать

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

С чего начать сегодня

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