在遗留的junit测试套件中解决java classpath地狱

Question

假设我有一个遗留的JUnit测试套件,其中包括以下测试:

public class AwesomeTest {
     public void testBusinessLogic() {
     ...
     [awesome mocking library]
     ...
     }
}

public class AmazingTest {
    public void testBusinessProcess() {
    ...
    [amazing xml operation]
    ...
    }
}

现在假设Awesome Mocking库依赖于包含该类的Awesome BCEL字节码生成库,org.useful.XMLClass该库具有XMLClass的版本1.

现在假设Amazing Xml操作依赖于包含该类的Amazing Xml库,org.useful.XMLClass并且该库具有XML Class的版本2.

还假设该类的版本2不向后兼容版本1 - 因此哪个版本在类路径中具有更高的优先级 - 它打破了另一个版本的依赖性.

还假设有400个测试依赖于令人敬畏的模拟库 - 所以重写不是一个理想的选择.

还假设一些关键业务功能已经使用了惊人的xml库构建 - 并且强烈建议不要重写它.

你如何解决这个类路径地狱的情况 - 除了运行ant测试(假设你用Ant运行它们)两次使用两个不同的手动排序的类路径和手动确定的测试子集？(我对自定义类加载器的想法持开放态度 - 但这似乎与使用ant解决方案的双自定义类路径具有相同的可维护性水平)

Answer 1

我确实相信使用 java 代理和自定义类加载器可以实现相当透明的解决方案。这个想法如下：

1. 使用Instrumentation Framework（java 代理）在加载类时拦截它们。当您检测到 Awesome Mocking Library 中的类时，请将所有引用替换为org.useful.XMLClass，例如intercepted.org.useful.XMLClass.
2. 创建一个自定义类加载器，在其中检查请求的类是否为intercepted.org.useful.XMLClass. XMLClass如果是，则加载模拟库使用的版本。所有其他请求都可以默认处理。

使用自定义类加载器并在运行测试时附加 java 代理，一切都应该正确运行，就好像没有依赖项冲突一样。