Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой статье я хочу ответить на вопрос, заданный мне в LinkedIn Полом Сименом (Paul Seaman). Он спросил, что я думаю о документировании автоматизированных тест-кейсов как способе продемонстрировать, что автоматизация вообще делает.

Краткий ответ: я не определился.

Это, конечно, не очень-то полезный ответ, да и статья вышла бы странно короткой – постараюсь развить свою мысль.

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

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

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

«Что мы покрываем нашими автотестами?»

Знание, что делают ваши тесты – полезное знание. Но создание (и поддержка) документации для тестов – не идеальное решение, с моей точки зрения. Почему?

Потому что ваши тесты И ЕСТЬ документация

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

• Читабельность: читая тесты, вы не отвлекаетесь на детали их внедрения;
• Поддерживаемость: с шансами низкоуровневые элементы (методы и классы для тестов на основе кода, или другие блоки из малокодовых решений) можно использовать повторно.

Вот тест для ваших тестов: найдите человека, который хорошо знает тестируемое приложение, но не работал над внедрением ваших тестов. Попросите его взглянуть на ваши тесты. Сможет ли он сказать, что они делают? Насколько подробные объяснения им потребуются, прежде чем посмотреть тесты? Если вам нужно многое объяснять, то ваши тесты, вероятно, не очень-то самодокументируемы.

А как насчет Cucumber / SpecFlow / Behave / вставить любимую BDD-библиотеку?

Безусловно, это отличные инструменты (я, скажем, большой поклонник SpecFlow), но их использование имеет свою цену. Если документация, точнее, спецификации, не создаются командой сообща, цена создания и поддержки Gherkin-уровня поверх ваших тестов зачастую не стоит свеч, и, возможно, лучше просто переписать тест, чтобы он был более говорящим.

Я уже писал именно об этой проблеме и дал несколько советов, как сделать тесты читабельнее, не прибегая к Gherkin.

Итак, вкратце моим советом будет добиться, чтобы ваши тесты были максимально говорящими. Повторюсь – тесты и есть документация.

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

Это означает, что при падении теста это должно каким-то образом отражаться в документации – к примеру, подсвечиваться красным, добавляться в форме заметки или скриншота. Способ неважен – но читателям документации должно быть ясно, что что-то пошло не так.

Иными словами, создавайте живую документацию своих тестов. Уже упомянутые Cucumber, SpecFlow, Behave и другие BDD-инструменты отлично это умеют, но для создания активных связей есть и другие способы.

Если такой связи между документацией и тестами не существует, то с высоким шансом ваша документация устареет при первом же изменении ПО. Рассматривайте документацию, как еще один уровень абстракции ваших тестов. Как и любой другой уровень абстракции, она должна синхронизироваться с происходящим под капотом.

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

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

Или же наша документация идет той же дорогой, что и мастер-план тестирования?

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