时间戳

首页 > 解决方案 > 旧代码中的 TDD - 打破“构造函数”依赖项

java - 旧代码中的 TDD - 打破“构造函数”依赖项

问题描述

在 JAVA 应用程序中，我有以下类：

public class PathEditor extends DocumentListBase {
    public PathEditor(Paths paths, Frame frame) {
        super(frame);

        // Some logic is being executed here.
    }
}

PathEditor该类正在使用一些复杂的继承，但下面列出了能够实例化 a 的所有相关类。

路径

public class Paths {
}

框架

public class Frame extends DocumentListItemBase {
    public Frame(DocumentBase parent) {
        super(parent);
    }
}

文档列表项库

public class DocumentListItemBase extends DocumentBase {
    public DocumentListItemBase(DocumentBase parent) {
        super(parent);
    }
}

文档库

public class DocumentBase {
    public Document _document;

    public DocumentBase(DocumentBase parent) {
    }

    public Document getDocument() {
        return this._document;
    }
}

文档列表库

public class DocumentListBase extends DocumentBase {
    public DocumentListBase(DocumentBase parent) {
        super(parent.getDocument());
    }
}

文档

public class Document extends DocumentBase {
    public Document(DocumentBase parent) {
        super(parent);
    }
}

现在，我需要PathEditor使用 TDD 方法向我想添加的函数添加一个函数。您可能会看到问题，我无法PathEditor在 UT 上下文中创建 a，因为它取决于具体类型。

请注意，具体类型在其构造函数中执行一些逻辑，例如调用数据库，因此不适合将它们添加到“UT”上下文中。

显然，这个类必须重构以允许 TDD 方法，但该类不包含任何测试。使此类可测试的首选方法是什么，使用尽可能小的更改以确保我不会破坏构造函数所做的任何事情？

标签： javarefactoring

解决方案

  1. 如果现有代码没有测试，您的首要任务是在修改该代码之前添加测试。这将为您的更改形成基线，确保您不会引入回归。
  2. final举例来说，显示的具体类都不是，Paths并且Frame可以被归类为测试模拟，如果这会使事情变得更容易的话。只要依赖项被注入并且是可扩展的，依赖项是具体的就无关紧要了。
  3. 如果构造函数依赖于未注入的依赖项，并且您希望在不调用这些依赖项的情况下测试此类类，则可能会被迫重构这些类。从 #1 开始，在重构之前编写（至少是集成）测试。

推荐阅读