Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Может ли один автотест иметь несколько проверок

java
testing
selenium
python
webdriver
Теги: #<Tag:0x00007fedc4659438> #<Tag:0x00007fedc46592f8> #<Tag:0x00007fedc4659168> #<Tag:0x00007fedc4658fd8> #<Tag:0x00007fedc4658e48>

(Elvis Presley ) #1

Всем привет, может ли один автотест иметь несколько проверок. Например что то типа:
Шаги:
1)Открываем страницу ввода логина;
2)Вводим юзера и пассворд;
3)Нажимаем ок;
Проверки, например такие:
4)Проверяем, что находимся в личном кабинете;
5)Проверяем, что присутствует сообщение приветствия;
6)Проверяем, что в сообщении приветствия, приветствуют именно того юзера, который залогинился.
Имеет ли это смысл? Или для каждой проверки должен быть отдельный тест? Но тогда шаги будут одни и теже, кроме проверок. А тестов будет огромное количество. Но с другой стороны, если, например первая проверка упадет, то весь тест упадет и оставшиеся проверки будут не пройдены.
Что думаете? Правильно ли это с точки зрения тестирования?


(Игорь Владимиров) #2

Если говорить о UI-тестах то на мой взгляд лучше так как ты описал, у меня в одном тесте бывает и по 10 проверок, и это нормально, иначе действительно тестов будет очень много и будут делать они в основном одно и тоже, спрашивается зачем?


(Михаил Братухин) #3

Делайте soft-assert’ы и проверки не будут падать после первого фейла.
В отличии юнит-тестов в ui и даже в api тестировании слишком накладно делать одну проверку на один тест, так что лучше один тест, который проверяет много чем много тестов, которые ничего не проверяют.


#4

По правилам написания ТС - 1 кейс на 1 проверку!
Хотя если вы пишите на кукумбере то там может быть и несколько проверок.


(Bolatbek) #5

Для pytest есть библиотечка для софт ассертов, как писали выше. Хорошее и правильное решение. Это если вам нужно, чтобы тест не падал на первом же фейле, и проверял все остальные ассерты.

Ответ - да, несколько проверок вполне нормальное решение.


(Vladimir Kovalenko) #6

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


(Михаил Братухин) #7

Если тесты не нужно подвязывать к alm системам, что делается зачастую вручную и для теста не требуется создавать сложные фикстуры, тогда можно и так делать. Но по мне так это всё какие-то непонятные излишества и очковтирательство типа “смотрите как у нас много тестов на проекте”. На уровне ui и api один тест это полноценная бизнес операция со всеми проверками, а не метод и проверка поля в xml. Даже в тех же allure отчетах используются шаги в которых можно выполнять проверки. Это и логично и удобно. Вместо того, чтобы делать тест: 1) создаем договор, проверяем ответный статус. 2) создаем договор, проверяем запись в лог… и т.д. Бизнес-операция одна - тест один. Проверок внутри столько, сколько считаете достаточным и необходимым для себя.