как найти на странице javascript-скрипт и вызвать его в тесте ?

Хм…
На этом форуме подключен jQuery.
Интересно, а как его заюзать?
Может просто в executeScript вызвать вот этот код?:

var msg;
if (window.jQuery) {
    msg = 'You are running jQuery version: ' + jQuery.fn.jquery;
} else {
    msg = 'jQuery is not installed';
}
return msg;

Ну в моем случае код теста на JS:

return driver.executeScript("тут наш скрипт").then((txt) => {
    console.log(txt) // вернет "You are running jQuery version: 2.2.0"
}) 

Или я не в ту степь ушел?

Я попробую еще раз. Изначальный вопрос у автора: как выполнить код js скрипта, который прячется за ng-click=“ctrl.confirmemailproperty()”.
Как вы выполните код за вызовом метода ctrl.confirmemailproperty() без действий на стороне ui?
Мне не нужно проверять установлена ли библиотека jquery. Я знаю, что есть такой метод как execute_script, но ему нужно подать js код, а не путь к js файлу.
Я хочу выполнить код js скрипта, который должен выполниться при нажатии на кнопку, но без нажатия на кнопку.
Вы сказали, что это можно сделать без хранения вот того самого кода у себя в проекте или где угодно, куда вы имеете доступ ( к веб серверу вы не имеете доступ). Я интересуюсь, как это сделать.

Попробовать так:

angular.element(document.querySelector('button.uri-button.component_ok_set'))
    .scope()
    .ctrl
    .confirmemailproperty();
1 лайк

отлично, спасибо!)
думаю это и есть ответ на самый первый вопрос в этом теме)

на Protractor для этого исп .

NgWebElement e = 
 ngDriver.FindElement(NgBy.Model("custId"))
.FindElements(NgBy.Repeater("cust in Customers"))
.First(cust => Regex.IsMatch(cust.Text, "Harry Potter"));
e.Evaluate("ctrl.confirmemailproperty()") 

-Локатор из другого проекта, для иллюстрации

Как минимум, вы явно ожидаете, что некий элемент появится в этой таблице - его и ожидайте.
Продумайте как вы собираетесь проверить какую-то функцию, что она работает: если необходимо - создайте объект с нужными свойствами, а далее примените фильтр - он будет в топе, так как стандартная сортировка от нового к старому.

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

Вот и получится грустная история о том, что раздел протестирован, а то что в него пользователь попасть не может - никто и не подумал, ведь я же URL нужный открою - и всё, делов-то.

Не всегда такое бывает.

Например: например вы не готовите БД до тестов, поэтому “точно не знаете, какие элементы должны появиться в этой таблице”, НО “знаете, что должны появиться элементы с нужными свойствами”. Если же все таблицу проверять с помощью ExpectedConditions - это будет скажем так не быстро. Проще дождаться, что страница обновилась, все скрипты отработали и готова к проверке и потом проверять наличие элементов.

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

Тут больше холивар о том, что вы проверяете “работоспособность скриптов” или “работу пользователя с этим функционалом”. И тут нет правых и неправых.

Но что мешает преподготовить бд, или предыдущим тестом создать необходимый объект, подходяший под условия фильтрации? Вы же фильтруете что бы найти что-то конкретное? Так почему тесты проверяют абстрактную работу?

К чему этот вопрос? Ведь по вашему независимо от цели не нужны скрипт екзекьюторы.

Бывают разные ситуации на разных проектах.