Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

"Нет", сказала я. "Измерение покрытия кода ничем не поможет, потому что оно не говорит о том, хороши ли наши тесты – оно только показывает, что наши тесты затрагивают определенные части кода".

Следующим предложением был подсчет строк кода. "Нет", сказала я. "Это тоже не поможет. Количество страниц в книге ничего не говорит о ее качестве, а количество строк кода ничего не говорит о качестве тестов".

"ОК", сказали они. "Как насчет количества тестов? Ну уж это-то покажет наш прогресс".

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

Тут они спросили "Так как же тогда выглядит ХОРОШИЙ тест?" Ответ на этот вопрос – тема этой статьи! Ниже – шесть признаков хорошего автотеста.

Он проверяет что-то важное

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

Вот пример того, что не стоит автоматизировать: допустим, вы тестируете новую страницу приложения и обнаруживаете, что в заголовке "Фамилия" опечатка - "Фмилия". Вы заводите баг, разработчик его исправляет, и вы проверяете фикс. Каковы шансы, что баг появится снова? Скорее всего, они невысоки; нет смысла писать автотест на проверку орфографии.

Он падает, когда должен

Новички в тест-автоматизации зачастую забывают убедиться, что их тест падает, когда должен упасть. Это произошло и со мной, когда я начинала писать на JavaScript. Я написала тест для проверки загрузки записи и была так счастлива, что она срабатывает; затем разработчик попросил меня проверить, упадет ли тест, если запись не соответствует ожиданиям. Он не упал! Оказалось, что я не понимала промисы; на самом деле я убеждалась в том, что промис существует, а не проверяла значение веб-элемента. Если ваши тесты срабатывают в 100% случаев вне зависимости от обстоятельств, это хорошо выглядит в отчетах, но в тестах нет смысла.

Он надежен

Тест должен давать точную информацию в ста процентах случаев. Этот уровень идеала, возможно, недостижим, но создатель теста должен к нему стремиться. Нестабильные тесты надо исправлять или истреблять. Нестабильный тест не может дать надежной информации: он упал из-за бага, или из-за свой нестабильности?

Его легко поддерживать

Автоматизированный тест-сьют, наполненный спагетти-кодом, неимоверно трудно поддерживать. При каждом изменении в коде приложения тратятся часы или дни на изменение тест-сьюьта. Код тестов должен быть чистым, осмысленным, хорошо организованным, и не повторяться.

Он быстро запускается

Автоматизированный регресс-набор, требующий восьми часов на запуск, не предоставит команде разработки быстрой обратной связи. Нам нужны тесты, запускающиеся максимально быстро, чтобы команда сразу узнала о проблеме. Ускорить автоматизацию можно множеством способов; мой любимый – это превосходство API-тестов над UI-тестами. Я предпочитаю иметь минимальное количество UI-тестов, и тестировать всю логику фич через API. Ускорение также возможно через параллельный запуск и однократную настройку перед прогоном набора вместо настройки перед каждым тестом.

Он запускается вовремя

Как тестировщики, мы часто стремимся проверить максимум возможного как можно чаще. Однако это не всегда эффективно. Смоук-тесты – хороший пример эффективного тестирования. Смоук-тест часто используется в ходе деплоя. Нам нужно небольшое количество смоук-тестов, чтобы сразу понять, как дела с деплоем. Более длинный регресс-набор лучше прогнать в другое время – возможно, ночью.

Как можно видеть, метрик недостаточно для оценки качества теста. Для этого нужно знать продукт, понимать его критические особенности, и иметь возможность оценить качество кода теста и его валидность.

Обсудить в форуме