Вводная:
Есть большой, сложный и местами злобный проект на 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) и получать отчёты об исполнении?

Здравствуйте, netch80, Вы писали:

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

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

Я тут недавно видос смотрел, вроде похоже на вашу проблему: Side Effect Injection

Если будешь переписывать, перепиши с использованием Spring и dependency injection. (а ещё лучше сразу Spring Boot)
В это случае тестирование будет тривиально — создаются моки для нужных уровней и на лету подключаются через профили.

Ещё вариант ничего не мокать, а тестировать в Докере

Здравствуйте, netch80, Вы писали:


N>Тестирование на 99% сценарное: запускается один или несколько рабочих процессов, каждый из которых включает некоторый поддиапазон полного набора уровней реализации, с моканием верхних уровней (выше того, что тестирует конкретный тест), нижних (как минимум, заменяется реализация сетевого транспорта, как TCP, на свою), внешних сущностей (БД, авторизатор, и тому подобное).

ну и прекрасно, вам тогда вообще не нужно переводить тесты с питона на яву

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

Совсем необязательно, чтобы запуск тестов управлял сборкой. Сделайте сборку автономно, а затем запускайте тесты. В качестве инструмента сборки рекомендую maven как самое популярное, и как результат с наибольшими шансами получить помощь в случае проблем.

Здравствуйте, netch80, Вы писали:

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

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

N>Собственно целевой пакет вопросов:
N>1. Что из набора Ant/Maven/Gradle/etc. поддерживает такие методы тестирования?
Лучше gradle, оно сложнее но гибче, мавен проще но ограниченнее. Ant забудь — это древнее говно мамонта.

N>2. Какие грабли встретятся на таком пути, и как их обходить?
Тестирование в java само по себе отлажено хорошо. Грабли у вас если и будут то только от недостатка знаний.

N>3. Как это сынтегрировать с IDE (и с каким), чтобы получить возможность запускать тесты кнопкой в нём, чтобы по логу тестов давало ссылку на конкретную строку кода, и прочие типичные плюшки IDE? И чтобы его точно так же можно было запускать под CI (Jenkins) и получать отчёты об исполнении?
По тому, что ты написал можно понять, что Spring Boot + JUnit правильный выбор. Можно поднимать 100% боевой код, можно по желанию мочить что-то, в разных тестах можно по разному это делать. Поддержка IDE (Idea вне конкуренции) со всеми плюшками будет. В дженкинсе плагины на любой вкус и цвет.

Есть еще https://docs.cucumber.io/ возможно оно вам больше понравится. Качество интеграции примерно такое-же но другой подход к организации тестов.

Всем спасибо за подробные и конструктивные комментарии.
Похоже, до реализации дойдёт где-то через полгода тогда же отпишу, что получилось.