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

Нужна помощь в освоении и написании Автотестов на scala

scala
Теги: #<Tag:0x00007f7b64bea8c0>

(Петров Денис) #1

Всем привет! Очень интересуют автотесты на scala, а именно тестирование web сайтов. документации на русском практически нет, а хотелось бы хотя бы на примерах понять как на scala написать автотест? например авторизация на сайте, нажатие на кнопки, открытие выпадающих списков и т.д. может ли кто нибудь помочь в этом или сказать где есть примеры конкретные? было бы очень хорошо если бы были конкретные примеры, надеюсь на вашу помощь друзья! Есть ли у кого нибудь опыт на этом поприще?


Как правильно писать функциональные тесты для сервисов на scala?
(sidelnikovmike) #2

А почему именно scala? чем не подходит Java+Selenium?


(Петров Денис) #3

Ну если вы можете помочь с Java+Selenium, я тоже не откажусь, хотя бы примеры или ссылки на хорошие статьи, где можно узнать как работать со всеми элементами на web странице. А scala потому, что она как язык компактнее, можно все сделать короче, соответственно возможность ошибки снижается в разы, ну и есть мощный инструмент scalatest, который хотелось бы освоить, но есть только на английском документация, примеров очень мало(


(sidelnikovmike) #4

Очень советую поискать по форуму, тут материалов оооочень много.
Что касается лаконичности - посмотрите в сторону selenide(http://selenide.org)


(Igor) #5

У меня на проекте есть тесты на Scala. Но это юнит и интеграционные тесты. Имхо, Scala имеет смысл брать, если само приложение пишется на Scala. Язык сам по себе сильно отличается от Java и достаточно много времени нужно вложить, чтобы изучить его нормально.


(Петров Денис) #6

Очень жалко, что у вас нет таких тестов((( да согласен, что язык отличается, но все таки нужно именно на scala автотестирование web сервисов, я думал что у кого нибудь здесь все таки имеется опыт, хотя бы в основах, ибо очень мало где можно это найти с конкретными примерами и на русском) ну или просто с конкретными примерами


(Igor) #7

@AbrosyElemoff в описании был вопрос про UI-тесты. Сейчас уже разговорпро web-сервисы. http://www.scalatest.org/quick_start - мы используем это. Там вроде документации хватает. Если веб-сервисы, то отправляйте запросы, проверяйте ответы: никакой магии.


(heartwilltell) #8

Чем обоснован выбор scala?


(Петров Денис) #9

Просто есть много чего интересного на scala к чему стоит присмотреться и что набирает популярность, тот же Scalatest, но к сожалению мало кто его использует


(sidelnikovmike) #10

То есть по сути отдать дань моде? :smile: В scala нету ничего такого особенного.


(Петров Денис) #11

А вы писали автотесты на scala чтобы быть уверенным что там ничего особенного нет?)


(heartwilltell) #12

В скала вообще нету ничего особенного. Это просто хороший язык. На скала есть много крутых проектов, но в этих проектах и мозги серьезные задействованы. Хочу развеять ваши иллюзии - скала очень сложна, а брать ее что бы писать в джава стиле это как стрелять из пушки по воробьям, потому не стоит долбится в модные тренды и писать на скала просто потому что говорят что это круто.


(sidelnikovmike) #13

Немного пробовал писать просто на scala какие-то примеры для изучения. Не сильно впечатлен. Про тесты ничего сказать не могу, но не думаю, что это всё сильно отличается от java библиотек для тестов.


(Петров Денис) #14

Никто и не говорит, что кто то хочет писать автотесты на scala только из за того, что это можно, я написал, что есть штуки на которые стоит обратить внимание, и в связи с этим мне бы на практике для примеров хотелось бы в общих чертах понять что к чему) вдруг есть опытные в этом деле люди


(asolntsev) #15

Привет!
Вот тут есть пример веб-приложения на Java и к нему автотестов и на Java, и на Scala:

А вот в этом виде эти тесты пишутся вживую (во второй части доклада, начиная примерно с 60 минут): https://youtu.be/8u6_hctdhqI


(Василий Чернов) #16

Мы как-то писали тесты на scala в bdd стиле… выходило что-то в таком духе https://gist.github.com/tjlee/7f5a09498b69b06d75c6 , но как-то впечатления были не очень. На самом деле проще использовать стандартные подходы java + selenium или тот же python.


Do different tests instead of repeating the same tests


(Dmytro Makhno) #17

@AbrosyElemoff, что все таки интересует?

Достаточно писал юай тестов под ScalaTest, и (минута рекламы) Марк вписал меня тут за минорный контрибут в xunit и CI процесс. Пробовал фреймворк для селениума Selenide вместе с ScalaTest, и рекомендую. @asolntsev, кинул валидный линк (и оказывается еще с моими предложениями по “сахеризации”) :slight_smile:

Из скала, что себя зарекомендовало для меня, (где-то в сравнении с Java 7, Java 8 облегчает жизнь):

  • Traits, можно компановать подобие страниц рабочими “примесями”. Например если у многих страниц есть header, то он примешивался. Это не создавало иерархии наследования PagesWithHeader и т.п. Было очень похоже на скальный Cake-pattern.
  • Implicit Webdriver, что-бы не тянуть нигде драйвер, и не писать его, что есть во многих фреймворках Java, его можно не явно держать в контексте, и компилятор сам будет передавать его.
  • Implicit Components, удобная форма записи, когда WebElement нужно обернуть в что-то Domain-specific. driver.findElement(By.id("element id")).asSidePanel.close(), ну или driver.findElement(By.id("element id")).closePanel(). Не шаман Java, но вроде такое нельзя было в ней, но достижимо в С# расширениями. Вообще при соглашении “локаторы одного типа”, можно писать ".class1 .class2".click(), где строка будет незаметно преобразована в локатор, засунут в вебдрайвер, преобразована в WebElelement.
  • Lambdas, которые есть в Scala даавно driver.findElements(By.id("element id")).filter(_.hasAttribute("ul")).foreach(_.click()).
  • waitDriver dsl. можно писать конструкции
withImplicit(5 seconds){
  doSomething()
}

//not None, with timeout
waitFor(action, 20 seconds) 

waifFor { 
  doSomething()
  driver.findElements('xxx').map(_.exists)
}

//Webdriver Native ExpectedConditions
waitFor(ExpectedConditions.elementToBeClickable(loc)).click()

Из подводных камней:

  • Любой из стилей написания требует понимания как ScalaTest дискаверит тесты, можно столкнутся что кода между “дескрайбами” выполняется на этапе дисковери.
  • Работа с selenium native PageObject (из org.openqa.selenium.support) на атрибутах, это адд (много лишнего писать приходится). В итоге выбросил, и получил более лаконичный код. Scala не очень любит аттрибуты.
  • В скалатест есть обвертка селениума, но она больше сделана, постольку поскольку, имхо. И я не видел чтобы она использовалась, и реальные мои попытки, не удавалось ее адоптировать. Нужно контрибутить, чтобы она стала живой, по тестам задумка классная. Вот с примерами WebBrowser, спасибо Марку, который держит скалатест документируемым.
  • Значительно дольше джавы компилируется. В случае имплицитов, нужно принаровиться понимать значение ошибок.

НО!!!
Пришлось отказаться, т.к. пришел новый тестировщик, и он просто не мог освоить Scala. Хотя код, реально было очень лаконичный, и поддерживаемый. :blush:
В итоге, просто вычитываю ScalaTest-ы за разработчиками и иногда “пописываю”, но уже совсем не Web-UI.


(Петров Денис) #18

ооо, очень ждал когда ответил человек, у которого есть большой опыт в этом) нужны именно примеры юай тестов под ScalaTest, например у нас есть сайт, там расположено много всяких элементов, начиная от поля поиска и заканчивая всякими чек боксами, выпадающими списка и прочее, так же у нас есть тест кейсы на проверку всего этого дела, например авторизироваться, нажать на поиск, найти компанию по инн, отфильтровать по параметру, и удостовериться что результат нужный нами получен, ничего не упало. Хотелось бы конкретные примеры именно как это реализовать и как с этим работать на scala, интересует все начиная от примеров и заканчивая полезной информацией где это можно почерпнуть, буду рад за вашу помощь!!!


(Василий Чернов) #19

А не лучше ли функциональные тесты реализовать через API, а не через GUI?


Do different tests instead of repeating the same tests


(Петров Денис) #20

хотелось бы именно через GUI , а в чем профит такого варианта?