开发与TDD的接口 [英] Developing to an interface with TDD

问题描述

我是TDD的忠实拥护者，最近这些时间用于我的绝大多数开发工作中.但是，我遇到某种情况时却经常遇到，却从未找到我认为是好"答案的情况，是类似以下(人为)的示例.

I'm a big fan of TDD and use it for the vast majority of my development these days. One situation I run into somewhat frequently, though, and have never found what I thought was a "good" answer for, is something like the following (contrived) example.

假设我有一个像这样的接口(用Java编写，但实际上，这适用于任何OO语言):

Suppose I have an interface, like this (writing in Java, but really, this applies to any OO language):

public interface PathFinder {
    GraphNode[] getShortestPath(GraphNode start, GraphNode goal);

    int getShortestPathLength(GraphNode start, GraphNode goal);
}

现在，假设我要创建此接口的三个实现.我们称它们为DijkstraPathFinder，DepthFirstPathFinder和AStarPathFinder.

Now, suppose I want to create three implementations of this interface. Let's call them DijkstraPathFinder, DepthFirstPathFinder, and AStarPathFinder.

问题是，如何使用TDD开发这三个实现?它们的公共接口将是相同的，并且大概我将为每个接口编写相同的测试，因为getShortestPath()和getShortestPathLength()的结果在所有三个实现中都应该是一致的.

The question is, how do I develop these three implementations using TDD? Their public interface is going to be the same, and, presumably, I would write the same tests for each, since the results of getShortestPath() and getShortestPathLength() should be consistent among all three implementations.

我的选择似乎是:

在我编写第一个实现的代码时，

1. 针对PathFinder编写了一组测试.然后将其他两个实现写为"blind"，并确保它们通过了PathFinder测试.这似乎不对，因为我没有使用TDD来开发后两个实现类.

1. Write one set of tests against PathFinder as I code the first implementation. Then write the other two implementations "blind" and make sure they pass the PathFinder tests. This doesn't seem right because I'm not using TDD to develop the second two implementation classes.

以测试优先的方式开发每个实现类.这似乎不太正确，因为我将为每个类编写相同的测试.

Develop each implementation class in a test-first manner. This doesn't seem right because I would be writing the same tests for each class.

结合以上两种技术；现在我有针对该接口的一组测试，以及针对每个实现类的一组测试，这很好，但是这些测试都是相同的，这不是很好.

Combine the two techniques above; now I have a set of tests against the interface and a set of tests against each implementation class, which is nice, but the tests are all the same, which isn't nice.

这似乎是相当普遍的情况，尤其是在实施策略模式时，当然，实施之间的差异可能不仅仅是时间上的复杂性.别人如何处理这种情况?是否有针对我不知道的接口的测试优先开发的模式?

This seems like a fairly common situation, especially when implementing a Strategy pattern, and of course the differences between implementations might be more than just time complexity. How do others handle this situation? Is there a pattern for test-first development against an interface that I'm not aware of?

推荐答案

您编写用于测试接口的接口测试，并为实际实现编写更详细的测试. 基于接口的设计讨论了一个事实您的单元测试应该为该接口形成一种合同"规范.也许当Spec#发布时，会有一种语言支持的方式来做到这一点.

You write interface tests to exercise the interface, and you write more detailed tests for the actual implementations. Interface-based design talks a bit about the fact that your unit tests should form a kind of "contract" specification for that interface. Maybe when Spec# comes out, there'll be a langugage supported way to do this.

在这种特殊的情况下(这是一个严格的策略实现)，接口测试就足够了.在其他情况下，如果接口是实现功能的子集，则将对接口和实现进行测试.例如，考虑一个实现3个接口的类.

In this particular case, which is a strict strategy implementation, the interface tests are enough. In other cases, where an interface is a subset of the implementation's functionality, you would have tests for both the interface and the implementation. Think of a class which implements 3 interfaces, for example.

这很有用，因此当您在以后添加接口的另一种实现时，您已经具有用于验证该类正确实现接口协定的测试.对于像ISortingStrategy这样具体的东西，对于像IDisposable这样广泛的东西，它都可以工作.

This is useful so that when you add another implementation of the interface down the road, you already have tests for verifying that the class implements the contract of the interface correctly. This can work for something as specific as ISortingStrategy to something as wide-ranging as IDisposable.

这篇关于开发与TDD的接口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！