Браво!

Браво!

Я быстро учусь)

это всё из-за семинаров

Всем добрых снов.

Привет всем. Скажите, тут кто-нибудь пишет UI-автотесты на groovy? geb, spock - слышали?

Привет всем. Скажите, тут кто-нибудь пишет UI-автотесты на groovy? geb, spock - слышали?

Слышали, видели

Слышали, видели

И как? )

Достаточно приятно)

Geb

Что-то нас таких немного.. Я, например, пользуюсь, и пока не замечаю особых минусов. Пытаюсь понять, почему он непопулярен в России.

Потому что зачем писать на груви?

А как много на грувях пишет?

Это язык который знают полтора ботана в мире

Потому что зачем писать на груви?

А зачем на нем не писать? ) Gradle на нем написан, например, и что плохого?

есть много языков на которых написано что то хорошее, это не делает язык самым лучшим

Ну скажу конкретно про Geb - на нем очень удобно писать тесты, и достаточно быстро. Кто-то же зачем-то разработал этот фрейворк. И, мне кажется, получилось достаточно удачно.)

А зачем на нем не писать? ) Gradle на нем написан, например, и что плохого?

Затем, что уже и так каждый разработчик знает по 2-3 мейнстримовых языка, и не видит смысл учить четвертый-пятый.

Всем, привет. #QA_question если бага воспроизводится время от времени как быть?

Искать зависимости

Что-то должно быть )

и фиксить

Не бывает, что "оно само". Обязательно какой-то триггер есть

Надо лучше искать

Ну скажу конкретно про Geb - на нем очень удобно писать тесты, и достаточно быстро. Кто-то же зачем-то разработал этот фрейворк. И, мне кажется, получилось достаточно удачно.)

Если рассматривать с точки зрения разработки - то возникает очень много коварных вопросов: каков цикл обновления этого груви, какое количество специалистов на рынке, насколько сложеня язык для понимания, разработки, отладки, есть ли IDE под него, какое сообщество у Geb фреймворка (вдруг он хипсторами разработан), какая история, какие намерения поддерживать это ПО в своременных трендах.

Всем, привет. #QA_question если бага воспроизводится время от времени как быть?

с подключением. Это называется "плавающий баг", наберитесь терпения и воспроизводите до седьмого пота, пока не получится :)

Надо лучше искать

Да вот проблема-то и в том, что всё это есть. Описание, условие, шаги... Но блин magic

если проблема не критичная - обвесить всё логами, чтобы при воспроизведении собралось больше информации, и катить как есть

Если рассматривать с точки зрения разработки - то возникает очень много коварных вопросов: каков цикл обновления этого груви, какое количество специалистов на рынке, насколько сложеня язык для понимания, разработки, отладки, есть ли IDE под него, какое сообщество у Geb фреймворка (вдруг он хипсторами разработан), какая история, какие намерения поддерживать это ПО в своременных трендах.

Могу ошибаться, конечно, но, по-моему, тут по всем вопросам ОК.

OK - это что за метрика? =)

Ну скажу конкретно про Geb - на нем очень удобно писать тесты, и достаточно быстро. Кто-то же зачем-то разработал этот фрейворк. И, мне кажется, получилось достаточно удачно.)

сделайте статью в телеграфе для далёких от груви

https://github.com/Codeception/Codeception - 2616 звезд https://github.com/geb/geb - 699 звезд по-моему, выбор очевиден, где ОК а где не ОК

Могу ошибаться, конечно, но, по-моему, тут по всем вопросам ОК.

http://www.tiobe.com/tiobe-index/ Груви на 37 месте

звёзды тоже не показатель =( количество их зависит от количества тех, кто использует конкретный язык

http://pypl.github.io/PYPL.html груви не замечен в топ 22

звёзды тоже не показатель =( количество их зависит от количества тех, кто использует конкретный язык

Так это и есть ровно тот нужный показатель! Количество тех, кто использует конкретный язык.

А я как раз пытаюсь понять, почему его не используют.)) Он намного проще, чем Java. Но Java при этом намного популярнее. Может, просто так повелось? И речь сейчас именно о тестировании, а не разработке.

Разработке автотестов ;)

Да, скорее всего так повелось, исторически сложилось.

> И речь сейчас именно о тестировании, а не разработке. Не сочтите за снобизм, но тут разработчики первичны, а тестирование идет на поводу. Будут разработчики массово переходить на груви - на нем и тесты станет писать модно.

Да вот проблема-то и в том, что всё это есть. Описание, условие, шаги... Но блин magic

как показывает практика - обязательно что то есть не магическое, какие то неочевидные проблемы по на сервере или еще что, в зависимости от проекта

И тут фактор "приятно писать" - он всего лишь один из десятков, и даже не на первом месте стоит. Важнее все то что я выше перечислил.

А я как раз пытаюсь понять, почему его не используют.)) Он намного проще, чем Java. Но Java при этом намного популярнее. Может, просто так повелось? И речь сейчас именно о тестировании, а не разработке.

А что на выходе имеется с этого framework?

как показывает практика - обязательно что то есть не магическое, какие то неочевидные проблемы по на сервере или еще что, в зависимости от проекта

Очень хотелось бы узнать..

Очень хотелось бы узнать..

Это не на ваш вопрос ответ ;)

Я к тому, что пойду разбираться )

как показывает практика - обязательно что то есть не магическое, какие то неочевидные проблемы по на сервере или еще что, в зависимости от проекта

Нашел) Вот только для разраба теперь пичалька будет(

Мы groovy юзали на одном проекте, правда для тестирования интеграции

Нашел) Вот только для разраба теперь пичалька будет(

это уже его пичалька)

Просто любопытно, что в некоторых компаниях, где приложение написано на php, тесты на него пишут все равно на java.) потому что так модно )

У джавы экосистема написания тестов гораздо мощнее чем у пхп, вот и пишут.

Нашел) Вот только для разраба теперь пичалька будет(

Расскажи же! )

Проект может быть и на Java написан, а тесты на vbs)

Но в нашей компании, к примеру, мы специально подбираем автоматизиаторов под наш язык разработки, чтобы уменьшать bus factor.

Но в нашей компании, к примеру, мы специально подбираем автоматизиаторов под наш язык разработки, чтобы уменьшать bus factor.

Что такое "bus factor"? ?

https://ru.wikipedia.org/wiki/%D0%A4%D0%B0%D0%BA%D1%82%D0%BE%D1%80_%D0%B0%D0%B2%D1%82%D0%BE%D0%B1%D1%83%D1%81%D0%B0

Да уж, кто вообще выдумал этот миф, что нужно автоматизировать на том же языке, на котором написан сам продукт

Что значит "нужно"? Так удобнее.

У нас разработчики пишут тесты вместе с QA в единой среде.

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

Это быстрее, понятнее, эффективнее, меньше затрат, если что то тесты легко отлаживать т.к. есть экспертиза, можно дописывать плагины. Плюсов полно.

Наоборот , QA поленились выбрать язык и теперь пишут на одном языке с разработкой

ERROR: S client not available

зачем, если есть python?!

А что QA хотят на себя навешивать тройную нагрузку по разработке и ответственности за тесты? :)

Хотя, может у вас дикая ситуация, фирма решила сыкономить на нормальном, и поэтому пишут на фри софте, ТОЛЬКО потому что а) бесплатно б) так делает разработка в) (самый любимый) так исторически сложилось

Не знаю - не знаю.. Мои разработчики (java) с удовольствием подхватили тесты на groovy, у них с эим вообще проблем не возникло, среда разработки одна. Так что Bus factor (спасибо за новый термин) у нас в порядке.)

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

Предлагаю перестать набрасывать. Если в компании все начнут писать автотесты на чём им угодно, разработка и тестирование превратятся в треш.

А причём тут тесты тестировщиков и код разработки?

каким образом вообще это связано?

Так это же просто классика - 2-3 разработчика с удовольствием подхватывают новую модную технологию XxX, пишут пишут на ней тесты, потом другие начинают писать на x_x_x_2, пишут на ней тесты, в результате через пару лет имеем адовый зоопарк технологий на проекте, невозможность разобраться во всем этом винегрете, кучи багов и бесконечные письма менеджеров.

А потом половина команды увольняется и появляется магический код, который "никто не знает как он работает, писали наши деды еще"

А причём тут тесты тестировщиков и код разработки?

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

А причём тут тесты тестировщиков и код разработки?

Это одно и то же. Тесты суть часть кода проекта.

Это одно и то же. Тесты суть часть кода проекта.

Если это unit или intagration тесты, только

Нет. Все тесты.

Нет. Все тесты.

как же, можно писать на ASM саму прогу, а тесты гонять на vbs

и где не правильно?)

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

Это правильно.

Но в случае java/php/groovy это не так.

Павел абсолютно прав по обоим вопросам. Автотесты - часть проекта. Более того, часть реестра поставки.

И по второму вопросу тоже. Вторая задача операционного менеджмента - уменьшение вариаций.

часть поставки ? речь о заказной разработке ?

Павел абсолютно прав по обоим вопросам. Автотесты - часть проекта. Более того, часть реестра поставки.

поставки кому и куда? часть проекта, как единицы всей, но она не обязана входжить в сам проект, она же его тестирует

часть поставки ? речь о заказной разработке ?

Да пофиг. Внешней, внутренней.

Зачем и для чего?

Просто, когда вы стартуете проект, вы должны договориться, что вы поставляете.

Зачем и для чего?

в чем плюсы раздельных я зыков?:

или это так вы раньше просто работали а теперь проэцируете, что так и должно быть?)

а если автотесты используются только для понижения количества регрессионных дефектов и конечному заказчику нет дела до того, каким это образом достигнуто, то тогда что ? То же часть поставки ?

а если автотесты используются только для понижения количества регрессионных дефектов и конечному заказчику нет дела до того, каким это образом достигнуто, то тогда что ? То же часть поставки ?

Да.