无注入(inject)测试

Question

我读到的关于模拟、 stub (测试替身)的大部分内容都涉及某种形式的 DOC 注入(inject)，要么通过 SUT 方法本身，要么通过构造函数或 setter 方法。像 InjectMock 这样打破边界的注入(inject)作为常规测试策略是不受欢迎的。但是，如果您正在构建一个不想公开这些 DOC 的类怎么办？有没有办法对这样的模块进行“单元”测试？没有AOP？这样的测试不再是真正的“单元”测试了吗？我感受到的阻力真的是设计气味吗，我应该以某种方式公开那些 DOC？

例如，假设我有以下要测试的类(单元或其他):

public class RemoteRepository {
  Properties props = null;
  public RemoteRepository(Properties props) { this.props=props; }
  public Item export (String itemName) {
    JSch ssh = new JSch();
    ssh.setIdentity(props.get("keyfile"));
    ssh.connect();
    ssh.execute("export "+itemName+" "+props.get("exportFilename"));
    ...
}

这是一个我想为其编写单元测试的单元，但我想对 JSch 组件进行 stub 或模拟。但是我在方法中创建的对象只是做方法需要完成的事情，甚至没有暴露在方法之外。所以我不能注入(inject) stub 来替换它们。我可以更改导出方法签名以接受 stub ，或者添加一个接受 stub 的构造函数，但这会改变我的设计以适应测试。

虽然该单元将连接到真实服务器以在产品中进行导出，但在测试该单元时，我要么想将 DOC 完全 stub ，要么使用简单且受控的真实 DOC 对其进行模拟。

后一种方法就像使用内存中的数据库而不是真实的数据库，因为它的行为和行为类似于将使用的最终数据库，但可以仅限于测试所需的内容(例如，只是感兴趣的表格，没有严格的安全性等)。所以我可以在我的测试中设置某种测试双 sshd，这样当构建运行测试时，它就有一些东西可以测试。然而，这在设置和维护方面可能会很麻烦，而且看起来有点矫枉过正 - 有时尝试去除真实的 DOC 比仅以某种方式使用真实的 DOC 更难。

我是否一直在尝试设置一个提供 sshd 测试替身的测试框架？我是不是看错了？我是否只使用打破类范围边界的 AOP 或模拟库方法？

重申基本问题是，很多时候我想测试一个具有复杂 DOC 的方法(即与其他系统交互的方法:网络、数据库等)并且我不想更改设计只是为了适应测试双 DOC 注入(inject)。在这种情况下，您如何进行测试？

Answer 1

根据个人经验，我的建议是编写 集成 测试，其中 不 模拟 DOC(依赖组件)。

但是，如果出于某种原因团队坚持要进行单元 测试，您将不得不使用合适的模拟工具(AOP 工具可以，但不适合这里)，或者更改 SUT 和 DOC 的设计以使用“较弱”的模拟工具。