Comments 24
И причём тут MS Dynamics CRM?
Тут показан один из методов тестирования клиентского кода, который можно применить в MS Dynamics CRM.
Других адекватных нет, к сожалению. А что вы хотели увидеть особенного?
Других адекватных нет, к сожалению. А что вы хотели увидеть особенного?
Я вижу супер простой тест через selenium в котором даже есть возможность найти элемент по id. Таким макаром можно было применить любой инструмент для функционального авто тестирования веб приложений. Учитывая это вся статья сводится к установке пары nuget пакетов и примера из любого туториала по selenium коих тысячи. А я ожидал, судя по заголовку, раскрытия уникальных особенностей тестирования MS Dynamics CRM.
Особенностей никаких, кроме driver.SwitchTo().Frame(contentFrame);
Статья призвана показать, что такой подход возможен.
Никаких уникальных особенностей быть и не может.
Статья призвана показать, что такой подход возможен.
Никаких уникальных особенностей быть и не может.
Никаких уникальных особенностей быть и не может.
Не очень тогда понятно почему
Других адекватных нет, к сожалению.
Из-за особенностей Dynamics CRM. Мы можем писать только обработчики событий, такое тестирование, как например, с использованием Karma, Jasmine тут не подходит. Мы можем лишь «протыкать» UI.
Итак, вы сравниваете связку karma + jasmine с связкой selenium + mstest и говорите что одно может делать функциональное тестирование веб приложений через ui браузеров, а другое не может. Ну да, действительно это так. Но и из этого автоматом не следует что selenium единственный инструмент который может тестировать MS Dynamics CRM. Или я не понял вашу мысль?
А что вы хотели увидеть особенного?
Хотя бы один нормальный тест всей системы. Начиная с заполнения базы фикстурами.
Я пытаюсь сказать, что адекватные инструменты вроде karma+jasmine не подходят для тестирования MS Dynamics CRM.
И остаются только «протыкивалки», коих много. И вот WebDriver оказался весьма удачным вариантом.
И остаются только «протыкивалки», коих много. И вот WebDriver оказался весьма удачным вариантом.
Не вижу ничего не адекватного в использовании инструментов работающих непосредственно с браузером. Для каждой задачи свой инструмент и тестирование портала в реальном браузере имеет свои плюсы и свои минусы. Однако смысловая нагрузка статьи сжалась в одну строчку,
И то явно этой строчки нет, нужно вчитываться в пример.
Перед тестированием нужно переключиться на frame contentIFrame
И то явно этой строчки нет, нужно вчитываться в пример.
Я и не говорил, что инструменты, работающие непосредственно с браузером, не адекватные.
Просто по ряду причин, они лучше.
Просто по ряду причин, они лучше.
Ну как же так
Одни инструменты адекватны.
А те кто остались не адекватны.
И да, чем они лучше и при каких условиях?
Я пытаюсь сказать, что адекватные инструменты вроде karma+jasmine не подходят для тестирования MS Dynamics CRM.
Одни инструменты адекватны.
И остаются только «протыкивалки», коих много.
А те кто остались не адекватны.
И да, чем они лучше и при каких условиях?
Ты баран? Где я сказал, что какие-то средства неадекватны? Я же черным по белому написал для MS Dynamics CRM.
Добрый день, сегодня пятница 25 декабря и я позволил себе наглость прочитать вашу статью, задавать по ней вопросы и цитировать ваши комментарии. Простите меня, я не хочу быть бараном. А если серьёзно, то я чуть выше цитировал ваш комментарий который дал мне повод увидеть у вас разделение о котором я говорю.
Поясняю: есть более подходящие, а есть менее подходящие инструменты. Вот karma+jasmine не подходит для MS Dynamics CRM, а Selenium подходит. И тут нигде не сказано, что какой-то инструмент неадекватен.
Я конечно могу продолжить и ещё раз процитировать комментарий где было про «адекватные» инструменты, но учитывая что тут не так много комментариев и его так и так видно, не буду. Да и после барана не сильно хочется продолжать общение.
Однако желаю удачи в использовании выбранных инструментов и буду ждать следующих статей которые
Однако желаю удачи в использовании выбранных инструментов и буду ждать следующих статей которые
коротенько и по делу:)
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, например, для этих целей?
А кто сказал, что на странице нет элемента с айдишником weightedEstimatedValueId и что этот элемент значение не имеет?
и чего ждать, когда эту штуку может вычислять долговыполняющийся яваскриптовый код?
и чего ждать, когда эту штуку может вычислять долговыполняющийся яваскриптовый код?
Если я правильно понял, то слип именно для этого. Если нет, прошу прощения — поясните, пожалуйста, назначение слипа в тесте.
значение инпута, который имеет id «weightedEstimatedValueId» может устанавливаться путем выполнения яваскрипта, причем длительного давольно, поэтому тут есть вот такой слип. При этом устанавливается только значение weightedEstimatedValueId и не факт, что из какого-то дефолтного. И как бы нет такого условия, которого бы мы ожидали.
Вас понял. В этом случае я бы ожидал, когда значение элемента управления станет expectedWeightedValue с помощью того же wait.Until. Тогда слип не потребуется.
значение инпута, который имеет id «weightedEstimatedValueId» может устанавливаться путем выполнения яваскрипта, причем длительного давольно, поэтому тут есть вот такой слипВот и нужно подождать, пока значение инпута изменится с текущего на ожидаемое. Это и будет условие, которого «нет».
Sign up to leave a comment.
Применение Selenium WebDriver для тестирования MS Dynamics CRM