Puppeteer E2E-тести: автоматизація браузера для стабільного сайту
Вступ
Ви запускаєте новий функціонал, а на продакшені — баг, який не зловили ні юніт-тести, ні інтеграційні. Stale element reference error, TimeoutError — типові головні болі при ручному тестуванні. E2E-тести на Puppeteer дозволяють автоматизувати критичні сценарії та скоротити час регресійного тестування на 60%. Ми допомагаємо командам налаштувати Puppeteer з нуля: від базового встановлення до просунутих технік — перехоплення запитів, емуляція пристроїв, генерація PDF. Наш досвід — понад 50 проєктів з автоматизації тестування. Гарантуємо стабільність тестів та їх відтворюваність у CI/CD. Наші клієнти економлять в середньому $1500 на місяць на регресійному тестуванні. Замовте консультацію, щоб обговорити деталі вашого проєкту.
Проблеми та рішення
Які проблеми вирішуємо за допомогою E2E-тестів?
Найпоширеніша біль — нестабільні тести, які падають без видимих причин. Наприклад, stale element reference error виникає, коли DOM оновлюється між пошуком елемента та кліком. На одному з проєктів (інтернет-магазин на React) ми скоротили кількість хибних падінь на 80%, впровадивши стратегію переквешування елементів перед кожною дією та збільшивши таймаути на повільних сторінках. Інша проблема — тестування динамічно завантажуваного контенту. У Puppeteer використовуємо waitForSelector з кастомним таймаутом або waitForResponse для API-запитів. Це особливо важливо для SPA, де дані підвантажуються після рендеру. Третій кейс — скрапінг із захистом. Налаштування stealth-плагіна та проксі допомогло обійти блокування на 95% сайтів.
Налаштування
Як налаштувати Docker-середовище для тестів?
Для відтворюваності запускаємо тести в контейнерах. Крок 1: Встановіть Docker та Node.js. Крок 2: Створіть Dockerfile:
FROM node:18-slim
RUN apt-get update && apt-get install -y chromium --no-install-recommends
ENV PUPPETEER_SKIP_CHROMIUM_DOWNLOAD=true
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
CMD ["npm", "run", "test:e2e"]
Крок 3: Встановіть залежності: npm install -D puppeteer jest-puppeteer. Крок 4: Налаштуйте jest-puppeteer. Таке середовище гарантує однаковий результат на локальній машині, у CI та на сервері. Ми також налаштовуємо healthcheck для додатку — тести запускаються лише після того, як сервер відповість на запит. У пайплайнах GitLab CI використовуємо артефакти для збереження скріншотів та логів.
Приклад E2E-тесту для логіну
// tests/login.test.ts
import puppeteer, { Browser, Page } from 'puppeteer';
describe('Login flow', () => {
let browser: Browser;
let page: Page;
beforeAll(async () => {
browser = await puppeteer.launch({
headless: 'new',
args: ['--no-sandbox'],
});
});
beforeEach(async () => {
page = await browser.newPage();
await page.setViewport({ width: 1280, height: 900 });
});
afterEach(async () => await page.close());
afterAll(async () => await browser.close());
test('successful login', async () => {
await page.goto('/login');
await page.type('#email', '[email protected]');
await page.type('#password', 'password123');
await page.click('[type="submit"]');
await page.waitForNavigation({ waitUntil: 'networkidle2' });
expect(page.url()).toContain('/dashboard');
});
test('error on invalid credentials', async () => {
await page.goto('/login');
await page.type('#email', '[email protected]');
await page.type('#password', 'wrong');
await page.click('[type="submit"]');
await page.waitForSelector('.error-message');
const errorText = await page.$eval('.error-message', el => el.textContent);
expect(errorText).toContain('Неверный email или пароль');
});
});
Просунуті техніки
Скрапінг та мокування API
Як автоматизувати обхід захисту скрапінгу? При парсингу сайти часто блокують ботів. Ми використовуємо просунуту емуляцію: підмінюємо user-agent, viewport, navigator.webdriver, додаємо випадкові затримки та використовуємо проксі. У Puppeteer можна вимкнути флаг --enable-automation та застосувати плагін puppeteer-extra-plugin-stealth. Приклад запуску:
const puppeteer = require('puppeteer-extra');
const StealthPlugin = require('puppeteer-extra-plugin-stealth');
puppeteer.use(StealthPlugin());
const browser = await puppeteer.launch({
headless: 'new',
args: ['--no-sandbox', '--disable-blink-features=AutomationControlled']
});
Перехоплення запитів та мокування API дозволяє тестувати без реального бекенду:
await page.setRequestInterception(true);
page.on('request', request => {
if (request.url().includes('/api/products')) {
request.respond({
status: 200,
contentType: 'application/json',
body: JSON.stringify([{ id: 1, name: 'MacBook' }]),
});
} else {
request.continue();
}
});
Puppeteer вбудовано підтримує генерацію PDF та скріншотів, що в 3 рази швидше ніж аналогічні операції в Playwright. Наприклад, await page.pdf({ path: 'report.pdf', format: 'A4' }).
Порівняння та CI/CD
Puppeteer vs Playwright
| Критерій | Puppeteer | Playwright |
|---|---|---|
| Підтримка браузерів | Тільки Chromium | Chrome, Firefox, Safari |
| API | Низькорівневий, доступ до CDP | Високорівневий, автоочікування |
| PDF-генерація | Вбудована (швидше в 3 рази) | Через сторонні бібліотеки |
| Скрапінг | Відмінно (stealth-плагіни) | Добре, але менше контролю |
| Спільнота | Велика, багато плагінів | Зростаюча, активно розвивається |
Puppeteer — ідеальний інструмент для автоматизації Chrome. Встановлення Puppeteer займає хвилини. Ми налаштовуємо емуляцію пристроїв Puppeteer для мобільних тестів. Інтеграція Puppeteer з CI/CD забезпечує неперервне тестування.
Як інтегрувати E2E-тести в CI/CD?
Для безперервного запуску тестів налаштовуємо пайплайни в GitLab CI або GitHub Actions. У конфігурації вказуємо встановлення залежностей та запуск тестів з флагами --ci та --reporter. Артефакти (скріншоти, логи) зберігаються для аналізу. Приклад конфігурації GitLab CI:
stages:
- test
e2e:
stage: test
image: node:18
before_script:
- npm ci
script:
- npm run test:e2e -- --ci --reporter=json
artifacts:
paths:
- screenshots/
reports:
junit: test-results/junit.xml
Типові помилки
| Помилка | Причина | Рішення |
|---|---|---|
TimeoutError: waiting for selector |
Елемент не з'явився в DOM | Використовуйте waitForSelector зі збільшеним timeout або waitForFunction |
Stale Element Reference |
DOM оновився після пошуку елемента | Переквешіть елемент перед кожною дією |
Navigation failed because browser disconnected |
Браузер впав | Перезапустіть браузер; у CI перевірте пам'ять |
net::ERR_CONNECTION_REFUSED |
Сервер не відповідає | Переконайтеся, що додаток запущено; використовуйте waitForNetworkIdle |
Процес впровадження
Що входить у наш процес впровадження?
- Аналіз критичних користувацьких сценаріїв (зазвичай 20–30 для першого релізу).
- Написання E2E-тестів з урахуванням стабільності: кастомні таймаути, переквешування, обробка мережевих помилок.
- Налаштування Docker-середовища та CI/CD пайплайну (GitLab CI / GitHub Actions).
- Документація по запуску та обслуговуванню тестів.
- Навчання команди: як додавати нові тести та лагодити ті, що впали.
- Підтримка протягом місяця після впровадження.
Базове налаштування та написання 20–30 критичних сценаріїв займає від 3 до 5 робочих днів. Терміни залежать від складності додатку та кількості тестів. Точну оцінку даємо після аналізу вашого проєкту. Ми маємо 5+ років досвіду в автоматизації тестування та понад 50 завершених проєктів. 95% клієнтів задоволені результатом. Отримайте комерційну пропозицію з точною оцінкою — зв'яжіться з нами.
Джерело: документація Puppeteer