Question

在TDD中，当你知道最终结果应该是什么时，你应该继续，但不是你需要的处理步骤？

例如，您的类正在传递一个API对您来说是全新的对象，您知道该类具有您需要的信息，但您还不知道如何检索它：您将如何进行测试？< / p>

您是否只关注忽略步骤的理想结果？

修改1

package com.wesley_acheson.codeReview.annotations;

import com.sun.mirror.apt.AnnotationProcessor;
import com.sun.mirror.apt.AnnotationProcessorEnvironment;

public class AnnotationPresenceWarner implements AnnotationProcessor {

    private final AnnotationProcessorEnvironment environment;

    public AnnotationPresenceWarner(AnnotationProcessorEnvironment env) {
        environment = env;
    }

    public void process() {
        //This is what I'm testing
    }

}

我正在尝试测试这个不完整的课程。我想测试我在流程方法中与AnnotationProcessorEnvironment的正确交互。但是，我不确定API文档中正确的交互是什么。

这将生成一个文件，其中包含有关源树中每个注释出现的详细信息。

然而，实际的文件写入可能会被委托给另一个类。因此，这个类的责任是创建注释出现的表示，并将其传递给需要移动它的任何类。

在非TDD中，我可能会调用一些方法设置一个断点并查看它们返回的内容。

无论如何，我不是在寻找这个特定示例的解决方案，有时候你不知道如何从A到B，并且你希望你的代码是测试驱动的。

Answer 1

我的答案基于这段视频： http://misko.hevery.com/2008/11/11/clean-code-talks-dependency-injection/

如果你有一个模型/业务逻辑类，它应该从服务中获取一些数据，那么我会这样做：

让您的模型类在构造函数中获取所需的数据，而不是服务本身。然后，您可以模拟数据并对您的班级进行单元测试。
为服务创建一个包装器，然后可以对包装器进行单元测试。
执行更全面的测试，将实际将数据从包装器传递到模型类。

Answer 2

一般答案 TDD可用于解决许多问题，首要的是确保代码更改不会破坏现有代码的预期行为。因此，如果您使用TDD编写了一个类，则首先编写一些代码，看它失败，然后编写行为使其变为绿色而不会导致其他测试变为红色。

编写测试用例的副作用是现在您有文档。这意味着TDD实际上为代码提供了两个不同问题的答案。在学习新的API时，无论它是什么，您都可以使用TDD来探索它的行为（在某些框架中，这可能很难非常很难）。因此，当您探索 API时，可以编写一些测试来提供它的使用文档。您也可以将此视为一个原型设计步骤，只是原型设计假定您在完成时将其丢弃。使用TDD方法，您可以保留它，因此您可以在学习API之后很久就返回它。

给定示例的具体答案 有许多方法试图用AnnotationProcessor解决问题。有一个Assertion framework通过在测试期间加载java代码并断言发生错误/警告的行来解决问题。在Stack overflow

Answer 3

我会在没有测试的情况下创建一个原型，以了解api是如何工作的。当我理解了这一点，我将继续我的项目的TDD周期

Answer 4

我同意巴塞塔森的观点。首先进行峰值以了解此外部API调用的作用以及您的方法所需的内容。一旦您熟悉API，您就知道如何继续使用TDD。

Answer 5

永远不要对未知的API进行单元测试。如果您没有代码，遵循相同的原则。隔离您正在编写的所有未知或无主的代码。

编写单元测试，好像environmental processor将成为您稍后将要进入TDD的代码。

现在你可以按照@Tom的建议，除了删除步骤1.步骤2的单元测试现在只是将包装类的输出映射到未知API的调用。第二步更像是集成测试。

我坚信，从TDD到原型设计再到TDD的流程都是速度的损失。继续使用TDD，直到完成，然后原型。

当您需要探索代码时，如何进行单元测试？

5 个答案: