java - 通过 "reference"而不是通过内容测试 .jar 库

Question

我需要在我的应用程序中使用第三方 .jar lib:不幸的是，这个第三方应用程序的设置方式使其几乎无法在我的 Windows 盒子上进行测试(因为它是为 Unix 环境设置的 - 我会省去细节)。所以我对其进行了重构，以便能够对其进行测试(更改结构以使用 maven/spring，以便属性文件的处理更加灵活，而无需更改调用接口(interface))。如果新版本编译为相同的 .jar 名称/版本/等。我大概可以在本地测试它，然后在“真正的”.jar 中进行编译以进行生产。这是愚蠢的想法吗？ (我有一种强烈的预感，因为我引入了一个不平凡的依赖关系......)。如果是这样，我怎样才能更好地测试这个库(例如不必将我自己的重构更改合并到原始代码中)？

Answer 1

从概念上讲，您已将第三方 jar 分割为两部分 - 属性位和其余部分。您用自己的东西替换属性位，然后继续测试其余部分。发布时，您准备一个包，其中包括您已测试过的部分以及您尚未测试过的原始属性内容。在采取这种方法时，您引入了哪些风险？

1. 您发布的代码不会是您测试的代码 - 它是一个不同的 JAR，尽管经过仔细处理，并不是一个非常不同的 JAR - 因此，如果您相信自己能够正确执行，这可能是一个可以接受的风险。
2. 您未测试的代码已损坏。这表明至少需要在真实平台上进行一些测试。
3. Windows 上的测试与 Unix 上的测试得出不同的结果。再次表明了一定程度的 Unix 测试。

我认为你的方法是务实的，并且可以通过至少在 Unix 上执行一些测试来减轻风险。我假设您基于 Windows 的测试是为了便于开发/调试。我会这样做，但我会尝试构建一个可以在 Unix 上运行的回归测试套件 - JUnit 测试可以在那里运行。