Комментарии 5
А теперь о том, как делать это "в две строчки":
1) В playwright.config.ts в секцию use добавляем строчку:
storageState: 'storageState.json'
2) В первом тесте, в projects выполняемом до всех остальных тестов, в конце (после успешного логина) добавляем:
await page.context().storageState({ path: 'storageState.json' })
Все тесты после этого будут уже начинать с авторизованного состояния. Если нужно неавторизованное - тогда нужны телодвижения)
а можно сделать setup который будет выполняться до тестов - сохранять контекст браузера projects: [ { name: 'setup', testMatch: /.*\.setup\.ts/ }, { name: 'chromium', use: { storageState: '.auth/*.json', }, dependencies: ['setup'], } который в тестах вызывается через test.use({ storageState: '.auth/admin.json' }); ну или не вызывается
Добрый день! Спасибо за интересную статью. Есть плюсы и минусы такого подхода, плюсы вы уже обозначили.
Главный минус (он же плюс) подхода - сохранение контекста и единственный логин. Соответственно, это становится узким горшлышком запуска.
1. Авторизационный токен может протухнуть посреди сессии.
2. Во время авторизации может на пару секунд моргнуть инфраструктура - и упадут все тесты разом.
3. В localStorage могут накапливаться тестовые данные прошлых автотестов, что делает сценарии довольно грязными, и может даже привести к конфликтам между тестами. Это довольно тяжело отловить особенно при параллельном запуске тестов.
Замечания резонные но в целом решаемые при желании, даже с такой реализацией но со всякими дополнениями/изменениями. Все индивидуально для каждого проекта) 1) можно попросить настроить отдельно/делать повторную авторизацию посреди тестов(костыль). 2) тут не понял, так и все тесты могут упасть без этого. 3) Тут да, зависит от сценариев, но в целом наверно можно подчищать.
А мы попросили разработчиков сделать нам на тестовом окружении урл быстрой авторизации, открываешь его с нужным логином - и вуаля, авторизован.
Постоянный логин в автотестах? Решаем с Playwright и экономим время