Ни один из приведенных 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.
Депенденси конфигурация у Грейдла в одну строчку, что делает более читабельным конфиг файл, по сравнению с Мавеном.
Создание кастомных тасков быстро и удобно. Более мощный функционал.
Новый тренд - решил попробовать. Все что было реализовано на Мавене легко переписал в Грейдле. Опять таки, конфиг файл легко читабельный. Про Мавен в этом плане промолчу…
В завершение скажу одно - нету никакого превосходства или недостаток в Автоматизированном Тестировании что у Мавена что у Грейдла. Все равно тестировщикам не нужен тот крутой функционал, в котором можно почувствовать разницу. Но с Грейдлом веселее
Тот факт, что говнокод можно нагенерировать и накопипастить, не делает его менее говнокодистым. Право слово, смешно это слышать.
Все остальные пункты относились к той статье, там был свой контекст. Насколько они актуальны для автоматизаторов - пусть судят сами автоматизаторы. Для кого-то, может, и неактуальны. А для кого-то актуальны. Автоматизаторы-то тоже небось очень разные бывают. Я всего лишь рассказал о том, что актуально для меня.
К чему это вообще было? Какое отношение имеет автокоплит структуры pom-файла из IDE, или копирование dependencies / plugins из официальных источников к говнокоду? Или лишь бы что-то ляпнуть?
Автоматизаторы и судят собственно. И как уже намекали выше: для автоматизации что maven, что gradle - одного поля ягоды. На том предлагаю и закончить сей бесполезный спор.
А вы вот-то пытаетесь всем навязать своё мнение. Выше были и другие намёки так-то…
P.S. Насчёт говнокода: я вовсе не пытался никого этим обидеть. Я имел в виду, что любой сгенерированный код по определению лишний. То же относится к сгенерированным летописи/сеттерам, сгенерированному javadoc и т.д. Раз его смог написать компьютер, значит, его можно было бы не писать вовсе. Ну, это такой слегка философский вопрос…
А тонкую аналогию с бухгалтерами и ковбоями конечно же не вы провели? Это, прямо скажем, целый булыжник в чужой огород. Вот мне и захотелось понять, а насколько же maven технологически отстал от gradle. Но, как в последствии выяснилось, все же у обоих лагерей есть как собственные компьютеры, так и автомобили. Возможно одни устройства выглядят немного современнее и компактнее других, но вот только со своими повседневными обязанностями оба лагеря справляются все так же эффективно.
Заметьте, я ни слова не написал о том, что якобы gradle - говно, и его не стоит использовать. Я подчеркнул лишь тот факт, что с задачами автоматизации maven прекрасно справляется, причем с минимальными усилиями. А вопрос условного улучшения читабельности весьма относителен, т.к. “на вкус и цвет” сами знаете что…
testomat.io управление авто тестами
