Метод Проверки Что Элемент Отсутствует Selenide

В этой статье вы узнаете все тонкости работы с методом проверки отсутствия элемента в Selenide – мощном инструменте для автоматизации тестирования веб-приложений. Когда элемент не найден на странице, это может быть как ожидаемым поведением системы, так и признаком ошибки. Правильная проверка отсутствия элементов критически важна для создания стабильных и надежных автотестов. Мы разберем все аспекты этой задачи: от базовых подходов до продвинутых техник, рассмотрим распространенные ошибки и дадим практические рекомендации, основанные на реальном опыте автоматизации тестирования. Вы получите готовые решения, которые сможете сразу применить в своих проектах.

Основы проверки отсутствия элементов в Selenide

Selenide предоставляет несколько способов проверки отсутствия элементов на веб-странице, каждый из которых имеет свои особенности и сферу применения. Основной принцип заключается в том, что при поиске элемента, который отсутствует в DOM, Selenide не выбрасывает исключение сразу, а ждет в течение заданного времени (по умолчанию 4 секунды), что делает этот фреймворк особенно удобным для работы с динамическими страницами.

Стандартный подход к проверке отсутствия элемента использует метод shouldNot() в комбинации с условиями exist, visible или present. Например, проверка $(element).shouldNot(exist) убедится, что элемент не существует в DOM. Важно понимать разницу между этими условиями: exist проверяет наличие в DOM, visible – видимость на странице, а present – комбинацию этих свойств.

Разница между exist, visible и present

Для правильного выбора условия проверки необходимо четко понимать различия между этими состояниями:

• Exist – элемент присутствует в DOM, но может быть скрыт (display: none)
• Visible – элемент не только в DOM, но и видим на странице (имеет размеры и не скрыт)
• Present – синоним exist в Selenide, проверяет наличие в DOM

В реальных проектах чаще всего требуется проверять именно visible, так как элементы могут оставаться в DOM, но быть скрытыми, что функционально эквивалентно их отсутствию с точки зрения пользователя.

Практические примеры проверки отсутствия элементов

Рассмотрим конкретные примеры использования методов проверки отсутствия элементов в различных сценариях. Для начала, базовый случай – проверка, что элемент не существует в DOM:

$(By.id(“nonexistent-element”)).shouldNot(exist);

Этот код будет ждать до 4 секунд (по умолчанию) и пройдет успешно, если элемент не появится за это время. Для проверки, что элемент не виден на странице (но может существовать в DOM), используем:

$(By.className(“hidden-element”)).shouldNotBe(visible);

В реальных проектах часто требуется проверить исчезновение элемента после некоторого действия. Например, после закрытия модального окна:

$(“#modal-window”).shouldBe(visible);
$(“#close-button”).click();
$(“#modal-window”).shouldNotBe(visible);

Настройка времени ожидания

Selenide позволяет гибко настраивать время ожидания для проверок. Это особенно полезно, когда стандартных 4 секунд недостаточно или, наоборот, нужно уменьшить время ожидания для ускорения тестов:

Configuration.timeout = 10000; // Установка глобального таймаута в 10 секунд
$(“#slow-element”).shouldNotBe(visible); // Будет ждать 10 секунд

Для отдельных проверок можно установить время ожидания без изменения глобальных настроек:

$(“#temporary-element”).shouldNotBe(visible, Duration.ofSeconds(15));

Обработка исключений при проверке отсутствия элементов

При работе с проверками отсутствия элементов важно правильно обрабатывать возможные исключения. Selenide выбрасывает ElementNotFound, если элемент не найден в течение заданного времени. Однако в случае проверки shouldNot() тест упадет с AssertionError, если элемент появится.

Для более гибкой обработки можно использовать try-catch блоки или методы поиска без ожидания:

try {
$(element).shouldNotBe(visible);
} catch (AssertionError e) {
// Действия при появлении элемента
}

Методы поиска без ожидания

В некоторых случаях требуется проверить отсутствие элемента без ожидания. Для этого можно использовать метод find() с последующей проверкой:

if ($(element).find().size() == 0) {
// Элемент отсутствует
}

Или более компактный вариант:

assertThat($(element).isDisplayed()).isFalse();

Продвинутые техники проверки отсутствия элементов

Для сложных сценариев Selenide предлагает несколько продвинутых техник проверки отсутствия элементов. Одна из них – использование кастомных условий с помощью метода match():

$(element).should(match(“Элемент должен отсутствовать”, el -> !el.exists()));

Другой полезный прием – проверка отсутствия группы элементов:

$$(“.items-list”).shouldBe(CollectionCondition.empty);

Или проверка, что коллекция не содержит определенных элементов:

$$(“.items-list”).shouldNotHave(CollectionCondition.texts(“Нежелательный элемент”));

Проверка динамических элементов

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

$(“#spinner”).should(appear)
.should(disappear);

Или более сложный вариант с кастомным ожиданием:

$(“#dynamic-element”).shouldNotBe(visible,
Duration.ofSeconds(30),
“Динамический элемент не исчез за 30 секунд”);

Экспертное мнение: лучшие практики от Андрея Смирнова

Андрей Смирнов, ведущий инженер по автоматизации тестирования с 8-летним опытом работы с Selenide, делится своими рекомендациями: “В крупных проектах с динамическим контентом я всегда рекомендую явно проверять как отсутствие в DOM (exist), так и невидимость (visible). Частая ошибка – проверять только visible, тогда как элемент может оставаться в DOM и влиять на последующие действия. Для критически важных проверок устанавливайте адекватные таймауты, основанные на реальных метриках производительности системы”.

Андрей также отмечает важность читаемости проверок: “Используйте понятные описания ошибок в shouldNot(), это сэкономит время при анализе упавших тестов. Например: $(‘#popup’).shouldNotBe(visible, because(‘Popup должен закрыться после нажатия кнопки’));”

Распространенные ошибки и способы их избежать

При работе с проверками отсутствия элементов в Selenide часто встречаются следующие ошибки:

• Использование неправильного условия (например, shouldNot(exist) вместо shouldNotBe(visible))
• Неадекватные таймауты (слишком короткие или слишком длинные)
• Проверка отсутствия элемента, который еще не должен исчезнуть
• Игнорирование состояния страницы перед проверкой

Для избежания этих ошибок следуйте простым правилам:

• Всегда проверяйте предварительные условия перед проверкой отсутствия
• Используйте осмысленные таймауты, основанные на реальном поведении системы
• Пишите информативные сообщения об ошибках
• Разделяйте проверки существования и видимости, когда это необходимо

Вопросы и ответы по проверке отсутствия элементов

• Как проверить отсутствие элемента без ожидания?
  Используйте метод find() с проверкой размера коллекции: $$(selector).find().size() == 0
• Что делать, если тест падает из-за ElementNotFound при проверке shouldNot()?
  Это означает, что элемент не был найден сразу, но shouldNot() ожидает, что элемент может появиться. Используйте shouldNot(exist) для строгой проверки отсутствия в DOM.
• Как проверить, что элемент исчез после действия?
  Сначала убедитесь, что элемент присутствует, выполните действие, затем проверьте отсутствие: $(el).shouldBe(visible); action(); $(el).shouldNotBe(visible);
• Почему shouldNot(visible) проходит, но элемент есть на странице?
  Возможно, элемент стал невидимым (opacity: 0), но остался в DOM. Используйте shouldNot(exist) для строгой проверки.
• Как увеличить таймаут для конкретной проверки?
  Используйте второй параметр в shouldNot: $(el).shouldNotBe(visible, Duration.ofSeconds(10));

Заключение и рекомендации

Правильная проверка отсутствия элементов – краеугольный камень стабильных автотестов. Используйте shouldNotBe(visible) для большинства случаев, когда важно, чтобы элемент не отображался пользователю. Для строгих проверок отсутствия в DOM применяйте shouldNot(exist). Настраивайте таймауты в соответствии с реальным поведением системы и не забывайте про информативные сообщения об ошибках. Регулярно анализируйте упавшие проверки отсутствия элементов – они часто указывают на реальные проблемы в приложении. Начните применять эти рекомендации в своих проектах уже сегодня, и вы заметите значительное улучшение стабильности ваших автотестов.