Тестирование библиотеки .jar по «ссылке», а не по содержимому

Question

Мне нужно использовать стороннюю .jar lib в моем приложении: к сожалению, из-за того, как настроено это стороннее приложение, его практически невозможно протестировать на моем компьютере с Windows (поскольку он настроен для среды Unix - я сэкономлю детали). Поэтому я реорганизовал его, чтобы иметь возможность его протестировать (изменил структуру для использования maven / spring, чтобы обработка файлов свойств была более гибкой, без изменения интерфейса вызова). Если новая версия компилируется с тем же именем .jar / version / etc. Я могу предположительно проверить его локально, а затем скомпилировать в «настоящий» .jar для производства. Это глупая идея? (У меня есть сильное предчувствие, что это так, поскольку я ввожу нетривиальную зависимость ...). Если да, как я могу лучше протестировать эту библиотеку (например, без необходимости объединять мои собственные изменения рефакторинга с исходным кодом)?

Answer 1

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

1. То, что код, который вы выпускаете, не будет кодом, который вы тестировали - это другой JAR, хотя с осторожным процессом, а не совсем другим JAR - так что, если вы доверяете себе, чтобы сделать это правильно, это может быть приемлемым риском.
2. То, что код, который вы не тестировали, не работает. Это говорит о том, что на реальной платформе необходимо хотя бы некоторое тестирование.
3. То, что тесты на Windows дают разные результаты от тестов на Unix. Снова указана некоторая степень тестирования Unix.

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