Ответ.

Автоматические тесты делят на юнит (unit), интеграционные (integration) и сквозные (end-to-end, E2E), чтобы комплексно покрывать проверку системы на разных уровнях.

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

конкретная функция (unit)
взаимодействие частей (integration)
вся система, работающая как для пользователя (E2E)

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

Решение:

Юнит-тесты проверяют изолированный код, как правило, на уровне функций или несложных классов. В продвинутых случаях используют моки и стабы.
Интеграционные тесты — связывают между собой несколько компонентов (например, модуль и БД), чтобы увидеть, как они работают в связке.
End-to-end тесты (E2E) имитируют сценарии пользователя — весь путь "от кнопки до результата".

Различать типы тестов жизненно необходимо, чтобы:

Минимизировать стоимость поддержки (E2E тесты дорогие)
Держать быструю обратную связь (юнит тесты молниеносные)
Уменьшать количество ложных срабатываний

Ключевые особенности:

Правильное распределение тестов помогает строить надежный "пирамидальный" подход (тестировочная пирамида).
Смешивание стилей тестирования ведет к проблемам локализации багов.
Четкое понимание назначения каждого слоя приводит к максимальной эффективности.

Вопросы с подвохом.

Можно ли считать интеграционные тесты просто "большими" юнит-тестами?

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

Должны ли все тесты быть сквозными (E2E)?

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

Юнит-тесты всегда быстрые?

Не всегда. Бывает, что изолировать код не удаётся, или у метода зависят сложные внешние ресурсы. В таком случае, тест перестает быть юнитом.

Типовые ошибки и анти-паттерны

Все тесты пишутся только сквозными, обратная связь получается крайне медленной.
Путаница в слоях: юнит-тест начинает дергать БД или API, а E2E строятся на моках.
Оставляют только юнит-тесты — проблемные баги на стыках компонентов не ловятся.

Пример из жизни

Негативный кейс

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

Плюсы:

Настоящие сценарии пользователя покрыты.

Минусы:

Медленная обратная связь.
Долгие разборы причин поломок.
Много ложных срабатываний.

Позитивный кейс

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