Применение Selenium WebDriver для тестирования MS Dynamics CRM

[Elufimov]

И причём тут MS Dynamics CRM?

[TheHedgehog]

Тут показан один из методов тестирования клиентского кода, который можно применить в MS Dynamics CRM.
Других адекватных нет, к сожалению. А что вы хотели увидеть особенного?

[Elufimov]

Я вижу супер простой тест через selenium в котором даже есть возможность найти элемент по id. Таким макаром можно было применить любой инструмент для функционального авто тестирования веб приложений. Учитывая это вся статья сводится к установке пары nuget пакетов и примера из любого туториала по selenium коих тысячи. А я ожидал, судя по заголовку, раскрытия уникальных особенностей тестирования MS Dynamics CRM.

[TheHedgehog]

Особенностей никаких, кроме driver.SwitchTo().Frame(contentFrame);

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

[Elufimov]

Никаких уникальных особенностей быть и не может.

Не очень тогда понятно почему

Других адекватных нет, к сожалению.

[TheHedgehog]

Из-за особенностей Dynamics CRM. Мы можем писать только обработчики событий, такое тестирование, как например, с использованием Karma, Jasmine тут не подходит. Мы можем лишь «протыкать» UI.

[Elufimov]

Итак, вы сравниваете связку karma + jasmine с связкой selenium + mstest и говорите что одно может делать функциональное тестирование веб приложений через ui браузеров, а другое не может. Ну да, действительно это так. Но и из этого автоматом не следует что selenium единственный инструмент который может тестировать MS Dynamics CRM. Или я не понял вашу мысль?

[VolCh]

А что вы хотели увидеть особенного?

Хотя бы один нормальный тест всей системы. Начиная с заполнения базы фикстурами.

[TheHedgehog]

Я пытаюсь сказать, что адекватные инструменты вроде karma+jasmine не подходят для тестирования MS Dynamics CRM.
И остаются только «протыкивалки», коих много. И вот WebDriver оказался весьма удачным вариантом.

[Elufimov]

Не вижу ничего не адекватного в использовании инструментов работающих непосредственно с браузером. Для каждой задачи свой инструмент и тестирование портала в реальном браузере имеет свои плюсы и свои минусы. Однако смысловая нагрузка статьи сжалась в одну строчку,

Перед тестированием нужно переключиться на frame contentIFrame

И то явно этой строчки нет, нужно вчитываться в пример.

[TheHedgehog]

Я и не говорил, что инструменты, работающие непосредственно с браузером, не адекватные.
Просто по ряду причин, они лучше.

[Elufimov]

Ну как же так

Я пытаюсь сказать, что адекватные инструменты вроде karma+jasmine не подходят для тестирования MS Dynamics CRM.

Одни инструменты адекватны.

И остаются только «протыкивалки», коих много.

А те кто остались не адекватны.
И да, чем они лучше и при каких условиях?

[TheHedgehog]

Я что-то вообще ничего не могу понять из вашего последнего поста.
Можете сформулировать мысль доступно?

[Elufimov]

Я пока вас никак не могу понять. Одни средства у вас адекватны, другие не адекватны. Одни лучше, другие хуже. В статье это не разбирается Кто, почему, в каких условиях, при каких задачах лучше/хуже. Есть только «ряд причин» и «особенности» которые тоже не расписаны.

[TheHedgehog]

Ты баран? Где я сказал, что какие-то средства неадекватны? Я же черным по белому написал для MS Dynamics CRM.

[Elufimov]

Добрый день, сегодня пятница 25 декабря и я позволил себе наглость прочитать вашу статью, задавать по ней вопросы и цитировать ваши комментарии. Простите меня, я не хочу быть бараном. А если серьёзно, то я чуть выше цитировал ваш комментарий который дал мне повод увидеть у вас разделение о котором я говорю.

[TheHedgehog]

Поясняю: есть более подходящие, а есть менее подходящие инструменты. Вот karma+jasmine не подходит для MS Dynamics CRM, а Selenium подходит. И тут нигде не сказано, что какой-то инструмент неадекватен.

[Elufimov]

Я конечно могу продолжить и ещё раз процитировать комментарий где было про «адекватные» инструменты, но учитывая что тут не так много комментариев и его так и так видно, не буду. Да и после барана не сильно хочется продолжать общение.
Однако желаю удачи в использовании выбранных инструментов и буду ждать следующих статей которые

коротенько и по делу:)

[fufnf]

Thread.Sleep(10000);
var weightedValueElement = driver.FindElement(By.Id(weightedEstimatedValueId));

Почему именно 10000, а не, скажем 5000 или 20000?

Конечно это жесткий костыль, который сильно влияет на производительность и стабильность тестов.
Есть такая штука как WebDriverWait:

IWait wait = new WebDriverWait(driver, TimeSpan.FromSeconds(10))
IWebElement element = wait.Until(driver => driver.FindElement(By.Id(weightedEstimatedValueId)));

Будет ждать элемент, пока он не появится либо пока не произойдет таймаут.

Еще вопрос, почему был выбран именно C#, а не JS, например, для этих целей?

[TheHedgehog]

А кто сказал, что на странице нет элемента с айдишником weightedEstimatedValueId и что этот элемент значение не имеет?
и чего ждать, когда эту штуку может вычислять долговыполняющийся яваскриптовый код?

[fufnf]

Если я правильно понял, то слип именно для этого. Если нет, прошу прощения — поясните, пожалуйста, назначение слипа в тесте.

[TheHedgehog]

значение инпута, который имеет id «weightedEstimatedValueId» может устанавливаться путем выполнения яваскрипта, причем длительного давольно, поэтому тут есть вот такой слип. При этом устанавливается только значение weightedEstimatedValueId и не факт, что из какого-то дефолтного. И как бы нет такого условия, которого бы мы ожидали.

[fufnf]

Вас понял. В этом случае я бы ожидал, когда значение элемента управления станет expectedWeightedValue с помощью того же wait.Until. Тогда слип не потребуется.

[ekungurov]

значение инпута, который имеет id «weightedEstimatedValueId» может устанавливаться путем выполнения яваскрипта, причем длительного давольно, поэтому тут есть вот такой слип

Вот и нужно подождать, пока значение инпута изменится с текущего на ожидаемое. Это и будет условие, которого «нет».