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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я бы java взял. 100%

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

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

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

String? - null-safety that's money! Ну и еще Extension functions. Все остальное оно как бы да, интересно, но опасно в неумелых руках. Вот эти бы две вщеи в жабу перенести...

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

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

А как к вам кью эй балбесом пойти?

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

низкая скорость написания тестов

Есть какие-то основания считать, что это следствие используемого языка?

как в джаве что-то писать без хорошего знания/понимания ООП и паттернов проектирования?

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

терпения, усидчивости и любопытства

для настройки редактора/IDE

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

LightTable

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

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

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

как в джаве что-то писать без хорошего знания/понимания ООП и паттернов проектирования?

Как и в любом другом в таком случае - без ооп и паттернов.

Для тестов и интероперабельности бери груви и не парься.

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

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

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

Emacs+CIDER вообще отлично у меня работает. Cursive использует товарищ на работе. Тоже норм.

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

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

Для замены Selenium запилили на clojure https://github.com/igrishaev/etaoin.

И ещё подсчёт ROI от их внедрения

Для UI-тестов ROI → ∞. Лучше уж без них, гемора много толку мало.

спасибо!

Тебе выше уже ответили

как-будто я где-то спорил)

например?

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

MachineLearning?

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

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 - это _самоцель_, а не подспорье.

выкинув TestNG к чертям

почему? чем он плох?

Да он не плох, вообщем-то, даже лучше JUnit’a, но в Споке приятнее делать читаемые тесты в стиле Given-When-Then с минимумом визуального мусора.

понятно, спасибо!

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

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

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

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

Мы использовали 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%-го.

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

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

Не за что :)

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

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