Вводная:
Есть большой, сложный и местами злобный проект на Python. Рассматривается вопрос его переноса на Java. Перенести код — тривиально и обсуждения не требует. Проблема в переносе тестов.

Проект реализует некоторый сетевой стек (не хочу пока называть, чтобы не давать разговору уйти в частности) и целевую логику над ним. Это не веб, не REST и тому подобное. Стек многоуровневый, громоздкий, со следами грубейших ошибок в проектировании и лихорадочных затыканий этих ошибок. Над ним бизнес-логика, тоже с нетривиальностями.

Тестирование на 99% сценарное: запускается один или несколько рабочих процессов, каждый из которых включает некоторый поддиапазон полного набора уровней реализации, с моканием верхних уровней (выше того, что тестирует конкретный тест), нижних (как минимум, заменяется реализация сетевого транспорта, как TCP, на свою), внешних сущностей (БД, авторизатор, и тому подобное). Процесс, управляющий тестом, проверяет все необходимые события (типа: U1 связался с M1, тот уточнил авторизацию у AA и метод связи у AB, передал сигнал на M2, тот передал на U2, и всё это уложилось в 5 секунд и в правильном порядке). Кроме того, используются инверсии, которые представляют собой модификации окружения или входных воздействий в тесте, так, чтобы результат теста не был достигнут. В инверсии проверяется собственно факт неудовлетворения теста, а в некоторых и конкретный механизм (например, какое исключение было сгенерировано). Их тоже надо перенести. Сводка результатов запуска тестов собирается в выхлоп под JUnit, по ней строятся графики и отчёт для Jenkins.

Комментарии типа «вы всё неправильно сделали», «надо всё уложить на юнит-тестирование» и т.д. будут неуместны: во-первых, объём и легаси, во-вторых, «долго объяснять» (tm), но это единственный реально сработавший метод, и его надо продолжать.

Структура реализации тестов на Python банальна:
— Основной код, подключаемый через стандартное указание пути поиска
— Модули поддержки тестирования, аналогично
— Код управляющего процесса, в test.py
— Код вспомогательных процессов, где нужен

запускается через стандартный пускатель с указанием подгруппы тестов, или напрямую. Python сам разбирается, откуда брать код, когда и куда «компилировать» *.pyc, и так далее.

А вот перенос на Java вызывает проблемы, начиная с того, что пути к участникам требуют заточки под конкретное средство управления сборкой, перед запуском теста надо явно перемейкать все *.class (или пнуть сборку jarʼа, если это лучше), настроить правильно classpath, возможно, ещё что-то уточнить.

Варианты выкрутиться своими силами в обход стандартных средств — очевидны. Написать и отладить управляющее средство (на том же Python), которое будет звать make нужного формата, подкладывать classpath, и так далее — дело двух дней с перекурами. Но это будет самостоятельная реализация заката солнца, со всеми вытекающими (если что меняется — подтачивать самим). И пускать можно будет только из комстроки и разбирать отчёты там же.

Собственно целевой пакет вопросов:
1. Что из набора Ant/Maven/Gradle/etc. поддерживает такие методы тестирования?
2. Какие грабли встретятся на таком пути, и как их обходить?
3. Как это сынтегрировать с IDE (и с каким), чтобы получить возможность запускать тесты кнопкой в нём, чтобы по логу тестов давало ссылку на конкретную строку кода, и прочие типичные плюшки IDE? И чтобы его точно так же можно было запускать под CI (Jenkins) и получать отчёты об исполнении?