x
 
Василий
24 октября 2019
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Первая часть: пирамида тестов


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

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

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

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

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

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

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

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

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

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

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

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

Ещё по теме

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

Поделиться
Отправить

Комментарии

Илья Сидорчик
19 апреля 2020

Василий, почему вы называете интеграционные тесты сервисными, а сквозные — интеграционными?

Памятка разработчика «Тестин-лайбрари»: testingjavascript.com
Документация Реакта, где перевели e2e как «сквозные»: ru.reactjs.org/docs/testing-environments.html


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

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

Вот такой веб 2.0.

Как бороться с багами? Часть десятая: не утонуть в багах и глюках Как организовать процесс сдачи задачи и код-ревью в рамках спринта? Типовые решения в вёрстке. Как форматировать ХТМЛ 9 Что нужно, чтобы сайт на Айфоне выглядел также как на Андроиде, а не в два раза меньше? 1




Недавно всплыло

6 Колледж, вуз или Школа бюро, доступный кайф в архитектуре, как устроен Дизайн-буфет, когда откроются продажи Бюросайна 1 7 Продолжение совета о системной фотосъёмке пластинок, часть 4 1