Правильное именование тестов и переменных в автоматизированном тестировании играет ключевую роль для читаемости, сопровождения и масштабируемости кода. В Playwright, как и в других фреймворках для E2E-тестирования, структурирование названий напрямую влияет на эффективность работы команды и скорость выявления ошибок.
Тесты в Playwright обычно описываются с помощью функции
test(). Имя теста должно быть дословным описанием
поведения, которое проверяется.
test('пользователь может успешно авторизоваться с валидными данными', async ({ page }) => {
// тестовые шаги
});
Рекомендации по именованию тестов:
Примеры хороших названий:
'отображает сообщение об ошибке при неверном пароле''создает новую задачу в списке дел''удаляет пользователя из базы данных'Примеры плохих названий:
'тест1''проверка логина''функционал кнопки'Четкое имя теста позволяет понять его назначение без необходимости открывать тело функции.
Переменные в тестах Playwright делятся на несколько типов: страницы
(page), элементы (locator), данные тестов
(testData) и вспомогательные функции. Все они должны иметь
описательные имена, соответствующие их назначению.
const loginButton = page.locator('#login-button');
const usernameInput = page.locator('#username');
const invalidPassword = 'wrongPassword123';
Основные правила:
Использовать camelCase для переменных и функций
(userEmail, submitForm) и PascalCase для
классов (LoginPage).
Избегать аббревиатур, если они не общеприняты в проекте.
Отражать тип данных или роль переменной, если это важно для понимания кода. Например:
userList — массив пользователейerrorMessage — сообщение об ошибкеsubmitButton — кнопка отправки формыЛокаторы — один из ключевых элементов Playwright. Их имена должны описывать, что представляет элемент, а не как он находится.
const submitButton = page.locator('button[type="submit"]');
const searchInput = page.locator('#search');
const userCardTitle = page.locator('.user-card .title');
Нежелательно использовать имена вроде button1,
inputField, div2, так как они не дают
понимания назначения элемента.
Playwright поддерживает describe() для группировки
связанных тестов. Имена блоков describe должны описывать
функциональный модуль или сценарий, что облегчает
навигацию по тестам.
describe('Авторизация пользователя', () => {
test('пользователь может войти с валидными данными', async ({ page }) => {});
test('отображается сообщение об ошибке при неверном пароле', async ({ page }) => {});
});
Советы по именованию блоков:
'Пользователи',
'Формы обратной связи'.'Тесты' или
'Функционал'.Файлы тестов Playwright обычно хранятся в папке tests
или e2e. Правильное именование файлов повышает удобство
поиска и понимание назначения тестов.
login.spec.js,
user-registration.spec.js..spec.js или .test.js для
обозначения тестового файла.Избегание дублирования слов в названиях тестов и переменных помогает
поддерживать код чистым и понятным. Например, если в блоке
describe('Авторизация пользователя') все тесты связаны с
авторизацией, нет необходимости повторять слово
'авторизация' в каждом имени теста:
describe('Авторизация пользователя', () => {
test('входит с валидными данными', async ({ page }) => {});
test('выдает ошибку при неверном пароле', async ({ page }) => {});
});
describe('Создание задач', () => {
const newTaskTitle = 'Купить продукты';
const newTaskDescription = 'Молоко, хлеб, яйца';
test('добавляет новую задачу в список', async ({ page }) => {
await page.locator('#task-title').fill(newTaskTitle);
await page.locator('#task-desc').fill(newTaskDescription);
await page.locator('#add-task-button').click();
await expect(page.locator('.task-item')).toContainText(newTaskTitle);
});
test('не позволяет создать задачу без заголовка', async ({ page }) => {
await page.locator('#task-title').fill('');
await page.locator('#add-task-button').click();
await expect(page.locator('.error-message')).toHaveText('Заголовок обязателен');
});
});
В этом примере:
newTaskTitle,
newTaskDescription).describe устраняет повторение
контекста.Правильное именование тестов и переменных в Playwright обеспечивает чистоту, читаемость и поддержку тестового кода, минимизирует ошибки при масштабировании проектов и упрощает работу командной разработки.