Если maven - это каменный век, то gradle - это леденящий душу пи####, он условно "прост" ровно до того момента, как приходится делать что-то сложное, после чего все его косяки вылезают наружу.

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

Чтобы пользователь смог войти в систему кто-то информацию об этом пользователе должен добавить - это предусловия тестового сценария, т.е. bottom line здесь к примеру такой: должен войти администратор и добавить пользователя (назначить полномочия и т.п.), если мы начинаем говорить, что между тестовыми сценариями зависимостей быть не должно, то мы еще глубже залезаем в кроличью нору: теперь в тестовых сценариях нужно делать ветвления в духе: зайти, посмотреть есть ли пользователь или нет, если есть, то проверить полномочия, если нет, то создать. Вот ветвления в тестовых сценариях - это куда большее зло, чем зависимости между ними (Test NG, кстати, с зависимостями прекрасно справляется ).

Ну вот вы говорите про параллельность, интеграционные тесты... а "народ" считает что для интеграционных тестов TestNG предпочтительнее, типа: для unit-тестов пусть разработчики со своим JUnit (5) копошатся, а действительно "полезные" тесты мы будем делать на TestNG.

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



? А по факту такой креатив в сценарии сборки нафиг не нужен - если что-то поменяется (что происходит крайне редко) можно и руками поправить, однако вот из-за таких мисфич сценарий сборки более-менее крупного проекта ни человек прочесть не может нормально, ни среда разработки (у них же в самом начале были какие-то попытки разбор build.gradle в IDE затащить, а потом остановились на том, что с gradle среда разработки должна работать только через демон). При этом действительно нужных возможностей в gradle толком нет, ну вот пример: есть какой-то срез кода из СКВ, как программно понять какой он версии? В maven это делается универсально через help:effective-pom, а в gradle каждый лепит кто во что горазд. Точно также с релизным воркфлоу: в maven release plugin - это часть экосистемы, а в gradle - какая-то сторонняя поделка, которой пользуются два инвалида (здесь больше похоже релизы в проектах на gradle не принято делать). В maven вообще есть киллер-фича: можно плагины дергать без прописывания их в pom.xml, ее полезность просто зашкаливает, гредлу до нее еще расти и расти.