Home

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

Оригинал статьи: http://www.thefriendlytester.co.uk/2016/02/why-was-this-check-created.html

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

Я много размышлял о проверках и тестах и том, как заставить их гармонично сосуществовать, и подумал, что мы упускаем что-то важное, создавая проверки. Я сконцентрируюсь на автоматических проверках, но думаю, что мои мысли применимы и к неавтоматическим.

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

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

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

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

Явный ответ на вопрос "почему это существует", как мне кажется, улучшит наш тест-дизайн. Это также будет полезно при ревью автотестов, когда мы решаем подправить или удалить уже существующие. Я вообще считаю, что пересматривать автотесты и переоценивать их значимость нужно регулярно. То, что проверка не упала, совершенно не означает, что вам это чем-то помогло и повысило ценность тестирования. Возвращаясь к тест-дизайну: предположим, упала проверка, созданная по причине "На проде были большие проблемы, когда система делала Х, и это приводило к падению на Y часов". Если бы я увидел, что проверка с таким обоснованием создания упала - возможно, я бы тщательнее отнесся к тестированию этой конкретной области, чем если бы обоснования не существовало. При ревью автотестов такой комментарий экономит время и силы на оценку полезности проверки.

Вот несколько способов указания цели создания проверки:

1. 1. Комментарии в коде. И незачем так укоризненно на меня смотреть. Я не говорю о том, чтобы в принципе использовать их - как я уже говорил выше, это все умеют. Я говорю о паре строк перед проверкой, объясняющих, зачем она была написана.
2. 2. BDD-инструменты. Хоть я и не советую их использовать при создании автотестов (особенно там, где BDD-подход не практикуется), я знаю, что многие активно ими пользуются. Эти инструменты позволяют внести обоснование создания проверки в секцию "сценарий".
3. 3. Информация о коммите. Возможно, мы можем договориться добавлять внятные обоснования создания проверок, когда они коммитятся в репозиторий. Чтобы вернуться к этой информации, достаточно будет посмотреть историю коммитов. Подход сработает хуже, если проверки часто перемещаются во время рефакторинга.
4. 4. Внешняя документация. Может, обоснования проверок уместно хранить во внешних файлах - ментальной карте, например, с идентификаторами всех проверок.

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