testomat.io управление авто тестамиСидит программист глубоко в отладке.
Подходит сынишка:
— Папа, почему солнышко каждый день встает на востоке, а садится на западе?
— Ты это проверял?
— Проверял.
— Хорошо проверял?
— Хорошо.
— Работает?
— Работает.
— Каждый день работает?
— Да, каждый день.
— Тогда ради бога, сынок, ничего не трогай, ничего не меняй!!!
Работает - не трожь, не мой подход 
Рано или поздно с новой фичей - отвалится…
Ну тут не тот случай. Ты же не будешь допиливать кхм maven или что-то вокруг него. Я думаю никакого профита это не принесет, только если это действительно не будет удобнее для тебя и твоих коллег.
1 лайк
За N лет работы с maven ни разу не встречал чего-либо, чего бы мне не хватало для решения automation задач. Более того, с годами у вас наверняка останутся какие-то шаблоны, которые вы будете переиспользовать на новых проектах. Создаете архетип с минимально необходимой конфигурацией, и вперед. При этом, никаких проблем и потребностей перехода на gradle не возникнет.
Чисто любопытства ради, при наличии времени и желания, на стартующем с нуля проекте, можно было бы поиграться с gradle. А так, весьма сомнительная затея.
1 лайк
Ну, это то же самое, что бухгалтеры в своё время считали, что компьютеры им не нужны. А ковбоям не нужны были автомобили. А крестьянам картошка.
Я знаю людей, которые до сих пор используют ant и уверены, что ни maven, ни gradle им нафиг не сдался.
1 лайк
Я тоже могу привести аналогию. Что же Selenide до сих пор на Java 7 завис? Хотя 8-ке то 2+ года, а в сентябре будет первый релиз 9ки… Дальше развивать мысль стоит? Или в ход пойдут популярные рассказы о пожизненном саппорте legacy динозавров / строгих company policy / широком комьюнити сторонников старины?
У каждого своя история. Вы не видите весомых причин переходить на 8-ку, другие - на gradle. 
Вот собственно и все.
Так это совсем другая история. Selenide - это библиотека, которую используют другие люди. Я просто опасаюсь, что многие из них сидят на семёрке, и поэтому переходить на восьмёрку нельзя. Только поэтому.
Open-source на то и open-source, что автор волен делать то, что пожелает, без каких-либо обязательств. Несомненно, есть определенные морально-этические нормы, годами накопленный уровень уважения, лайков, звезд и т.п. Но трястись из-за того “вечного” сегмента legacy проектов, которые до сих пор сидят на <=7 java - полный нонсенс. Всегда найдутся недовольные, этого не избежать. Но жизнь идет, технологии развиваются, и на тот процент “отпавших” из-за перевода на новую версию java найдется такой же или еще больший процент “прибывших”. Так что никакая это не другая история. С таким подходом можно вечно сидеть на 7й java. А потом через пару лет автор какой-нибудь новой модной библиотеки будет смеяться и проводить аналогии с условным selenide, так же, как вы делаете с ant, maven и gradle, либо бухгалтерами и ковбоями.
1 лайк
Мысль интересная, но не улавливаю логики. Откуда вдруг возьмётся процент прибывших? Никто не начнёт использовать Selenide только потому, что она компилируется только с Java 8. Тут никакой связи. Что бы они ни использовали - Java 7 или Java 8 - им лучше всего подойдёт библиотека, которая поддерживает и то, и другое.
А Selenide не переходит на Java 8 не потому, что я трясусь, а потому, что нет необходимости. Я активно использую Java 8 в работе и знаю её возможности. И ни одна из них пока не нужна в Selenide. Поэтому просто нет смысла.
А почему же вы тогда так уверены в том, что у пользователей maven должна вдруг появиться резкая необходимость перехода на gradle? Я пока не увидел ни одного весомого аргумента в пользу gradle в контексте автоматизации.
А я этого и не говорил.
Я говорю о том, что есть огромная разница между “я хорошо знаю, что там, и мне это не нужно” и “точно не знаю, что там, но мне это не нужно, мне и так хорошо”.
P.S. преимущества у градла всё-таки есть и в контексте автоматизации тестирования - я их в первом комментарии описал.
А можно эти пункты как-то поподробнее обосновать? Не пробовал Gradle, пока только с Maven’ом “развлекаюсь” и не совсем понимаю, чем он может быть нам лучше в рамках нашего тестирования.
Интересно понять, стоит ли его пробовать в будущих проектах вместо maven’а или пока и так сойдет и лучше не тратить время на это и заниматься самим тестированием.
Во тут я расписывал подробнее:
https://plus.google.com/+AndreiSolntsev/posts/E4VBf7iUMSG
Например:
Элементарно, команда “mvn help:help” выкачивает 6 MB зависимостей.
Чтобы показать, сцуко, свой собственный help!
А вообще я ведь изначально привёл очень понятный пример, после которого не должно остаться вопросов. В Gradle делаешь таск в три строчки:
task tests-chrome(type: Test) {
systemProperties['selenide.browser'] = 'chrome'
}
В мавене то же самое - целый профайл с сопутствующей тонной XML.
Ни один из приведенных 3х пунктов не аргументирует, почему gradle лучше для автоматизации.
- Причем здесь enterprise / open-source и нестандартная maven / gradle структура?
- Какие еще maven плагины мне надо будет писать для автоматизации тестирования ПО?
- По поводу скачиваемого объема - вообще не аргумент. Сколько уже лет работаю, ни разу не сталкивался с проблемами отсутствия свободного места по вине maven. Не спорю, бывают исключения, когда место действительно критично, но не для web’a так точно.
- Тут же касательно команд - вообще абсурд. Вы часто для автоматизации тестирования пользуетесь чем-то, кроме
mvn clean test / site? Я вот нечасто. В остальном, официальные сайты плагинов, как правило, дают более чем исчерпывающие инструкции по применению.
Ага, в IDEA наверное очень тяжело написать пару букв + TAB, чтобы у вас сработало автозаполнение любой нужной секции pom?
Чтобы написать полнофункциональную красивую обертку над WebDriver / WebElement (без излишеств) достаточно порядка 6-8-ми зависимостей и 2-3х плагинов. Это ~100 строк xml (с репортингом еще + ~20), из которых 60% либо автоматически сгенерированны IDE, либо написаны с минимальными усилиями при помощи автокомплита / копипаста. Так что давайте не будем вводить читателей в заблуждение о невероятной сложности конфигурации automation проекта при помощи maven. 
2 лайка
Перешел с Мавена на Грейдл пару месяцев назад.
Основные причины:
- Депенденси конфигурация у Грейдла в одну строчку, что делает более читабельным конфиг файл, по сравнению с Мавеном.
- Создание кастомных тасков быстро и удобно. Более мощный функционал.
- Новый тренд - решил попробовать. Все что было реализовано на Мавене легко переписал в Грейдле. Опять таки, конфиг файл легко читабельный. Про Мавен в этом плане промолчу…
В завершение скажу одно - нету никакого превосходства или недостаток в Автоматизированном Тестировании что у Мавена что у Грейдла. Все равно тестировщикам не нужен тот крутой функционал, в котором можно почувствовать разницу. Но с Грейдлом веселее
4 лайка
Тот факт, что говнокод можно нагенерировать и накопипастить, не делает его менее говнокодистым. Право слово, смешно это слышать.
Все остальные пункты относились к той статье, там был свой контекст. Насколько они актуальны для автоматизаторов - пусть судят сами автоматизаторы. Для кого-то, может, и неактуальны. А для кого-то актуальны. Автоматизаторы-то тоже небось очень разные бывают. Я всего лишь рассказал о том, что актуально для меня.
К чему это вообще было? Какое отношение имеет автокоплит структуры pom-файла из IDE, или копирование dependencies / plugins из официальных источников к говнокоду? Или лишь бы что-то ляпнуть?
Автоматизаторы и судят собственно. И как уже намекали выше: для автоматизации что maven, что gradle - одного поля ягоды. На том предлагаю и закончить сей бесполезный спор.
1 лайк
Собственно, я никакого спора и не начинал.
А вы вот-то пытаетесь всем навязать своё мнение. Выше были и другие намёки так-то…
P.S. Насчёт говнокода: я вовсе не пытался никого этим обидеть. Я имел в виду, что любой сгенерированный код по определению лишний. То же относится к сгенерированным летописи/сеттерам, сгенерированному javadoc и т.д. Раз его смог написать компьютер, значит, его можно было бы не писать вовсе. Ну, это такой слегка философский вопрос…
Помню, осваивался с Gradle, потому что смежная команда перешла на него.
Понравился, намного интереснее, чем Maven, намного понятнее и намного гибче.
- конфиг Gradle это полноценный код на Groovy
- конфиг получается компактный и леко читаемый
- его можно составить из нескольких файлов
- параметры внутри конфига можно определять-переопределять динамически
- цели тоже можно формировать динамически
Можно дописать абсолютно любой функционал для вашего окружения/приложения/железа
3 лайка
А тонкую аналогию с бухгалтерами и ковбоями конечно же не вы провели? Это, прямо скажем, целый булыжник в чужой огород. Вот мне и захотелось понять, а насколько же maven технологически отстал от gradle. Но, как в последствии выяснилось, все же у обоих лагерей есть как собственные компьютеры, так и автомобили. Возможно одни устройства выглядят немного современнее и компактнее других, но вот только со своими повседневными обязанностями оба лагеря справляются все так же эффективно.
Заметьте, я ни слова не написал о том, что якобы gradle - говно, и его не стоит использовать. Я подчеркнул лишь тот факт, что с задачами автоматизации maven прекрасно справляется, причем с минимальными усилиями. А вопрос условного улучшения читабельности весьма относителен, т.к. “на вкус и цвет” сами знаете что…