语言无关 – 开发到TDD接口

我是TDD的忠实粉丝,并且最近将它用于我的大部分开发.然而,我经常碰到的一种情况,从未发现我认为是“好”的答案,就像下面的(人为的)例子.

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

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

    int getShortestPathLength(GraphNode start, GraphNode goal);
}

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

问题是,如何使用TDD开发这三种实现？他们的公共接口将是相同的,并且,我可能会为每个人编写相同的测试,因为getShortestPath()和getShortestPathLength()的结果应该在所有三个实现中保持一致.

我的选择似乎是：

>在对第一个实现进行编码时,针对PathFinder编写一组测试.然后将其他两个实现写成“盲”并确保它们通过了PathFinder测试.这似乎不对,因为我没有使用TDD来开发第二个两个实现类.
>以测试优先的方式开发每个实现类.这似乎不对,因为我会为每个类编写相同的测试.
>结合上述两种技术;现在我有一组针对接口的测试和针对每个实现类的一组测试,这很好,但测试都是一样的,这不太好.

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

您编写接口测试来练习接口,并为实际实现编写更详细的测试. Interface-based design谈到了一个事实,即你的单元测试应该为该接口形成一种“契约”规范.也许当Spec#出现时,将会有一个支持这种方式的语言.

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

编辑：这很有用,所以当你在路上添加另一个接口实现时,你已经有了测试来验证该类是否正确实现了接口的契约.这可以像ISortingStrategy那样特定于IDisposable等广泛的东西.