Привет, пока не совсем понятно, КАК эти ваши тесты отличаются от самых обычных тестов на Selenium. Т.к. прелесть UI тестов как раз в том, что они могут и должны проверять пользовательские сценарии. Больше пользовательских сценариев покрыто = больше толку от тестов.
Давайте представим такой сценарий:
Проверка написания отзыва в системе отзывов. Чтобы написать отзыв, нужно быть зерегистрированным.
Идеи по оформлению сценария:
- метим тест фикстурой, что она выполняется из под пользователя, а не гостя. В этом случае фикстура может как получать уже готовые данные логина (из ресурса с тестовыми данными), так и получать их в случайном порядке из БД (бд хелпер функция возвращающая удовлетворяющие условию данные). Фикстура эта будет производить логин непосредственно перед тестированием самого кейса. Либо в самом кейсе,
- Захожу на форму написания отзыва(точка входа? прямой линк или клиентский рендеринг приложения, т.е. клик в какую-нибудь кнопку? - оба сценария имеют право на жизнь), делаю все проверки поведения, присущие этой форме: проверяю негативные сценарии (наличие JS-popup’ов-заглушек), проверив все возможные кейсы - выполняю успешный сценарий публикации отзыва. Если отзыв при публикации не перенаправляет на общую ленту отзывов, можно перейти на страницу, где он будет виден в общем списке и найти его по тексту сообщения. Всё.
при этом, помимо фикстуры логина, у вас будет конкретный отдельный тест, который, например, будет проверять форму логина на сайт, со всеми возможными проверками на поведение.
В большинстве случаев, на разные страницы пишутся разные тесты, и если в рамках тестирования страницы отзыва вам нужно делать манипуляции со страницей логина, то этот шаг нужно считать подготовительным и не обременять его проверками на негативное тестирование - этот шаг будет контекстом. Контекст теста никогда не тестируется и принимается, что он должен просто быть корректным.
При этом всём, никогда не зазорно при получении инстанса новой страницы брать и проверять существование элементов - это не обходится дополнительными расходами на время выполнения текущего сценария и позволяет понять по css состояние элементов, тексты и их номинальное соответствие спецификации.
В современных веб приложениях все компоненты имеют слабосвязанную архитектуру, и прежде чем делать кейсы в автоматизации UI, которые должны как-то стрессово протестировать сайт, нужно как минимум иметь какие-то основания на этот счет. Но в большинстве своём, повторюсь, изолированные тесты каждого компонента, который вписывается в пользовательский сценарий - с наличием акцентов для текущего сценария - это на мой взгляд лучшее решение. Таким образом при прогоне всех тестов на все пользовательские сценарии будет протестировано поведение всех страниц при миинмальном повторении кода и затратах времени на выполнение.
Пример самого простого пользовательского сценария представлен ниже.
def test_chat_as_bac(self):
"""
Проверяем клиентский рендеринг и написание из под роли Компании
"""
login_as(self.driver, users['pac'])
start_page = FirstPage(self.driver)
messages_page = start_page.enter_messages() # переходим из хедера в личные сообщения
message_text = get_random_99() # генерируем случайный текст
messages_page.chat_with(users['basic']).as_company().send_message(message_text) # находим собеседника, выбираем роль от лица компании, вводим текст в поле ввода, отправляем сообщение
assert messages_page.last_message_text(message_text) # проверяем, что текст сообщения отобразился в диалоге последним
assert messages_page.message_author_is_bac # проверяем, что иконка отправителя соответствует выбранной роли, от лица кого пишем
В момент перехода на начальную страницу мы можем проверить все ее элементы - на наличие, и их текущее состояние. Но прокликать все кнопки сейчас на ней - это лишнее. Поэтому мы просто переходим в личные сообщение методом PageObject’a .enter_messages()
Такие проверки для каждого PageObject можно помещать в конструктор. Например, так:
class MessagesPage(BasePage, MessagesPageLocators):
"""
Страница личных сообщений
Содержит:
- список диалогов
- поиск по пользователям для создания нового диалога
- поле с чатом текущего собеседника
"""
def __init__(self, driver, url=None):
super().__init__(driver, url)
if not url and 'messages' not in self.url:
self.driver.get(self.DEFAULT_HOST + '/messages')
self.validate_header_elements_are_present()
self.validate_messenger_elements_are_present()
Здесь проверка компонентов страницы описана в методах validate_header_elements_are_present() и validate_messenger_elements_are_present(). Т.е. фактически перед тем, как что-то вызывать на текущем pageobject - мы можем легко взять и проверить его состояние. помимо самих проверок, такие методы в конструкторе могут гарантировать, что вызов других методов на странице не будет вызывать проблем, т.к. страница точно загрузилась ( в валидаторах-методах описан перечень элементов, где каждый находится через WebDriverWait)
testomat.io управление авто тестами