Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Чекбокс нажимается, но при этом поле не активируется

selenium
java
webdriver
Теги: #<Tag:0x00007f7b5ffec130> #<Tag:0x00007f7b5fff3d18> #<Tag:0x00007f7b5fff3e58>

(Denis Vovchenko) #1

Добрый день! Столкнулся с такой проблемой:
Тест в котором был метод нажатие на чекбокс:

public void searchValueAndClickCheckBox(List<WebElement> list, String search, String checkBoxXPath, String textXPath){
for (WebElement tr: list){
    WebElement checkBox = tr.findElement(By.xpath(checkBoxXPath));
    WebElement text = tr.findElement(By.xpath(textXPath));
    if (text.getText().equals(search)){
        checkBox.click();
        break;
    }
}

}
Работал, до того момента, пока я не добавил:

    DesiredCapabilities dc = DesiredCapabilities.internetExplorer();
    dc.setCapability("nativeEvents", false);

После этого, при прохождение теста, когда драйвер нажимает на чекбокс - галочка появляется, но в поле не появляется значение которое отмечено. При этом, когда делаешь нажатие руками - все работает.
То как работает на тесте:

То как работает, если нажимать руками:


(Ray Romanov) #2

Ну естественно, отключил нативную обработку, вот твой JS скрипт и не обрабатывается.


(Denis Vovchenko) #3

То что я отключил нативную обработку - это понятно.
Вопрос в том, что обойти как-то можно?


(Ray Romanov) #4

А зачем отключил, в чем грандиозный замысел?


(Denis Vovchenko) #5

Тест проходит на Windows Server, IE8 - связка очень тупит.
При вводе текста иногда бывает, например так:
sendKeys(“Какой-то текст”) а в строку он может ввести “Ка кой -тоте кст” или как-то еще рандомно.


(Евгений Бухгаммер) #6

на EditBox вешается какой-нибудь джаваскрипт, который по событию ввода сразу будет проверять введенную инфу в этот EditBox, валидирует что ему там вздумается. Я пришел к общим правилам таким, что это должно лечиться просто более медленным вводом при автоматизации “диктуйте медленней, я записываю” ©, если, конечно, сам тест не являет собой проверку этого джаваскрипта на UX и корректность соответствия исходных вводимых данных тем данным, что в EditBox начинают фигурировать.

вот есть у вас например:

name = "Vasiliy Pupkin"
input_name_xpath = "//*[@id="name_input"]"

def type_with_pause(input_text, edit):
    """
     ***input_text - строка которую вводим в Эдит
     ***edit- референс на объект нужного нам Эдита
    """
    currently_put_text = u""
    for c in input_text:
        edit.sendKeys(c)
        time.sleep(1)
        # можно добавить assert и валиться, если ожидаемая информация искажается
        # currently_put_text += c
        # assert currently_put_text == edit.text

type_with_pause(name, input_name_xpath)

(Denis Vovchenko) #7

Спасибо, буду пробовать


(Denis Vovchenko) #8

А можно написать просто метод, который будет проверять введенный текст поля, и если не равен перезаписывать!?


(Евгений Бухгаммер) #9

Я бы не рекомендовал так делать, т.к. перезаписывать и делать проверки можно очень долго, и если какой-то валидатор на JS так скверно себя ведет, то лучше не отходя от кассы понаблюдать за его поведением, почитать его код в Консоли браузера, чтобы понять, как он работает. На крайний случай - написать разработчикам фронтенда тикет. Вслепую гадать и пытаться понять - не лучший вариант. Но если все же хотите - написать такой метод - можно :slight_smile:

В этом случае вместо assert блока будет if блок на проверку currently_put_text == edit.text
и в случае неравенства - очистка эдит бокса и рекурсивный вызов этой же самой функции.