Заморочки Playwright — waitForResponse

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

В фреймворку Playwright є зручна фіча «очікування» на Респонс від реквеста

waitForResponse — playwright.dev/...​ge#page-wait-for-response

Яка може допомогти в тих випадках, коли явних змін на WEB UI нема, а треба зробити перевірку що дійсно реквест пішов, сутність створилась успішно і замість того, щоб:

• відкривати сторінку з тою сутністю та писати перевірки що всі дані вірні
• або безпосередньо «дьоргати» певний ендпоінт та перевірити його поля

Можна реалізувати таке очікування, беремо з документації приклад:

1. Оголошуємо певне очікування, відповідно стартуємо очікування, робимо дію, потім чекаємо на респонс:

const responsePromise = page.waitForResponse('https://example.com/resource');
await page.getByText('trigger response').click();
const response = await responsePromise;

2. Оголошуємо предикат з очікуванням, робимо дію та «отримуємо» результат очікування

const responsePromise = page.waitForResponse(response =>
    response.url() === 'https://example.com' && response.status() === 200
    && response.request().method() === 'GET'
);
await page.getByText('trigger response').click();
const response = await responsePromise;

І нібито нам проміс, в цьому випадку, нам дає перевагу над іншим не асинхронними мовами

Юридично логіка яка описана вона є правильна та логічно коректна.
Спершу оголошуємо, що треба почекати коли буде респонс від бекенду, але ми не блокуємо виконання наступних дій
Далі ми робимо безпосередньо дію, але чекаємо коли вона виконається, браузер безпосередньо дає відповідь Playwright, що дія виконана, івент завершено, згрубше
І лише потім ми «отримуємо» результат очікування від асинхронного очікування яке ми оголосили браузеру.

Але тут є інший момент. Ваш бекенд не дає відповідь на фронтенд за 1 мілісекунду, дай бог дасть відповідь за 100 мілісекунд, звісно якщо ми не говоримо про gRPC, WebSocket.

Постає питання: А скільки часу проходить між завершенням промісу та «запуском» нового промісу
Відповідь: мікросекунди, це час JS івентлупа на опрацювання черги мікротасок

Тому можна ось так писати і буде компактніше, простіше:

await page.getByTestId('submit-button').click(); 
await page.waitForResponse('**/api/users');

Ви дуже малоймовірно отримаєте такий race condition коли клік, або філ буде стільки часу тримати проміс, що очікування на респонс буде марним.

Тому можете спробувати в вас на проєкті так само писати «синхронний» код, в мене працює і вас спрацює.

А для скептиків, я підготував приклад репозиторію з емуляцією такої поведінки на localhost коли в вас просто все локально ганяється і все успішно проходить.

github.com/...​l_service_for_experiments

Але звісно можуть бути всякі ситуації, які залежать від реалізації вашого фронтенда