Зачем добровольно себя ограничивать типом str в локаторах? Пропадает возможность использовать поиск и отличные фильтры, встроенные playwright. А так мы себя ограничиваем поиском self.page.get_by_test_id(locator) и всё. Ни цепочки локаторов, ни фильтров.
class BaseElement:
def __init__(self, page: Page, locator: str):
Чем не нравятся локаторы playwright?
class BaseElement:
def __init__(self, page: Page, locator: Locator):
2. Классы для всех базовых элементов это хорошо. А что со списками этих элементов?
В первом пункте ещё можно упомянуть про soft assert или сравнение какой-то группы элементов как единое целое (например dataclass). Удобно сразу видеть в отчете, что поле логин и пароль упали на ассертах, а email прошел. В случае обычных ассертов упадет на первой же проверке.
Если я правильно понял, то вы создаете для каждого теста своего пользователя в setup и удаляете в teardown. Если это так, то возникает 2 вопроса: как обеспечивается уникальность созданных пользователей (привязка к timestamp?), создаются ли эти пользователи через api?
Что вы делаете с авторизацией при параллельном запуске? Вы же не можете два теста запустить с логином под одним пользователем, иначе они будут мешать друг другу. Есть какой-то пул пользователей или как это реализовано?
Очень понравилась статья. Прикольная фишка с динамическими локаторами. Раньше только selenium пользовался и задавался вопросом в чем принципиальные отличия от playwright, а тут как раз эта статья.
Зачем добровольно себя ограничивать типом str в локаторах? Пропадает возможность использовать поиск и отличные фильтры, встроенные playwright. А так мы себя ограничиваем поиском self.page.get_by_test_id(locator) и всё. Ни цепочки локаторов, ни фильтров.
Чем не нравятся локаторы playwright?
2. Классы для всех базовых элементов это хорошо. А что со списками этих элементов?
Почему используется pytest_asyncio, вместо рекомендованного документацией playwright pytest-playwright-asyncio?
В первом пункте ещё можно упомянуть про soft assert или сравнение какой-то группы элементов как единое целое (например dataclass). Удобно сразу видеть в отчете, что поле логин и пароль упали на ассертах, а email прошел. В случае обычных ассертов упадет на первой же проверке.
Если я правильно понял, то вы создаете для каждого теста своего пользователя в setup и удаляете в teardown. Если это так, то возникает 2 вопроса: как обеспечивается уникальность созданных пользователей (привязка к timestamp?), создаются ли эти пользователи через api?
Что вы делаете с авторизацией при параллельном запуске? Вы же не можете два теста запустить с логином под одним пользователем, иначе они будут мешать друг другу. Есть какой-то пул пользователей или как это реализовано?
Очень понравилась статья. Прикольная фишка с динамическими локаторами. Раньше только selenium пользовался и задавался вопросом в чем принципиальные отличия от playwright, а тут как раз эта статья.
Несколько лет назад работал на C#, сейчас всё python да python. Как раз искал задачки чтобы знания освежить. Надо будет глянуть.