单元测试接口的定义是否必要？

Question

我偶尔会听到或读到人们在单元测试中断言他们的接口.我并不是要嘲笑一个用于其他类型测试的接口,而是专门创建一个伴随接口的测试.

考虑这个超级蹩脚的袖手旁观的例子:

public interface IDoSomething
{
   string DoSomething();
}

和测试:

[TestFixture]
public class IDoSomethingTests
{
   [Test]
   public void DoSomething_Should_Return_Value()
   {
        var mock = new Mock<IDoSomething>();
        var actualValue = mock.Expect(m => m.DoSomething()).Returns("value");

        mock.Object.DoSomething();
        mock.Verify(m => DoSomething());
        Assert.AreEqual("value", actualValue);
   }
}

我想这个想法是使用测试来驱动界面的设计,并为实现者提供预期的指导,以便他们可以自己进行良好的测试.

这是一种常见(推荐)的做法吗？

Answer 1

在我看来,仅仅使用模拟框架测试接口除了模拟框架本身之外几乎没有测试.我个人没有时间花在上面.

我想说应该驱动界面设计的是什么功能.我认为很难确定只使用模拟框架.通过创建接口的具体实现,需要与否的内容将变得更加明显.

我倾向于这样做的方式(我决不是推荐的方式,只是我的方式),是在具体类型上编写单元测试,并引入依赖注入目的所需的接口.

例如,如果测试中的具体类型需要访问某个数据层,我将为该数据层创建一个接口,为该接口创建一个模拟实现(或使用一个模拟框架),注入模拟实现并运行测试.在这种情况下,接口没有为数据层提供抽象的目的.

Answer 2

我从来没有见过这样的东西,但似乎毫无意义.您可能希望测试这些接口的实现,而不是接口本身.