Лучше приходите к работе через qa api

То есть добавьте метод, который будет генерить эту ссылку и идите по ней

Это - самый основной и самый верный метод.

Вариант похуже - mailhog, к которому можно достучаться по api через cy.request

вот по нему я и думала делать

реквесту же вроде как пофиг

спасибо

значит, как говорили наши индусы,
ДА.

о, тоже начинаем пилить qa api, только отдельным сервисом
Может есть какие-нить инсайты/подводные камни/вкусные-невкусные плюшки/ user experience ?)

все ок делайте, со временем просто допиливайте нужный функционал

ну и самое главное на проде отключите

Отдельным сервисом - хорошо, можно просто не деплоить

Хотя я очень люблю когда можно попасть на любую страницу по прямой ссылке, а стороний сервис такого не даёт

Чтобы подготовил всё на бекенде, точечной попал на нужную страницу, проверил тот маленький кусок функционала и тест завершён

Можно чтобы логинил тебя за пользователя *@test.test
Например по ссылке
http://testserver.local/service/cart/?testkey=TrustNo1&user=vasya
сразу перекидывал тебя на корзину пользователя vasya@test.test
В таком случае даже если забыть это отключить на проде, то хакер знающий секретный тестовый пароль максимум сможет - зайти за  тестового юзера (которых на проде и нету вовсе)

И вообще, test-api - это хорошо, но подготовленая база мне понравилась больше. Просто скрипт, который на тестовой базе создаёт всех нужных пользователей во всех нужных состояниях со всеми нужными ключами. И ты в тестах просто идёшь по заранее известному адресу и проверяешь что там всё как всегда. Базу можно держать даже in memory, чтобы быстрее работала (всё равно кроме твоих данных там ничего нет, а твоих данных еле на мегабайт наберётся.

иногда приходится правда совмещать и апи и базу

Тесты они как раз про то что работает - не трогай, тронул - проверь что работает.

То есть я их рассматриваю как контракт (не путать с контрактным тестированием): если тест упал, значит контракт нарушен. И либо надо менять контракт, либо исправлять нарушение