Или например критически относится к чужому мнению, особенно в форме доклада)

его сделали на 10-15 лет позже двух остальных и уделили внимание типичным проблемам.
Ну и на сегодня он наиболее мейнстримовый и значительно активнее других развивается.

переформулирую вопрос есть ли что-то в JUnit5 без чего действительно порой сложно жить и чего нет в TestNG?

а Вы сами слушали этот доклад?

я бы специально не переходил. Если проект в фазе поддержки то точно нет. По слухам с недавних пор можно запускать одним раннером JUnit5 + TestNG, что даёт возможность писать в старом проекте новые тесты на JUnit5, не  переписывая всё остальное.

C JUnit4 + JUnit5 - это работает хорошо и просто, сам проверял.

да ничего нет такого специального

Отрывок посмотрел про testng, и в целом с ним согласен

У всех трёх фреймворков разные методы расширения. Если работать со специальными технологиями (типа Spring, Kafka, Reactive) - то существуют уже написанные расширения, которые помогают легче и эффективнее тестировать данную технологию. И тогда, если для условного Kafka - написаны расширения для JUnit4, но нет для TestNG и JUnit5 - то нечего думать, надо брать JUnit4

Но принципы везде аналогичные, разница в имплементации.

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

как минимум можно посмотреть что нужно и написать самому)

ну и в testcontainers что то есть

познавательное видео, спасибо)

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

Нет, специально переходить не стоит.

мало того, "фичи testng", про которые Андрей написал, что они зло, есть и в junit5 тоже :)

(кроме, пожалуй, конфигурационных файлов, которые непонятно за что получили статус зла, их в junit нет, и это не очень удобно)

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