В этой статье я делаю упор на теорию без примера. Возможно в будущем если будет время и я перепишу какой то свой фреймворк (выпилив от туда конф. инфу) как пример для этой статьи потому что тут надо шарить весь рабочий репозиторий а не куски кода, чтобы были видны взаимосвязи (мое имхо конечно же).
ПС: у меня тоже есть проект в котором генерация тестовых данных (пользователей и других сущностей) вынесена в отдельный микросервис с апи ручкой. Как раз таки сделано это для того чтобы разные автоматизированные проекты могли их дергать. Так что тут я соглашусь что если есть необходимость и возможность надо выносить.
Этого всего конечно же не надо. Это пример абстрактной архитектуры в вакууме. На практике в разных проектах все может быть вообще по другому. Нужно брать только то что действительно нужно не забывая про принцип простоты. Нужно брать только то что действительно нужно твоему проекту.
Привет. Шаг от шага все таки наследовать плохая практика (мое ИМХО). Мой подход в этом плане такой: я выношу какие то действия в шаге в отдельные функции и вот их уже вызывать в разных шагах. На мой взгляд также можно в UI тестах использовать готовые API шаги без наследования. Условно говоря есть UI шаг "я добавил заказ". Потом идет шаг проверить API ответ для этого я просто использую API шаг: "я проверил что наш заказ есть в полученном API запросе заказов".
Вообще в практике если позволяет приложения я придерживаюсь концепции для UI тестов: "один тест одна страница" . то есть если мой UI тест проверяет создание заказа то он визуально проверяет только этот экран - остальное проверяется через API. Тоже самое если я проверяю страницу списка заказов я пред настройку делаю через API и проверяю только что визуально я вижу те заказы что до этого создал мой тест через API )
Если вопрос про движок — однозначно берите Puppeteer.
Если вопрос про визуальные фреймворки тут надо хорошо анализировать. У меня пока нет полной картины что лучше. Сейчас очень активно развиваются сторонние библиотеки в этой области. Вот тут есть список популярных инструментов, возможно он будет полезен. Также на одном проекте мы применяли jest-image-snapshot. Из того что использовали могу выделить Gemini. Это тоже неплохая технология разработанная Яндексом. Но однозначного ответа я вам про визуальные тесты не скажу)
Странно что за 9 лет я должна знать то, что хотите вы не так ли?)
Описаны тест-раннеры только для JS, потому что статья и так избыточно большая. Будет желание или потребность опишу про другие.
Если посмотреть внимательно в таблице со скоростью, можно увидеть, что там есть ссылка на абсолютно полные данные. Вот ссылка оттуда blog.checklyhq.com/cypress-vs-selenium-vs-playwright-vs-puppeteer-speed-comparison. Это статься на английском. Данные по скорости взяты из нее. Еще есть статься на хабре с переводом (их ранней статьи) habr.com/ru/company/simbirsoft/blog/539646. Если вас интересует производительность читайте их.
В этой статье я делаю упор на теорию без примера. Возможно в будущем если будет время и я перепишу какой то свой фреймворк (выпилив от туда конф. инфу) как пример для этой статьи потому что тут надо шарить весь рабочий репозиторий а не куски кода, чтобы были видны взаимосвязи (мое имхо конечно же).
ПС: у меня тоже есть проект в котором генерация тестовых данных (пользователей и других сущностей) вынесена в отдельный микросервис с апи ручкой. Как раз таки сделано это для того чтобы разные автоматизированные проекты могли их дергать. Так что тут я соглашусь что если есть необходимость и возможность надо выносить.
Этого всего конечно же не надо. Это пример абстрактной архитектуры в вакууме. На практике в разных проектах все может быть вообще по другому. Нужно брать только то что действительно нужно не забывая про принцип простоты. Нужно брать только то что действительно нужно твоему проекту.
Привет. Шаг от шага все таки наследовать плохая практика (мое ИМХО). Мой подход в этом плане такой: я выношу какие то действия в шаге в отдельные функции и вот их уже вызывать в разных шагах. На мой взгляд также можно в UI тестах использовать готовые API шаги без наследования. Условно говоря есть UI шаг "я добавил заказ". Потом идет шаг проверить API ответ для этого я просто использую API шаг: "я проверил что наш заказ есть в полученном API запросе заказов".
Вообще в практике если позволяет приложения я придерживаюсь концепции для UI тестов: "один тест одна страница" . то есть если мой UI тест проверяет создание заказа то он визуально проверяет только этот экран - остальное проверяется через API. Тоже самое если я проверяю страницу списка заказов я пред настройку делаю через API и проверяю только что визуально я вижу те заказы что до этого создал мой тест через API )
да это про JS и для безголового режима )
Если вопрос про визуальные фреймворки тут надо хорошо анализировать. У меня пока нет полной картины что лучше. Сейчас очень активно развиваются сторонние библиотеки в этой области. Вот тут есть список популярных инструментов, возможно он будет полезен. Также на одном проекте мы применяли jest-image-snapshot. Из того что использовали могу выделить Gemini. Это тоже неплохая технология разработанная Яндексом. Но однозначного ответа я вам про визуальные тесты не скажу)
Описаны тест-раннеры только для JS, потому что статья и так избыточно большая. Будет желание или потребность опишу про другие.
Если посмотреть внимательно в таблице со скоростью, можно увидеть, что там есть ссылка на абсолютно полные данные. Вот ссылка оттуда blog.checklyhq.com/cypress-vs-selenium-vs-playwright-vs-puppeteer-speed-comparison. Это статься на английском. Данные по скорости взяты из нее. Еще есть статься на хабре с переводом (их ранней статьи) habr.com/ru/company/simbirsoft/blog/539646. Если вас интересует производительность читайте их.