Ожидание перед действием решает свою задачу
Перед многими действиями Playwright проверяет готовность элемента. Для обычного клика важны, в частности, видимость, стабильность, возможность получать события и активное состояние. Это помогает избежать нажатия в неподходящий момент. Но такие проверки не подтверждают, что сервер сохранил заметку после нажатия. Между кликом и итогом могут происходить запрос, обработка и обновление интерфейса. Поэтому автоматическое ожидание перед действием нельзя считать полной проверкой бизнес-сценария. Нужно заранее определить, какой результат действительно означает успех для пользователя.
Проверяйте видимый результат с повторением условия
В учебном сценарии пользователь меняет текст заметки и нажимает кнопку сохранения. После завершения приложение показывает подтверждение и новый текст. Для проверки видимости Playwright предоставляет утверждение expect(locator).toBeVisible(), которое в тесте используют с await. Такая проверка повторяет условие до успеха или истечения установленного времени. Она отличается от одноразового чтения состояния в случайный момент. Фиксированная пауза тоже не доказывает результат: на одном запуске она окажется лишней, на другом слишком короткой. Ожидать полезно нужное состояние, а не просто прошедшие секунды.
Локатор должен обозначать нужный элемент
Если на странице две кнопки сохранения, поиск только по общему тексту может оказаться неоднозначным. Нужно уточнить область формы или другое устойчивое пользовательское различие. Локаторы по роли и доступному имени часто лучше выражают намерение теста, чем длинный путь по случайной структуре элементов. Но хороший локатор всё равно должен соответствовать интерфейсу. Нельзя выбирать первый совпавший элемент только ради исчезновения ошибки, если порядок не является частью проверяемого поведения. Такая замена может заставить тест успешно нажимать совсем другую кнопку.
Успешное сообщение должно относиться к текущему действию
Перед сценарием важно подготовить известное состояние. Если старое подтверждение уже осталось на экране, проверка его видимости после клика может пройти даже при неудачном новом сохранении. Поэтому используйте отличимый учебный текст и проверяйте ожидаемое изменение. Если задача требует подтверждения сохранности после повторного открытия, включите такую проверку отдельно в соответствующий тест. При падении полезно изучить фактическое состояние и диагностические материалы, а не сразу увеличивать все задержки. Причиной может быть ошибка приложения, неоднозначный локатор или неверная подготовка данных.
Попробуйте на практике
Спроектируйте тест сохранения вымышленной заметки в Playwright. Для задания достаточно описания шагов; запуск на чужом или рабочем сайте не требуется.
- Опишите исходное состояние: учебная заметка имеет старый текст, а подтверждение нового сохранения отсутствует. Выберите отличимый новый текст.
- Укажите, как однозначно найти поле и кнопку в нужной форме. Проверьте, что на странице возможны и другие похожие элементы.
- После действия задайте проверку текущего результата с повторяющимся утверждением. Объясните, почему ожидание фиксированного числа секунд недостаточно.
- Добавьте негативный разбор: старое сообщение уже видно, а новое действие не завершилось. Укажите, какая проверка не позволит принять этот случай за успех.
Как проверить результат. Сценарий различает готовность кнопки и завершение сохранения. Локатор однозначен, начальное состояние известно, а проверка связана с новым текстом и текущим действием, а не со старым подтверждением.
Частые вопросы
Auto-waiting означает, что все ожидания можно убрать?
Нет. Playwright помогает ожидать готовность действий, а тест должен явно проверять нужный результат. Это связанные, но разные задачи.
Нужно ли увеличивать тайм-аут после каждого случайного падения?
Сначала выясните причину. Большой тайм-аут не исправляет неверный локатор, старые данные или ошибку приложения и может лишь замедлить обнаружение проблемы.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.