В зависимости от количества таких элементов на странице, нужно выполнить определенное количество действий по нажатию на каждый элемент, по нажатию он просто удаляется.
Привет!
Селенидовский ElementsCollection действительно не очень удачно сделан. Он был рассчитан на то, что элементы на странице могут подгружаться медленно, и ждёт, пока они подгрузятся. А вот на то, что элементы могут пропадать, мы как-то не рассчитывали.
К счастью, есть простое решение.
Выкиньте нафиг @FindBy - как я недавно писал, это бесполезная хрень.
By xpath = By.xpath(".//*[@id='inspectors']//i[contains(@class, 'icon--cancel--tn')]");
for (SelenideElement element = $(xpath); element.exists(); element = $(xpath)) {
element.click();
}
А вообще это какой-то стрёмный тест.
Какая от него польза? Что он вообще проверяет?
Тут скорее не проверка идет, а действия по удалению динамически созданных элементов.
Пример:
Допустим есть некий проект, за этим проектом можно закреплять пользователей разных ролей, добавлять можно любое количество пользователей. Ну и собственно в чем заключается тест, открывает некий проект, определяет какое количество пользователей закреплено за этим проектом и удаляет их (нажатием на кастомный элемент). Вот как то так.
P.S.
Похдход с FindBy плохой в принципе, потому что способствует “избыточности кода”. Если тебе нужна сущность только в одном месте - то незачем ее выносить в переменную (если только эта сущность не нуждается в читабельном имени, без которого прийдется использовать комментарий что бы ее объяснить). А подход с FindBy - не оставляет выбора - и учитывая то что обычно нужно “динамические элементы” (для тих же вейтов) принуждает тебя всегда создавать переменные, не важно нужны они или нет. Конечно это замечание касается чистого селениума, в селениде элементы - ленивые динамические прокси сами по себе, поэтому ты можешь и пользоваться просто:
и да, выделять несамодостаточную сущность - кнопку удаления - в отдельную переменную - это тоже ЗЛО потому что нечитабельно, не концептуально и не структурно а потому усложняет использование и поддержку.
или если учитывать твои нужды и то что селениде сейчас не апдейтит корректно состояние коллекции при использовании get и size, то:
private ElementsCollection inspectors() { return $$("#inspectors"); }
public void removeInspector(int index) {
inspectors().get(0).find(".icon--cancel--tn").click();
}
public void removeAllInspectors(int index) {
while (!inspectors().isEmpty()) {
removeInspector(0);
}
}
или если ты хочешь все в стиле ООП, то:
public class Inspectors {
private ElementsCollection inspectors() { return $$("#inspectors"); }
public void remove(int index) {
inspectors().get(0).find(".icon--cancel--tn").click();
}
public void removeAll(int index) {
while (!inspectors().isEmpty()) {
remove(0);
}
}
}
ну тут уже можно извращаться как только душе угодно, при этом конечно непонятно зачем, наверное из-за сильной любви к модным шаблонам типа ElementObject
public class Inspector {
SelenideElement self;
public Inspector(SelenideElement container) {
this.self = container
}
public void remove(int index) {
self.find(".icon--cancel--tn").click();
}
// ...
}
public class Inspectors {
private ElementsCollection inspectors() { return $$("#inspectors"); }
public Inspector inspector(int index){
return new Inspector(inspectors().get(index));
}
public void remove(int index) {
inspector(0).remove();
}
public void removeAll(int index) {
while (!inspectors().isEmpty()) {
remove(0);
}
}
}
P.S. 2 Тем кто сейчас набежит защищать свои любимые икспасы - ЗЛОМ я их обозвал не потому что они никогда не нужны, а потому что они не нужны в 99 процентов случаев Ну ок… в 99 процентов случаев ЕСЛИ вы используете selenide, в котором все для чего обычно нужны икспасы реализовуется намного более удобно и читабельно через методы
ElementsCollection#findBy(Condition)
ElementsCollection#filterBy(Condition)
ElementsCollection#exclude(Condition)
Selectors.byText(String)
Selectors.withText(String)
SelenideElement#parent()
…
Но даже если у вас нет такого замечательного инструмента как селениде - создать набор таких методов в виде хелперов - ничего не стоит. Это повысит ваше КПД при написании тестов и их поддержке на порядок по сравнению с использованием этих ужасных громоздких и абсолютно нечитабельных икспасов.
Единственный 1% где таки стоит использовать икспас напрямую - это там где есть ну очень большой список айтемов на странице, в несколько десятков - и у вас ну очень много кода где вы делаете кучу махинаций с этими айтемами - тогда тот бенефит в скорости который дадут икспасы - действительно может быть существенным.
А так то - все поиски по тексту, поиски среди соседей/друзей/родителей/детей/братьев реализовываются намного более читабельно (а потому экономят время на поддержке) с методами упомянутыми выше.
testomat.io управление авто тестами
Ну ок… в 99 процентов случаев ЕСЛИ вы используете selenide, в котором все для чего обычно нужны икспасы реализовуется намного более удобно и читабельно через методы