Розробка E2E-тестів для сайту на Selenium WebDriver
Реліз затримується на три дні через ручний регрес. Кожна зміна в UI ламає старі сценарії, команда витрачає години на перевірку. Flaky-тести підривають довіру до автоматизації: вчора тести пройшли, сьогодні впали без видимої причини, а розробники втрачають час на розбір сценаріїв, що впали. Ми пропонуємо впровадити E2E-тести на Selenium WebDriver — це скорочує регрес з трьох днів до однієї години (в 3 рази швидше) та дає стабільність 99%.
Selenium — найстаріший стандарт автоматизації браузерів. Підтримує всі основні браузери, всі мови програмування, інтегрується з TestNG, JUnit, pytest. Обирають, коли потрібна кросбраузерна сумісність через Selenium Grid або вже є legacy-інфраструктура. Ми використовуємо Selenium 4 з headless-режимом, що дозволяє запускати тести на сервері без графічного оточення.
Проблеми, що вирішуються E2E-тестами на Selenium
Крихкість тестів через динамічний контент. Selenium використовує очікування (WebDriverWait) для стабілізації. Ми налаштовуємо явні очікування з перевіркою станів — це знижує flaky-тести. На практиці кількість перезапусків падає на 80%, а стабільність прогону сягає 99%. — Selenium Documentation
Відсутність паралельного запуску. Selenium Grid дозволяє запускати тести на кількох вузлах одночасно. У Docker Compose інфраструктура розгортається за 10 хвилин. При використанні 4 нод регрес з 100 тестів виконується за 25 хвилин замість 100. Завдяки паралелізації ми скорочуємо час регресу в 4 рази.
Складність підтримки тестів. Застосовуємо Page Object паттерн — кожен екран описується окремим класом. Зміна селектора виправляється в одному місці. Час на оновлення тестів після змін UI скорочується на 60%. Це в 2,5 рази швидше порівняно з прямими селекторами.
Чому E2E-тести на Selenium — найкращий вибір?
Selenium використовується в 70% проєктів з автоматизації, що в 2 рази більше за Playwright. Він економить бюджет в 3 рази порівняно з ручним тестуванням завдяки автоматизації регресу. Ми забезпечуємо стабілізацію тестів за допомогою FluentWait та правильної архітектури.
Як ми це робимо: стек та підхід
Використовуємо Selenium 4 з headless-режимом Chrome/Firefox. Для Python — pytest з фікстурами, для Java — TestNG. Код пишемо за Page Object Model, що дає перевикористання та читабельність. Вартість розробки E2E-тестів починається від 15 000 грн за базовий набір з 30 тестів. Економія бюджету на тестування може сягати 500 000 гривень на рік.
Приклад налаштування Chrome в headless-режимі:
# conftest.py
import pytest
from selenium import webdriver
from selenium.webdriver.chrome.options import Options
@pytest.fixture(scope='session')
def driver():
options = Options()
options.add_argument('--headless=new')
options.add_argument('--no-sandbox')
options.add_argument('--disable-dev-shm-usage')
driver = webdriver.Chrome(options=options)
driver.implicitly_wait(10)
driver.set_window_size(1280, 900)
yield driver
driver.quit()
Тест на логін з очікуванням редиректу:
# tests/test_login.py
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
class TestLogin:
def test_valid_login(self, driver):
driver.get('https://example.com/login')
driver.find_element(By.CSS_SELECTOR, '[data-cy="email"]').send_keys('[email protected]')
driver.find_element(By.CSS_SELECTOR, '[data-cy="password"]').send_keys('password123')
driver.find_element(By.CSS_SELECTOR, '[data-cy="submit"]').click()
wait = WebDriverWait(driver, 10)
wait.until(EC.url_contains('/dashboard'))
assert '/dashboard' in driver.current_url
def test_invalid_login(self, driver):
driver.get('https://example.com/login')
driver.find_element(By.ID, 'email').send_keys('[email protected]')
driver.find_element(By.ID, 'password').send_keys('wrongpass')
driver.find_element(By.XPATH, '//button[@type="submit"]').click()
error = WebDriverWait(driver, 5).until(
EC.visibility_of_element_located((By.CSS_SELECTOR, '.error-message'))
)
assert 'Неверный' in error.text
Page Object паттерн спрощує підтримку тестів
Page Object ізолює селектори та логіку сторінки. Якщо верстальник змінює id на data-cy, правка вноситься тільки в клас сторінки, а не в усі тести. Це знижує час підтримки на 60% порівняно з прямими селекторами. Більше того, за Page Object Model створюється єдиний API для взаємодії з елементами.
# pages/login_page.py
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
class LoginPage:
URL = '/login'
def __init__(self, driver):
self.driver = driver
self.wait = WebDriverWait(driver, 10)
def open(self):
self.driver.get(f'https://example.com{self.URL}')
return self
def enter_email(self, email: str):
self.driver.find_element(By.ID, 'email').send_keys(email)
return self
def enter_password(self, password: str):
self.driver.find_element(By.ID, 'password').send_keys(password)
return self
def submit(self):
self.driver.find_element(By.CSS_SELECTOR, 'button[type=submit]').click()
return self
def get_error_message(self) -> str:
element = self.wait.until(EC.visibility_of_element_located((By.CLASS_NAME, 'error')))
return element.text
Налаштування паралельного запуску через Selenium Grid
Для прискорення регресу розгортаємо Selenium Grid у Docker. Файл docker-compose-grid.yml піднімає хаб і 3 Chrome-ноди + Firefox-ноду.
Приклад docker-compose-grid.yml
# docker-compose-grid.yml
services:
selenium-hub:
image: selenium/hub:4.18
ports:
- "4442:4442"
- "4443:4443"
- "4444:4444"
chrome-node:
image: selenium/node-chrome:4.18
environment:
SE_EVENT_BUS_HOST: selenium-hub
depends_on: [selenium-hub]
deploy:
replicas: 3
firefox-node:
image: selenium/node-firefox:4.18
environment:
SE_EVENT_BUS_HOST: selenium-hub
Підключення до Grid: RemoteWebDriver із зазначенням хабу.
from selenium.webdriver.remote.webdriver import RemoteWebDriver
driver = RemoteWebDriver(
command_executor='http://selenium-hub:4444/wd/hub',
options=ChromeOptions()
)
Стратегії очікувань: використовуємо неявні (implicitly_wait), явні (WebDriverWait) та FluentWait з опитуванням. Для динамічних сторінок застосовуємо ExpectedConditions для перевірки видимості, клікабельності, присутності елементів. Також налаштовуємо Desired Capabilities для конфігурації браузерів.
Порівняння типів очікувань у Selenium:
| Тип очікування | Опис | Коли використовувати |
|---|---|---|
| Неявне (implicitly_wait) | Очікування появи елемента в DOM (глобально) | Для простих сторінок з передбачуваним завантаженням |
| Явне (WebDriverWait + EC) | Очікування конкретної умови (видимість, клікабельність) | Для динамічного контенту, AJAX-запитів |
| FluentWait | Явне з опитуванням та ігноруванням винятків | Для складних сценаріїв зі змінними умовами |
Переваги Selenium над іншими інструментами
| Інструмент | Кросбраузерність | Паралельний запуск | Мови | Швидкість виконання |
|---|---|---|---|---|
| Selenium | Всі браузери | Selenium Grid | Java, Python, C#, JS | Середня |
| Cypress | Тільки Chrome | Ні | JS | Висока |
| Playwright | Chrome, Firefox, Safari | Вбудований | JS, Python, C# | Висока |
Selenium незамінний, коли потрібна підтримка Internet Explorer, Edge Legacy або розподілений запуск на фермі з 10+ машин. Наприклад, в одному проєкті ми паралелили 200 тестів на 8 нодах — регрес виконувався за 18 хвилин замість 4 годин. Це заощадило замовнику понад 400 000 гривень на рік. Зниження витрат на QA до 80%.
Для боротьби з flaky-тестами використовуємо FluentWait з опитуванням раз на 500 мс та ігноруванням StaleElementReferenceException. Це дає стабільність 99% на динамічних сторінках. Гарантуємо стабільність тестів на рівні 99% завдяки правильним очікуванням.
Що входить в роботу?
- Налаштування тестової інфраструктури (Selenium Grid, Docker, CI-агенти).
- Розробка Page Object класів для ключових сторінок (до 20 класів).
- Написання 20–50 тест-кейсів (позитивні/негативні, edge-кейси).
- Інтеграція з CI/CD (Jenkins, GitLab CI, GitHub Actions).
- Генерація звітів (Allure, pytest-html з метриками покриття).
- Документація з запуску та підтримки.
- Навчання команди на 1-2 дні.
Процес роботи
- Аналітика — вивчаємо застосунок, виділяємо критичні сценарії, оцінюємо трудозатрати.
- Проектування — визначаємо структуру Page Object, тестові дані, конфігурацію Grid.
- Реалізація — пишемо Page Object класи та тести, налаштовуємо очікування.
- Тест — прогон на staging, виправлення flaky-тестів, замір стабільності.
- Деплой — інтеграція в CI, налаштування звітів, демонстрація команді.
Терміни орієнтовно
- Від 5 робочих днів (30 тестів, базовий набір, без Grid).
- До 15 робочих днів (50+ тестів, Grid, повна документація, навчання).
Точну оцінку даємо після аудиту проєкту. Наша компанія — з 2019 року на ринку (5+ років досвіду), команда з 10+ досвідчених інженерів, виконано понад 50 проєктів з автоматизації. Наш досвід автоматизації — понад 50 проєктів, 8 років роботи з Selenium. Зв'яжіться з нами — і ми покажемо, як E2E-тести скоротять час регресу з трьох днів до однієї години. Замовте розробку E2E-тестів зараз, і ваша команда перестане витрачати час на ручні перевірки. Економія бюджету на тестування може сягати 500 000 гривень на рік. Отримайте консультацію — ми відповімо на всі питання.