Комментарии 15
Отличная статья. Спасибо, забрал в избранное)
A чем вам Ranorex не понравился? Там фиксированная стоимость лицензии, если делаешь для заказчика — просто перекладываешь стоимость интрумента на него. Порог вхождения в инструмент, чтобы полностью разобраться — месяц. Начать писать первые тесты можно уже с первого дня. Поддержка есть. Тренинги, обучающий материал. И стоит оно не столько много.
Я просто как-то не верю в то, что разработка и поддержка своего инструмента в перспективе будет дешевле. Про vendor lock-in… так самодельные решения это впринципе тот же vendor lock-in — ушли ребята которые этим занимались и загнулся инструмент, потому что никто больше не знает как его код работает. А если относиться к нему как к полноценному программному проекту — нужны деньги уж точно не меньшие, чем на приобретение стороннего решения и обучение специалистов.
Я просто как-то не верю в то, что разработка и поддержка своего инструмента в перспективе будет дешевле. Про vendor lock-in… так самодельные решения это впринципе тот же vendor lock-in — ушли ребята которые этим занимались и загнулся инструмент, потому что никто больше не знает как его код работает. А если относиться к нему как к полноценному программному проекту — нужны деньги уж точно не меньшие, чем на приобретение стороннего решения и обучение специалистов.
НЛО прилетело и опубликовало эту надпись здесь
тесты почему-то криво мерджились у нас в гитлабе
работа в команде над одним и тем же проектом там порой заковыриста, чтобы на ноги друг другу не наступать. Изза кодгена и своего формата практически бесполезно диффать код. Т.е. и ревью нужно делать по-другому. Например мерджить себе на машину и пробовать.
Хотя если работать через Visual Studio и просто пользоваться их либой то процесс разработки не должен отличаться от классического.
То что там в 4.5.2 чего-то нехватает, ну я брал сторнонние библиотеки. Можно апнуть проект до 4.7.2. И думаю если фронтенд на винде вдруг перейдет на новые технологии, то они будут это поддерживать. например Еdge Chromium они бысто подцепили.
А если интерфейс доступа к UI с dotNet 6 не поменяется то как бы нет смысла компилировать под более новую версию дотнета. Это же просто версия под которой они компилируют солюшн, а сам тестовый обьект может быть написан на любой версии фреймворка.
Но я понимаю, что заморочки они всегда отталкивают.
НЛО прилетело и опубликовало эту надпись здесь
Раз уж завел разговор хочу разобраться до конца…
www.ranorex.com/supported-technologies
То что их инструмент по совпадению сам сделан на си шарпе, никак тут не мешает.
Версии 4.5.2-4.7.2 это тот стандарт под который Ranorex компилирует проект. Это не мешает ему при этом работать с приложениями написаными на других технологиях и версиях фреймворка. Единственное где можно упереться в используемую для компиляции версию dotNet это когда пишешь для тестов кастомный код и хочешь там использовать функции которых нет в старых версиях фреймворка. Мне например для парсинга json ответов с API пришлось использовать сторонюю библиотеку от Newtonsoft, потому что встроенная поддержка парсинга json появилась в более позндей версии dotNet.
А может я чего-то не понял, если не пользоваться их IDE а писать чисто под Visual Studio, пристегивая их библиотеку, (мне, правда так не приходилось работать), то это только в том случае мешает использованию более новых версий dotNet в продукте если вы и продукт и тесты держите в одном проекте. А зачем так делать? Для написания тестов свое окружение для написания продукта — свое.
P.S.:
А вот, конечно, из недостатков нельзя не отметить, что тесты будут запускаться только из под винды, потому что тестовый пакет компилируется в экзешник.
И какой толк от тестов если я протестирую только версию для .NET Framework, а потом у меня крякнется версия для .NET Core потому что там что-то с её библиотеками не так.Тестируемое приложение может быть написано на любой технологии .Net, .NetCore .Net Windows Forms, Delphi, Air, Gtk… и там куча других.
www.ranorex.com/supported-technologies
То что их инструмент по совпадению сам сделан на си шарпе, никак тут не мешает.
Версии 4.5.2-4.7.2 это тот стандарт под который Ranorex компилирует проект. Это не мешает ему при этом работать с приложениями написаными на других технологиях и версиях фреймворка. Единственное где можно упереться в используемую для компиляции версию dotNet это когда пишешь для тестов кастомный код и хочешь там использовать функции которых нет в старых версиях фреймворка. Мне например для парсинга json ответов с API пришлось использовать сторонюю библиотеку от Newtonsoft, потому что встроенная поддержка парсинга json появилась в более позндей версии dotNet.
А может я чего-то не понял, если не пользоваться их IDE а писать чисто под Visual Studio, пристегивая их библиотеку, (мне, правда так не приходилось работать), то это только в том случае мешает использованию более новых версий dotNet в продукте если вы и продукт и тесты держите в одном проекте. А зачем так делать? Для написания тестов свое окружение для написания продукта — свое.
P.S.:
А вот, конечно, из недостатков нельзя не отметить, что тесты будут запускаться только из под винды, потому что тестовый пакет компилируется в экзешник.
А winappdriver не рассматривали? https://github.com/microsoft/WinAppDriver
С WinAppDriver сталкивались ранее на одном из наших проектов и были трудности в работе с ним(не было доступа к некоторым элементам), а поскольку он имеет закрытый исходный код, то возможности доработки не было.
В этот раз мы решили рассмотреть продукты с открытым исходным кодом и с возможностью внесения изменений.
В этот раз мы решили рассмотреть продукты с открытым исходным кодом и с возможностью внесения изменений.
Appium не пробовали? Вроде удовлетворяет всем требованиям. https://appium.io/docs/en/drivers/windows/
С WinAppDriver сталкивались ранее на одном из наших проектов и были трудности в работе с ним(не было доступа к некоторым элементам), а поскольку он имеет закрытый исходный код, то возможности доработки не было.
В этот раз мы решили рассмотреть продукты с открытым исходным кодом и с возможностью внесения изменений.
В этот раз мы решили рассмотреть продукты с открытым исходным кодом и с возможностью внесения изменений.
Давно слежу за развитием средств автоматизации тестирования.
По статье и комментариям вижу, что за прошедшие 10+ лет фактически никакого развития не произошло. Как были пляски с бубном, так и остались. Даже до разработки собственных решений дело дошло.
Значит, буду тестировать по старинке, ручками… )
«Если нужно вбить гвоздь, не ищи обходных путей — возьми обычный молоток, и вбей этот гвоздь!» (с)
По статье и комментариям вижу, что за прошедшие 10+ лет фактически никакого развития не произошло. Как были пляски с бубном, так и остались. Даже до разработки собственных решений дело дошло.
Значит, буду тестировать по старинке, ручками… )
«Если нужно вбить гвоздь, не ищи обходных путей — возьми обычный молоток, и вбей этот гвоздь!» (с)
НЛО прилетело и опубликовало эту надпись здесь
Видимо автоматизация вам и не очень-то и нужна раз вы обходитесь без нее.
Сколько тестовых сценариев руками за день прогоняете? Я без шуток, просто мне практически не довелось общаться с ручными тестировщиками и я слабо себе представляю их производительность. На одном из проектов где я работал, например, машина проходила около 80 экранов и проверяла около 250 функций за час, причем на 12 разных конфигурациях продукта.
Сколько тестовых сценариев руками за день прогоняете? Я без шуток, просто мне практически не довелось общаться с ручными тестировщиками и я слабо себе представляю их производительность. На одном из проектов где я работал, например, машина проходила около 80 экранов и проверяла около 250 функций за час, причем на 12 разных конфигурациях продукта.
1. в UIAutomation 99% стандартных контролов имеют одинаковое свойство ControlType
Поэтому при типизированном поиске автоматически дописываем, например, [@ControlType= 'ComboBox']"
Это позволяет обойтись без указания AutomationId во многих контролах
2.
в c# мы используем расширение
var comboBox = driver.FindElement<ComboBox>(xpath)
3.
Интересный опыт, по моим подсчетам большую часть времени отбирает формирование PageObject и поиск нужного XPath. Сколько у вас на это уходит времени?
Поэтому при типизированном поиске автоматически дописываем, например, [@ControlType= 'ComboBox']"
Это позволяет обойтись без указания AutomationId во многих контролах
2.
ComboBox comboBox = new ComboBox(driver.findElement(xpath));
в c# мы используем расширение
var comboBox = driver.FindElement<ComboBox>(xpath)
3.
Вложив силы и время в разработку собственного драйвера, удалось значительно сократить время и потратить меньше усилий на создание фреймворка и его внедрение, а также сильно упростить написание тестов.
Интересный опыт, по моим подсчетам большую часть времени отбирает формирование PageObject и поиск нужного XPath. Сколько у вас на это уходит времени?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FlaNium: как сделать тестирование Desktop-приложений под Windows проще