测试驱动接口设计

Question

自从我从大学开始我的第一份工作(大约5个月前)以来，我就一直在做TDD，其中大部分工作是使用遗留代码。我今天开始了一个个人项目，我想我会去做这个项目。我没有太多的“绿色领域”开发经验，所以我不确定这是否是正确的方式驱动界面设计。我正在测试的界面有预期的方法，是服务合同等。我觉得这太过分了？

守则如下：

[TestFixture]
public class IPairSessionTests
{
    [TestCase]
    public void Then_IPairSession_is_a_service_contract()
    {
       var iPairSessionType = typeof(IPairSession);
       Assert.That(iPairSessionType.IsDefined(typeof(ServiceContractAttribute),true));

    }
    [TestCase]
    public void Then_IPairSession_has_Insert_Method()
    {
        var iPairSessionType = typeof(IPairSession);
        Assert.That(iPairSessionType.GetMethod("Insert"), Is.Not.Null);
    }

    [TestCase]
    public void Then_IPairsSession_Insert_is_operation_contract()
    {
        var iPairSessionType = typeof(IPairSession);
        var insertMethod = iPairSessionType.GetMethod("Insert");
        Assert.That(insertMethod.IsDefined(typeof(OperationContractAttribute), true));
    }
}

Answer 1

是的，太多了。对合同上存在的方法进行测试是过分的，也是高维护的.如果您决定更改一个方法名，它会中断测试，并且测试的破坏不会告诉您一些有用的东西。问问自己，你从这个测试中得到了什么价值。

我倾向于通过对使用接口的类进行TDD来测试接口。我不认为更多是有用的。

Answer 2

我认为在TDD中，接口本身并不是第一步(只是它不知怎么已经给出了)。您创建测试，并逐步创建一个具体的类。在进行此过程时，您可能会重构或优化API。提取接口类使您的实现可互换是最后一步。

首先考虑接口可能会不必要地限制您。

Answer 3

我对C#/.NET世界并不太熟悉，但我想有一些现有的工具可以帮您做到这一点。它们可能包含更高级的测试，比如检查返回类型，忽略兼容的更改(例如，将MySubType参数更改为MyType，其中MySubType扩展了MyType)。

以下堆栈溢出问题可能是一个好的开始：验证公共接口的兼容性的工具。

如果接口和接口的客户端仅在同一个应用程序中使用(因此，您可以同时修改这两种方法，编译器也可以对其进行检查)，那么这类测试似乎是不必要的。