LINUX.ORG.RU

Выбор JVM-ЯП для тестового фреймворка

 , , , ,


0

2

Всем доброго времени суток!
Дано:
- Полуготовый тестовый фреймворк на Java+TestNG+Selenium/Selenide с почти сформированной тестовой архитектурой;
- 2 QA-инженера со знанием JavaCore и слабым пониманием проектирования ПО;
- большая команда Java/Groovy разработчиков;
- большая потребность в инженерах по тестированию, т.е. возможность прибытия новичков;
Проблема:
- низкая скорость написания тестов;
- относительная сложность написания тестов (большая сложная система);
Варианты решения:
- поиск более легкого высокоуровневого языка под JVM с возможностью безболезненной интеграции с существующими тестами на Java
-- варианты языков: Clojure, Groovy, Kotlin.
Clojure - потому что наслышан про языки из lisp-семейства и про возможность легкого метапрограммирования и лёгкого создания DSL на языках этого семейства. Ну это не все фичи конечно же. Ещё плюсом может быть иммутабельность по дефолту и прочие возможности функциональщины. Сложность может представлять только не совсем привычный синтаксис языка, но я думаю это не такая уж большая проблема, т.к. эти особенности синтаксиса вполне можно объяснить за одну небольшую лекцию/daily + мне кажется, что поначалу может быть непривычно и сложно, но потом это окупится с лихвой (при проектировании тестов/фреймворка), но, возможно, я и не прав...
Groovy - история та же (возможность легкого метапрограммирования и лёгкого создания DSL), но синтаксис проще, но и есть подозрение, что язык предоставляет слишком большое количество развесистых граблей.
Kotlin - выглядит как самый вменяемый кандидат из всех, но лично я знаком с ним меньше всего. Радует то, что:
«В мае 2017 года компания Google сообщила, что инструменты языка Kotlin, основанные на JetBrains IDE, будут по стандарту включены в Android Studio 3.0 — официальный инструмент разработки для ОС Android.

На Google I/O 2019 было объявлено, что язык программирования Kotlin стал приоритетным в разработке под Android.»
и используется так же и для тестирования Android-приложений (тоже важный фактор).

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

QA макаки могут осилить только Gherkin, пускай пишут фичафайлы на нем, а шаги разрабы на чем угодно.

Я бы взял Groovy в связке со SpockFramework, выкинув TestNG к чертям. Там синтаксис простой, DSL тоже можно накидать.

P.S. Kotlin недоязык, продвигаемый гуглом только потому, что других вариантов быть в ногу со временем, а не писать на старой версии явы, на андроиде нет.

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)

Clojure - потому что наслышан про языки из lisp-семейства

Кложура это кложура, а не CL.

про возможность легкого метапрограммирования

Оно тут ограничено (хотя и вполне достаточно). За навороченным метапрограммированием это к Racket. В кложуре упор на ФП, parallelism и concurrency.

2 QA-инженера со знанием JavaCore и слабым пониманием проектирования ПО

У кложи относительно низкий порог вхождения, пойдёт.

Hertz ★★★★★ ()

Kotlin - выглядит как самый вменяемый кандидат из всех, но лично я знаком с ним меньше всего.

Вроде он позаимствовал у groovy создания декларативных DSL, гугли типобезопасные строители.

anonymous ()
Ответ на: комментарий от Deleted

Я бы взял Groovy в связке

Не кодил на груви но просто интересно, если что-то пойдет не так, он нормальные(читаемые) стектрейсы генерирует? Я просто помню что раньше с интерпретируемыми языками на JVM были у меня проблемы.

anonymous ()

Я бы java взял. 100%

лёгкая интеграция и интероперабельность с джавой, существующими тестами, джавийными библиотеками

Остальное - неопытные тестописатели, возможность легкого метапрограммирования и лёгкого создания DSL и уж тем более, иммутабельность по дефолту, лол - внимания не заслуживает. Заодно разрабов потом будет где взять, если сильно припечёт

anonymous ()
Ответ на: комментарий от anonymous

Ну груви добавляет шелухи в стек, это да. Читаемо ли? Вопрос привычки, имхо. Ява с лямбдами и стримами тоже нихера не ясные стектрейсы показывает.

Deleted ()
Ответ на: комментарий от anonymous

String? - null-safety that's money! Ну и еще Extension functions

Это я про Kotlin писал, чем он лучше жабы в реальных кейсах. Тот же DSL довольно опасный инструмент, главное не пересолить.

anonymous ()

Пробуйте в BDD тесты если получится выделить инженера на реализацию глаголов и фикстур, может выйти синергия по итогу. Хорошие QA и не обязанны в автоматизацию уметь, а тем более в проектирование ПО, низковат уровень. Либо берите с рынка чисто автоматизатора, он сам расскажет на чём ему удобней будет, а они пусть кейсы на натуральном пишут или в том же кукумбере.

pon4ik ★★★★★ ()
Ответ на: комментарий от Hertz

Ну и ещё мне показалось, что со средствами разработки для кожуры - не очень... Но, возможно, это просто потому что я не туда и не то смотрел... Emacs+CIDER - показался слишком заумным и у меня при попытке использовать CIDER летели все время какие-то совсем уж странные ошибки, а при гуглении этих ошибок натыкался на обсуждения на гитхабе, исходя из которого создаётся впечатление, что поддержкой этого плагина занимаются 2,5 школьника, что уж как-то совсем несерьёзно... Nightcode - выглядит интересно, но сыровато. Cursive - тоже в упор не заводится... Сплошные exception'ы при запуске. В sublime тоже какие-то пляски с бубном были... Уже почти готов был сдаться, но вроде Atom более-менее нормально поддерживает Clojure, хотя я ещё толком не смотрел конечно. Если и тут возникнут какие-то такие грабли на взлёте, то тогда даже не знаю... Язык-то может и хороший, но как с ним работать без плясок с бубном?) И если мне, например, терпения, усидчивости и любопытства хватит, то другим совсем необязательно.

Eid010n ()
Ответ на: комментарий от Eid010n

LightTable пробовали? Специально с упором на кложу пилится. Мне с головой хватает Emacs+CIDER. Вернее, хватало, от кложи отошёл и руки не доходят вернуться. Глюки с сидром периодически возникали, но фиксились как откатом взад, так и обновлениями. Серьёзных конфликтов не вспоминается. С Курсивом полный порядок был, кроме прожорливости IDEA. Да и сама кложа этим и убила. Вывод сделал, что хороша она подо что-то довольно крупное, а под мелочёвку лучше заюзать схемы (Racket например).

Hertz ★★★★★ ()
Ответ на: комментарий от Hertz

LightTable

спасибо! попробую

подо что-то довольно крупное

например? MachineLearning? (вроде слышал, что ее успешно там используют (где-то даже был подкаст с рассказом про зарубежную контору))

Eid010n ()

Мой опыт написания автотестов говорит о том, что их надо проектировать как и основное ПО. То есть не «сделал базовый слой-фреймворк-запускалку» а потом сверху неё тесты фигачишь линейно, а именно проектировать, как и основное приложение.

Иначе вы можете получить пачку автотестов (от 100 и выше), которые надо будет все изменить при небольших изменениях в тестируемой программе. Про сами ЯП ничего не скажу - мы всегда писали на Java. Главное - это не отпускать работу на самотёк.

Qasta ()

Тебе выше уже ответили, что главное - проектирование автотестов. И ещё подсчёт ROI от их внедрения, иначе автоматизация будет съедать всё время автоматчиков с плохим результатом.

На чём писать варианта три: 1) Если надо быстро, то ищите Automation Engineer с рынка. Продвинутый сам возьмёт кложуру, тут стрельнет фича загрузки файла (DSL или plain clojure с либой для actions, как пойдёт) в образ (часть функционала test framework уже есть в языке). Новички в массе не осиливают, это по опыту. 2) Если надо не очень быстро, то берите новичков под присмотром старшего разработчика и пишите на том, по чему смогут подсказывать знающие товарищи (Java/Groovy) 3) Есть вариант, когда framework и actions пилят разработчики, а кубики собирают нубы. Но тут нужен сильный тех. лид, который не даст развести кашу из кубиков и будет делать всё композабельным. Новички могут писать скрипты тогда хоть в XML (такой цирк тоже был и неплохо работал, кстати)

anonymous ()
Ответ на: комментарий от Eid010n

например?

Любой достаточно большой проект, которому потребуется многопоток.

MachineLearning?

Простите, не разбираюсь в этой отрасли. Пробегали слухи, что кложа там используется немножко, но львиная доля всё равно у питона.

Hertz ★★★★★ ()

Google - это обычный Candyland, а не серьезная компания.

Я понимаю, что сейчас в меня полетят гнилые помидоры, однако, а что производит Google?

Ну кроме гигантского «мыльного пузыря»?

Станки? Электронику? Одежду? Еду?

Да, удобны поисковик, электронная почта и помойка-видеохранилище.

Но сейчас это уже не является чем-то особенным, как было 20 и даже 10 лет назад.

Без бугагашечек с тыртюба кулькакер прожить сможет, несмотря на «ломку».

А вот без нямки любой кульхацкер не проживёт.

Так, что «крах доткомов» 2 не за горами.

https://ru.wikipedia.org/wiki/Пузырь_доткомов

----

Теперь по технологиям.

GWT - кирдык. «Подберёт» GWT либо Apache либо Embarcadero (Sencha), либо кто-то ещё.

Guice - симпатичный фреймворк, который больше года не обновлялся. Однако, не смог вытеснить Spring (привет Apache Groovy). iReport - это тоже сейчас, как правило, с поддержкой Groovy.

Eclipse - Oracle и IBM и так чувствуют себя неплохо. Особенно (таки-да!) в финансовой сфере. А также на правительственных заказах.

----

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

(C)

IT должно помогать _производительным_ сферам экономики.

А для кульхацкеров IT - это _самоцель_, а не подспорье.

Bioreactor ★★★★★ ()
Последнее исправление: Bioreactor (всего исправлений: 2)
Ответ на: комментарий от Qasta

Спасибо! Очень ценное замечание! Может, сможете подсказать, пожалуйста, по архитектуре автотестов какие-то основные моменты? Как их грамотно организовать? Какие паттерны/фреймворки лучше всего использовать? В принципе насколько я понял пригодятся PageObject’ы (который будет повторять структуру, иерархию UI тестируемого ПО), DataProvider’ы (для формирования/скармливания тестовых данных непосредственно в сами тесты), сами тесты наверное было бы неплохо писать в виде наборов тест-сьюитов и далее код в виде эдаких тест-кейсов (возможно, здесь хорошо подойдёт какой-нибудь BDD фреймворк для этого). В общем решили всё-таки использовать котлин, там вроде в качестве BDD-фреймворка есть Kirk. Что скажете?

Eid010n ()
Ответ на: комментарий от Eid010n

Может, сможете подсказать, пожалуйста, по архитектуре автотестов какие-то основные моменты?

Никаких особенных моментов нет: как только ты понимаешь, что начал писать большое приложение, то вопрос условно отпадает (проектирование ничем не отличается). Сразу скажу - не бойтесь глубокого рефакторинга, если поняли, что надо что-то переделать!

Как их грамотно организовать? Какие паттерны/фреймворки лучше всего использовать?

Мы использовали JUnit (плюс свой «runner»), т.к. с ним очень удобно работать из среды разработки. Здесь главное, чтобы осталась возможность работать с тестами (запустить один тест или один метод теста) из среды разработки - это очень, очень важно.

В принципе насколько я понял пригодятся PageObject’ы (который будет повторять структуру, иерархию UI тестируемого ПО), DataProvider’ы (для формирования/скармливания тестовых данных непосредственно в сами тесты), сами тесты наверное было бы неплохо писать в виде наборов тест-сьюитов и далее код в виде эдаких тест-кейсов (возможно, здесь хорошо подойдёт какой-нибудь BDD фреймворк для этого).

Тут напишу на правах ИМХО. 9 лет назад был один очень хороший доклад на тему автотестов - Alexandre Iline Rit 2010 Java Fxui. К сожалению, я видео не нашел - только слайды, но может Вас посетит удача...

Так вот: у тестирования GUI есть несколько очень важных аспектов:

1. Не делайте иерархию страниц (PageObject-ы и т.п.): в UI эффективным механизмом является композиция, а не наследование

2. Не повторяйте иерархию вашего разработанного ПО (мы же ведём речь о тестировании чёрного ящика?)

3. Для упрощения написания кода - пишите высокоуровневые «операторы». Например, раз у страницы есть «шапка», то создайте класс PageHeaderOperator, который позволит работать с этой шапкой (вызывать меню сайта, получать различные надписи и всё остальное). Если есть кнопка «логин» - сделайте LoginOperator, у которого будут методы login(user,password), logout(), status(). И так далее. Конечную сборку делайте уже только в самом тестовом методе.

4. Общие вещи можно и нужно вынести в суперкласс автотеста (например, можно создать AbstractAuthenticatedPageTst, который будет автоматом перед каждым тестом проверять, что пользователь залогинен и логиниться, если ещё нет). Большего в суперкласс я за свою практику так и не вынес :) У автотестов глубина иерархии сильно меньше в отличии от операторов.

В общем решили всё-таки использовать котлин, там вроде в качестве BDD-фреймворка есть Kirk. Что скажете?

Не смогу подсказать, т.к. котлином не пользуюсь. Вот что точно знаю - фреймворк и среда запуска вторичны, если решены задачи запуска на CI сервере и в IDE. Берите то, что знают ваши программисты/тест-автоматизаторы.

P.S. Приготовьтесь сразу быть готовым считать, сколько вы тратите на написание и поддержание автотестов и сколько при этом экономите. Экономика здесь очень важна. Ну и 100% покрытия автотестами я не видел никогда. Даже 60%-го.

Qasta ()
Последнее исправление: Qasta (всего исправлений: 1)
Ответ на: комментарий от Qasta

Спасибо огромное!

  1. Сможете, пожалуйста, более развернуто объяснить почему именно композиция? Или кинуть ссылкой где про это можно почитать более подробно? Т.е. концептуально вроде бы понятно (отношение «has a» вместо «is a»; факт того, что элементы UI являются частью других элементов, а не их наследниками…), но хотелось бы ещё посмотреть примеры.
Eid010n ()
Последнее исправление: Eid010n (всего исправлений: 1)
Ответ на: комментарий от Eid010n

Не за что :)

отношение «has a» вместо «is a»; факт того, что элементы UI являются частью других элементов, а не их наследниками

Кроме этого ничего другого и нет на самом деле. Но зато это очень сильно упрощает проектирование и поддержку - это могу подтвердить своим опытом (SOLID никто не отменял - он не просто так появился). Наверное, так как «операторы» в некотором виде олицетворяют собой высокоуровневый способ работы с интерфейсом (с блоками интерфейса), а сам интерфейс собирается «композицией», то и структура операторов должна быть аналогичной (но не обязательно «дублирующей полностью»). Но это всё вопросы «философские» :)

Qasta ()