Home

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Ранее я писал о концепции мягких ассертов. Процитирую себя: "Мягкий ассерт – это ассерт, результат которого записывается, но не останавливает выполнение тестового сценария на этой точке. Результаты всех мягких ассертов оцениваются в указанный автором тест-сценария момент, как правило, в конце; если какое-либо условие мягкого ассерта валидируется как ложь, мягкий ассерт сообщает о провале в результате, и тест-сценарий, как правило, отмечается как проваленный". Если вы пропустили предыдущую статью, прочитайте про концепцию мягких ассертов.

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

Итак, как же использовать мягкие ассерты?

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

Здорово, правда? Почему бы не использовать мягкие ассерты везде и всюду и просто вызывать "падение теста, если упал мягкий ассерт" в конце каждого сценария? Ну, как всегда, на это есть причины.

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

Как нам решить, когда не стоит продолжать? В общем случае, если продолжать после падения ассерта нет смысла, нужно заставлять тест-сценарий падать на этом ассерте. К примере, в тесте GUI с кликом по кнопке, которая должна перенести нас на определенную страницу, мы можем проверять, что эта страница – то, что нам нужно. Если эта проверка провалена, то мы, скорее всего, не на нужной странице, или же сайт вернул, скажем, 404 ошибку. В любом случае продолжать движение по шагам теста с шансами бессмысленно, потому что то, что мы пытались делать на нужной нам странице, не сработает на той, которую мы получили. Что еще хуже, некоторые действия, предназначенные для правильной страницы, могут сработать и на этой, неправильной, позволяя скрипту продолжать; скрипт, скорее всего, упадет позднее, когда диагностировать проблему будет трудно.

Резюмируя,

• Если у вас одно условие ассерта, то жесткий ассерт, как правило, верный выбор.
• Если вы проверяете множество связанных значений, вам подойдет мягкий ассерт.
• Если после падения условия Х вы все еще хотите проверить условие А, вам подойдет мягкий ассерт.
• Если после падения условия Х нет смысла проверять условие Y или выполнять дальнейшие шаги теста, верным выбором будет применение жесткого ассерта или вызов функции мягкого ассерта "уронить сценарий, если упал мягкий ассерт" немедленно после условия Х.

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

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