Home

Автор: Ричард Брэдшоу (Richard Bradshaw)

Оригинал статьи: http://www.thefriendlytester.co.uk/2016/08/give-your-automated-checks-voice.html

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

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

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

Время выполнения

Несколько лет назад я много работал над проектами для digital-агентств. Это были средне- и краткосрочные проекты (от трех до шести месяцев), и я старался писать максимально много автотестов, потому что быстрая обратная связь была очень и очень важна. Изменения вносились в последнюю секунду, хотфикс там, патчик сям… Нет, я не возражаю против таких темпов, но с ними надо уметь уживаться. Обратная сторона всех этих перемен – за ними не успевает "традиционное" тестирование, и в моем случае это было тестирование производительности. Я никогда ранее им не занимался (да и сейчас не занимаюсь), но теперь я знаю, как можно выкрутиться в такой ситуации.

Я изменил подход к проверкам и начал сохранять время выполнения моих автотестов. К сожалению, на проекте не использовалась непрерывная интеграция (нас это, конечно, не извиняет, но дело было шесть лет назад). Все автотесты стартовали с моей машины сразу же после деплоя новой версии. После каждого прогона я сохранял временные отметки в таблицу. Я запускал их, как правило, дважды в день, и собрал неплохой массив данных.

Я это сделал, думая, что такая метрика может сообщить мне о неожиданных отклонениях во времени выполнения проверок – а это может потенциально означать проблему производительности, которая, возможно, заинтересует команду.

Сработало ли это? Да, и обнаружило две проблемы. Первая была связана с продуктом. После рефакторинга SQL-запросов с целью улучшить их произошло, к сожалению, ровным счетом противоположное. Конечно, обнаружить это можно было и другим способом, но нам помогло использование собранных мною данных.

Причиной второй проблемы стал я сам! =)

Я провел рефакторинг части кода Selenium и обновил версию – и что-то пошло не так. Время выполнения тестов увеличилось на 50%. Как оказалось, я написал кривоватый код, но и в релизе был пойман баг, найденный благодаря моей табличке.

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

Правила

"Ожидалось true, фактический результат: false"

"Ожидалось 6, фактический результат – 5".

Уверен, вы видели подобные упавшие проверки. Прекратите их писать! Все тест-фреймворки, которые я когда-либо видел, позволяют вам включать в правила сообщения, ну так используйте эту функциональность!

Что в примерах выше должно было быть true? Шесть штук чего? Простенькое сообщение, вводящее читателя в контекст правила, сильно ускорит дебаг.

"Я ожидал, что количество пользователей будет равно 6, но оно было равно 5". Простенькое String.Format – и все стало куда понятнее.

Многие, возможно, возразят, что само название проверки должно информировать о том, к чему относится правило. Да, я видал такое, но неужели добавление сообщения ухудшит ситуацию? Лично мне это сэкономило немало времени при дебаге упавших проверок.

Скажи мне все, что знаешь

Распространенная, насколько я могу судить, практика – заставить Selenium-проверки делать скриншот в случае падения. Это здорово, и очень полезно – скриншот помогает понять суть проблемы. Однако большинство приложений могут гораздо больше!

Извлеките пользу из кода, который предлагают вам Selenium-проекты. Подключитесь к обработчику событий, чтобы выводить сообщения на консоль. Дайте роботам заговорить! "Я нажал на кнопку <locator>", "Я ввел "name" в элемент <locator>". "Я подождал <element> Х секунд". Эти сообщения рассказывают о ходе проверки, и если она упала, они крайне ускоряют дебаг.

Что касается самого приложения – как насчет логов? Если они есть, пусть упавшая проверка складывает логи в определенное место, чтобы их можно было быстренько добыть, а не искать вручную. Я так делал! Я даже заставил проверку выбирать лог только за определенный период времени, отталкиваясь от времени старта прогона проверки. Это сэкономило немало времени на просмотр логов.

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

Почему меня никто не любит?

"На меня никто не обращает внимания, мне плохо и одиноко". Конечно, странно, если ваши автотесты внезапно сообщат вам нечто подобное, но я веду речь о последних изменениях ваших проверок и пересмотре их ценности.

Да, я тоже совершал эту ошибку. У меня были проверки, которые здравствовали в течение всего срока моей работы, и я никогда их не пересматривал – все зеленое, значит, все хорошо! Майкл Болтон писал статью на эту тему. Однако это совершенно не значило, что проверка была чем-то полезна для меня – я так давно не копался в ней, что уже даже не помнил, а что же конкретно она там проверяет.

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

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

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

Заключение

Подумайте, что еще могут поведать вам ваши тесты, подумайте о данных, которыми они с вами делятся, и которые могут помочь вам тестировать.

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