Home

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

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

Вот ряд примеров:

«Нормально ли иметь несколько ассертов в тесте?»

«Нужно ли писать код автотестов на том же языке, что и код приложения?»

«Помогите, в коде есть дупликация, нужен ли тут рефакторинг?»

На первый взгляд это совершенно разные вопросы, но у них есть общий знаменатель – все они связаны с существующими догмами (или принципами) тестирования и автоматизации:

«Нормально ли иметь несколько ассертов в тесте?» -> Догма: «у теста должно быть одно и только одно условие падения».

«Нужно ли писать код автотестов на том же языке, что и код приложения?» -> Догма: «тесты нужно писать на том же языке, на котором написано приложение».

«Помогите, в коде есть дупликация, нужен ли тут рефакторинг?» -> Догма: «Да не допустишь ты дупликации в коде своем».

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

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

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

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

«Нормально ли иметь несколько ассертов в тесте?»

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

Однако если чересчур следовать догмам, это может привести к большой дупликации в настройке теста, так как вам, возможно, понадобится воссоздавать одно и то же состояние для множества ассертов. Представьте себе, например, окно подтверждения, на котором находится сообщение об успешном оформлении заказа, а также содержание этого заказа, сделанного вами в интернет-магазине. При догматичном подходе «один тест – один ассерт» вам придется создавать два заказа, по одному на проверку. Возможно, это чересчур для относительно простой проверки.

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

• Артикул успешно добавляется в корзину,
• Корзина верно подсчитывает общее количество товаров и их цену,
• Все необходимые варианты оплаты доступны,
• Стоимость доставки верно рассчитана,

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

Возьмем еще пример – вопрос «Помогите, в коде есть дупликация, нужен ли тут рефакторинг?», который мы уже видели.

При догматичном подходе вы, возможно, примените принцип DRY (Don’t Repeat Yourself – не повторяйся) везде и всюду, чтобы избежать абсолютно всей дупликации. И до какой-то степени это будет хорошей идеей. Выделение последовательностей-дубликатов в отдельные методы, создание слоев абстракции (к примеру, использование паттернов Page Object/Screenplay в UI-автоматизации) даст вам код, в котором меньше дупликации, который проще читать, писать и поддерживать.

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

Тут в игру вступает принцип DAMP (Descriptive and Meaningful Phrases – понятные и значимые фразы): в борьбе читабельности с устранением всей дупликации читабельность должна побеждать. Ниже – ссылки на статьи с примерами тест-кода, кажущиеся мне полезными:

• https://www.arhohuttunen.com/dry-damp-tests/
• https://enterprisecraftsmanship.com/posts/dry-damp-unit-tests/

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

Кстати, я только что узнал, что для этого тоже есть акроним – WET (Write Everything Twice – пишите все дважды). Кто-то креативно подошел к вопросу…

Итак, кем же быть, догматиком или прагматиком? Я думаю, что правильно – найти правильный баланс. Как мы увидели на примерах, можно перегнуть палку в обоих случаях, и в обоих случаях это приведет к проблемам. Еще одна расхожая фраза – «от добра добра не ищут».

Где же баланс? Зависит от ситуации ;) не страшно, если вы не сразу разберетесь. Рекомендую делать небольшие шажки, смотреть, что работает, учиться на своих ошибках и найти правильный баланс для вашей ситуации по ходу дела. Где-то я это уже видел…

P. S. Хочу сообщить об одном исключении, где я предельно догматичен – оно связано с повторными попытками запустить тест. Пожалуйста. Никогда. Этого. Не. Делайте. Вот почему.

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