Меньше фич-лучше

Саш, а если нужно подготовить данные через апишку, а только потом UI-тест делать - дублируешь логику?

Что мешает взять got и сделать запрос там где надо? Зачем это заносит в playwright?

Спасибо! Мы безусловно не хотим отвлекаться от браузеров. Именно поэтому и задаю вопрос. Там цепочка какая:

1) хотят срезать на login и на подготовке к тесту,  делаем context.request для этого. он интегрирован с куками контекста, это наша тема
2) получается апи request-а, которое попадает в trace viewer, можно state на нем собрать и с ним контексты браузерные быстро собрать, тоже наше
3) но апи получается generic и сразу мы получаем считайте axios. можно в globalSetup сделать без всяких браузеров себе сессию и потом с нее начинать браузерное тестирование

и вот так, 1-2-3 и мы получается в этой теме. и хочется понять, нам убрать (3) и в нее не лезть или все прям захотят чтобы мы смотрели на эту область как на важную и растущую...

Да, у нас сейчас есть траблы с этим. Мы решили юзать встроенные возможности для перехвата и подмены реквестов в браузере, а прекондишины делать через api client который мы пока сами для себя написали, и будем выкладывать как пекедж для реюза в апи тестах, е2е, call performance и backend load

Апи клиент приблизительно такой же как в видосах что у меня на ютубе, только с возможностью замены http реквестилки чтобы в k6.io юзать тоже

чтобы был один контекст этих запросов. чтобы куки e.g. этого запроса автоматом подхватились из браузера.

да, мы изначально решаем именно эту задачу, это точно будет, в 1.15 будет context._request (experimetnal на один релиз, в 1.16 stable)

но как-то логически вытекает (2) и (3) и хочется понять где останавливаться!

Только не останавливайтесь, не для себя прошу.

У нас большие надежды на этот инструмент

Playwright не остановится, вопрос как глубоко копать API testing :-)

Ну тогда, я за (3).

я скажу так. если вы сами не сделаете (3) юзеры в итоге сделают за вас. каждый сам у себя. практика показывает что даж сайпрес берут и используют под онли-апи тесты.

А вот автоматически разруливать когда API тест, а когда UI и не стартовать лишний раз браузер было бы нормальной фичей 🙂 У меня был общий sh-скрипт для всех тестов, поэтому я кастомил эту логику.

Ну если мы про раннер думаем в этой связке

В этом случае все эти jest+axious станут не нужны)

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

а по итоге это может и будет нормально синтегрировано с репортингами ( которые все любят ) из короба