UI: локаторы, ожидания и наблюдаемый результат · QA Orbit
Перейти к содержимому
QA ORBIT
Новости Инструменты Библиотека Полезные сайты Курсы ИИ и тестирование
Войти
КурсыТренажёры3
Маршруты обучения
КурсыАвтоматизация тестирования: код, изоляция и CIУрок 3
Программа курса

Автоматизация тестирования: код, изоляция и CI

0 из 6 уроков пройдено
01Автотест как программа: данные, действие, оракул≈ 50 мин02Уровни проверки и контракт состояния≈ 50 мин03UI: локаторы, ожидания и наблюдаемый результат≈ 50 мин04Изоляция, fixtures и асинхронность≈ 50 мин05Диагностика падений и запуск в CI≈ 50 мин06Итоговый проект: надёжный набор публикации≈ 70 мин
Учебные данные. Реальные навыки.
Урок 03 / 6 · 03 · Браузерный слой≈ 50 мин с практикой

UI: локаторы, ожидания и наблюдаемый результат

Разбираем самостоятельный DOM-тест Playwright и заменяем хрупкие селекторы и задержки проверками поведения.

В своём темпе
Что вы сможете после урока
  • Находить элементы по роли и доступному имени.
  • Отличать ожидание действия от ожидания бизнес-результата.
  • Читать TypeScript-тест и назвать границу DOM-упражнения.

Что добавляет браузер

На уровне UI важны доступность элемента пользователю, его состояние и отображаемый результат. Успех функции публикации в памяти не подтверждает, что кнопку можно найти, поле связано с подписью, а статус после действия действительно виден. Браузерный тест должен взаимодействовать с наблюдаемым интерфейсом и проверять обещанный эффект. Сам факт click без последующего ожидания слаб: обработчик мог не изменить нужное состояние.

Скачиваемый dom-exercise.spec.ts создаёт целую учебную страницу через page.setContent. На ней есть main с именем Task editor, поле Task title, кнопка Publish task и status Publication status. Обработчик меняет текст draft на published. Это самостоятельное DOM-упражнение: оно не вызывает наш Node-модуль, не делает запрос в сеть и не сохраняет задачу. Начальное название Export меняется тестом на Release checklist, а после клика должно остаться тем же.

Семантический сценарий

typescriptУчебный пример
const editor = page.getByRole('main',{name:'Task editor'});
await editor.getByLabel('Task title').fill('Release checklist');
await expect(editor.getByRole('status',{name:'Publication status'}))
  .toHaveText('draft');
await editor.getByRole('button',{name:'Publish task',exact:true}).click();
await expect(editor.getByRole('status',{name:'Publication status'}))
  .toHaveText('published');
await expect(editor.getByLabel('Task title'))
  .toHaveValue('Release checklist');

Локатор выражает пользовательский договор

Селектор .card:nth-child(2) button связывает тест с порядком и оформлением. Роль button и точное имя Publish task выражают действие, которое должен видеть пользователь. getByLabel проверяет связь подписи с полем. Ограничение поиска областью editor помогает избежать неоднозначности, если на странице появится вторая кнопка с таким же именем. Если локатор находит несколько элементов, уточните смысловую область, а не добавляйте случайный first(), скрывающий неоднозначность.

Устойчивость не означает запрет CSS во всех случаях. Для технической структуры или явно согласованного test id могут быть свои основания. Но селектор должен отражать стабильный договор и давать понятный отказ при его нарушении. Изменение доступного имени пользователю может быть важным изменением интерфейса, а перестановка декоративных контейнеров обычно не должна ломать сценарий. Решение выбирают по риску и поддерживаемости, а не по минимальному числу символов.

Ожидание условия вместо секунд

Перед click Playwright проверяет применимость действия: элемент должен быть подходящим для взаимодействия. Это не означает, что после клика любое бизнес-действие завершено. Для результата используется await expect(locator).toHaveText('published'): проверка повторяется до выполнения условия или исчерпания тайм-аута. Произвольная пауза на две секунды одновременно замедляет быстрые случаи и не гарантирует успех медленных.

Не заменяйте такую проверку на expect(await locator.isVisible()).toBe(true), когда требуется дождаться изменения. Мгновенное наблюдение отвечает на вопрос о текущем кадре. Проверка текста и значения поля после действия ловит два разных дефекта: отсутствие нового статуса и потерю пользовательского ввода. Скриншот может помочь диагностике, но assertion должен выражать требование явно.

Файл дан на TypeScript: import {test,expect} подключает Playwright Test, async-функция принимает fixture page, await связывает последовательные действия. Основной Node-набор курса не требует Playwright. Для DOM-упражнения создаётся отдельный проект по командам в тетради; зависимости не добавляются в QA Orbit. При подготовке курса файл прошёл чтение и проверку структуры, но Playwright runner не запускался. До вашего отдельного запуска статус именно «не выполнено», а не «браузеры проверены».

Отдельная установка

В новой папке: npm init -y; npm install --save-dev @playwright/test; npx playwright install chromium. Сохраните dom-exercise.spec.ts туда и выполните npx playwright test dom-exercise.spec.ts. Команды установки требуют доступ к npm и загрузку браузера. Это дополнительная практика; основная Node-практика работает без неё.

Источники и проверка фактов

Playwright · LocatorsРоли, доступные имена и область поиска.Playwright · Auto-waitingОжидания перед действием.Playwright · AssertionsПовторяемые проверки наблюдаемого результата.

Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1

Теперь применим это к задачеПопробуйте сами, прежде чем открывать разбор.
Предыдущий урокУровни проверки и контракт состоянияСледующий урокИзоляция, fixtures и асинхронность
QA ORBIT

Проверяй. Понимай. Расти.

Пространство осмысленного тестирования.
ИсследуйтеНовостиИнструментыБиблиотека
РазвивайтесьКурсыТренажёрыМаршруты обученияИИ и тестирование
Оставайтесь на орбитеО проекте Полезные сайтыГлоссарий
© 2026 QA Orbit. Сделано с вниманием к деталям.
КонфиденциальностьУсловия использования Всегда есть что исследовать