Home

Автор: Энди Найт (Andy Knight)

Оригинал статьи

Перевод: Ольга Алифанова

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

Копипаста

Дупликация кода – это его рак. Особенно он свирепствует в тест-автоматизации, потому что шаги тестов зачастую повторяются. Но это не причина дублировать код! Используйте лучшие практики при создании кода, или готовьтесь к тому, что я забракую ваш код на код-ревью!

Жесткое кодирование конфигурационных данных

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

Повторное считывание данных ввода для Каждого. Теста.

Конфигурационные файлы и данные ввода не должны меняться при прогоне набора тестов. Прекратите постоянно их считывать! Это непродуктивно. Считайте их один раз и держите в памяти в централизованно-доступной локации.

Оставление временных файлов или настроек

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

Неверные результаты теста

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

Неинформативные сообщения о падении

Вот яркий пример: «Тест упал». Это ни о чем мне не говорит. Почему он упал? Чего-то не хватает на веб-странице? Возникло непредвиденное исключение? Запрос службы вернул 500? СКАЖИТЕ ЖЕ МНЕ! В противном случае я вынужден тратить время на повторный прогон или даже дебаг этого теста. Падения к тому же могут быть непостоянными. Скажите мне, в чем проблема, в момент, когда она возникает!

Проверки находятся в поддерживающем коде

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

Обращение с булеан-методами как с проверками

Это распространенная ошибка новичков. Булеан-методы просто возвращают значение «правда/ложь». Они не могут (или, согласно моей предыдущей жалобе, не должны) содержать проверки. Однако я видел множество код-ревью, на которых программист вызывал булеан-метод, но ничего не делал с результатом. Упс.

Захоронение исключений

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

Отсутствие автоматического восстановления

Настоящая автоматизация означает отсутствие ручного вмешательства. Фреймворк автоматизации должен иметь встроенные способы восстановления после распространенных проблем. К примеру, при обрыве сетевого соединения он должен автоматически пытаться подсоединиться заново. Если тест падает, перезапустите его. Если прошло слишком много падений, или завершите прогон раньше, или на какое-то время поставьте его на паузу. Убедитесь, что механизмы восстановления встроены во фреймворк, а не сидят копипастой во всей базе кода. Суть повторных попыток (особенно для тестов) не в том, чтобы тупо гонять тесты, пока они не станут зелеными, а в том, чтобы преодолеть непредвиденные прерывания и собрать больше данных, чтобы лучше понять механизм падения. Прерывания неминуемо будут – расправьтесь с их возникновением. Убедитесь, что все падения логируются, чтобы разобраться в причинах.

Отсутствие логов

Пожалуйста, собирайте полезную информацию в логах. После падения отслеживать причины в коде автоматизации зачастую сложно, особенно если его писали не вы. Логирование помогает быстро выяснить ключевую причину падений. Оно также полезно для создания сценариев воспроизведения. Если я могу скопировать лог падающих тестов в баг-репорт и на этом его закончить, то АМИНЬ.

Жестко закодированное время ожидания

На это ни у кого нет времени! Автоматизация должна быть быстрой, время – деньги. Навязывание Thread.sleep (или эквивалента в вашем языке программирования) демонстрирует или лень, или отчаяние. Это бессмысленная трата ценного времени прогона. Она также создает гоночные условия: что, если время ожидания завершится раньше, чем что-то подготовится? Всегда используйте «умные» ожидания: активно и регулярно проверяйте систему через короткие интервалы, и прерывайтесь после разумного значения таймаута.

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