Автотесты «на пальцах»
Пирамида тестов
Интеграционные тесты
Автотесты «на пальцах»
Пирамида тестов
Интеграционные тесты
Многие уверены, что работа программиста — писать код. Это не так. Работа программиста — приносить пользу, увеличивать прибыль и снижать издержки.
Автоматические тесты — инструмент снижения издержек. Есть тесты — смело и быстро добавляете фичи. Нет тестов — проверяете изменения вручную, теряете время и деньги.
Автотесты принято делить на три типа: модульные (юнит), сервисные и интеграционные (UI, браузерные, end‑to‑end, E2E) тесты.
Модульные тесты проверяют работу отдельно взятых модулей — функций, классов, моделей, контроллеров — кирпичиков, из которых построено приложение. Модульные тесты выполняют проверки за миллисекунды, потому что тестируют модуль в отрыве от остального приложения.
Интеграционные тесты проверяют приложение целиком, когда все модули в сборе. Их задача — убедиться, что модули правильно соединены друг с другом. Кроме того, ими проверяют те части приложения, которые не имеют права сломаться: биллинг, регистрацию, оформление заказа. Интеграционные тесты длятся секунды, а иногда и минуты: запускаем приложение, загружаем его в браузер или эмулятор и «прокликиваем» сценарии.
Сервисные тесты — среднее между интеграционными и модульными. Их задача — проверить функционал, который нельзя уверенно протестировать модульными тестами, а интеграционными тестировать «слишком жирно».
Такое разбиение тестов по уровню детализации программисты используют в «тестовой пирамиде» — визуальной метафоре, которая подсказывает, сколько каких тестов лучше иметь:
Идея простая: чтобы у приложения была быстрая и отзывчивая к изменениям тестовая база, большая её часть должна приходиться на модульные тесты, небольшая часть — на сервисные, малая часть — на интеграционные.
Покажу на примере. Представим, что нужно запрограммировать добавление комментариев к фотографиям. Если отказаться от модульных тестов и всё проверить интеграционными, мы получим очень медленную и хрупкую тестовую базу. Работать с такими тестами будет мучительно: любые изменения в коде будут проверяться минутами.
Если отказаться от интеграционных тестов и всё проверить модульными, может оказаться так, что тесты проходят, а добавление комментариев не работает из‑за ошибки на стыке модулей. Доверять таким тестам нельзя, придётся добавление комментариев проверять вручную.
Поэтому лучше начать с единственного интеграционного теста, который открывает фотографию в браузере, заполняет форму, нажимает «Отправить» и проверяет, что комментарий появился на странице. А затем добавить модульных и сервисных тестов, которые проверят всё остальное: автоматическое форматирование текста комментария, санитайзинг, валидацию и почтовое уведомление автору фотографии.
Ещё по теме
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.