Автотесты «на пальцах»

Автотесты «на пальцах»

Многие уверены, что работа программиста — писать код. Это не так. Работа программиста — приносить пользу, увеличивать прибыль и снижать издержки.

Автоматические тесты — инструмент снижения издержек. Есть тесты — смело и быстро добавляете фичи. Нет тестов — проверяете изменения вручную, теряете время и деньги.

Автотесты принято делить на три типа: модульные (юнит), сервисные и интеграционные (UI, браузерные, end‑to‑end, E2E) тесты.

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

Интеграционные тесты проверяют приложение целиком, когда все модули в сборе. Их задача — убедиться, что модули правильно соединены друг с другом. Кроме того, ими проверяют те части приложения, которые не имеют права сломаться: биллинг, регистрацию, оформление заказа. Интеграционные тесты длятся секунды, а иногда и минуты: запускаем приложение, загружаем его в браузер или эмулятор и «прокликиваем» сценарии.

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

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

Чем выше тест, тем он медленнее и дороже в создании и поддержке

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

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

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

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

Ещё по теме

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.

Веб‑разработка
Отправить
Поделиться
Запинить

Рекомендуем другие советы