TDD - 测试接口的存在性

Question

开始使用TDD，我想要创建一个存储库驱动的模型。但是，如何使用NUnit有效地说：

SomeInterfaceExists()

我想为每个域模型创建测试（例如ICarRepository，IDriverRepository）等。）

这真的有意义吗？

此致

Answer 1

这不是你用TDD测试的东西。测试是我可以在这个类上调用该接口的一个方法，并返回正确的东西。

Answer 2

TDD意味着您通过以测试优先的方式进行开发（设计），这意味着您

1. 写下您要测试的班级的大纲（方法）
2. 您为班级草图创建单元测试
3. 您运行单元测试 - ＆gt;它会失败
4. 你破解你的课程，足以让考试通过
5. 你重构你的课程

每个项目都会重复此操作。

Answer 3

我会说编译器'测试'（我知道这是一个有争议的声明）当接口尝试编译实现它的类时存在。我希望在测试中明确测试接口是否存在，因为它没有任何证据。您没有测试已经定义了类，您测试了类的方法。

Answer 4

您可以写下类似内容：

void AssertSomeInterfaceExists(object domainObject)
{
    Assert.IsTrue(domainObject is ICarRepository);
}

您可以编写此测试，如果有人将您的域对象更改为不再实现ICarRepository，则该测试将失败。但是，您的其他单元测试（取决于实现此接口的域对象）将不再编译，这将使此测试有点多余。

Answer 5

每次在测试中使用接口时，都会测试接口是否存在 implicity 。例如，在接口或其任何实现存在之前，您可以编写一个部分说明的测试：

ICar car = new Convertible();

这确定了ICar接口的存在 - 你的测试在创建之前不会编译 - 并且Convertible实现了ICar。您调用的汽车上的每个方法都会详细说明界面。

Answer 6

您无需测试您的界面是否存在。你实际上并没有“测试”任何东西。

Answer 7

如果您的域对象不需要数据访问代码，会发生什么。一个例子 - 购物车？

Answer 8

您可以使用反射来判断接口的存在，但这似乎延伸了TDD的概念。

请记住，TDD是关于确保功能随着时间的推移而保留，而不是关于断言应用特定设计模式。正如Juri所指出的，测试不是绝对你构建的第一件事。