unit-testing - 接口(interface)和单元测试 - 总是白盒测试？

Question

我终于明白了依赖注入(inject)和类似技术让我担心的是什么，这些技术应该使单元测试变得更容易。让我们举个例子:

public interface IRepository { void Item Find(); a lot of other methods here; }
[Test]
public void Test()
{
  var repository = Mock<IRepository>();
  repository.Expect(x => x.Find());
  var service = new Service(repository);
  service.ProcessWithItem();
}

现在，上面的代码有什么问题？我们的测试粗略地了解了 ProcessWithItem() 的实现。如果它想要执行“from x in GetAll() where x...”怎么办？但是不，我们的测试知道那里会发生什么。这只是一个简单的例子。想象一下我们的测试现在与之相关的几个调用，当我们想在方法内从 GetAll() 更改为更好的 GetAllFastWithoutStuff() 时......我们的测试被破坏了。请改变它们。很多蹩脚的工作经常发生，没有任何真正的需要。

这常常让我停止编写测试。我只是不知道如何在不知道实现细节的情况下进行测试。了解它们后，测试现在变得非常脆弱且痛苦。

当然，这不仅仅与接口(interface)(或 DI)有关。 POCO(以及 POJO，为什么不呢)也遭受同样的问题，但它们现在与数据绑定(bind)，而不是与接口(interface)绑定(bind)。但原理是相同的 - 我们的最终断言与我们对 SUT 将要做什么的了解紧密结合。 “是的，您必须提供这个字段，先生，并且最好具有这个值”。

因此，测试很快就会失败，而且经常失败。这就是痛苦。还有问题。

有什么技术可以解决这个问题吗？ AutoMockingContainer(基本上负责所有方法和嵌套 DI 层次结构)看起来很有前途，但也有其自身的缺点。还有什么吗？

Answer 1

依赖注入(inject)本身可以让您注入(inject) IRepository 的实现，该实现接受对其进行的任何调用，检查不变量和前置条件是否满足，并返回满足后置条件的结果。当您选择注入(inject)一个模拟对象，该对象对将调用的方法有非常具体的期望时，那么是的，您正在执行高度特定于实现的测试 - 但依赖注入(inject)在这件事上完全是无辜的，因为它从来没有规定您要做什么应该注入(inject)；相反，您的烦恼似乎在于模拟 - 事实上，特别是您选择使用的有点自动化的模拟方法，这是一种基于非常具体的期望的方法。

具有非常具体期望的模拟确实仅对白盒测试有用。根据您使用的工具/框架/库(并且您甚至没有在标签中指定确切的编程语言，所以我假设您的问题是完全开放式的)，您也许能够指定允许的自由度(这些调用允许以任何顺序进行，这些参数必须仅满足以下先决条件等)。然而，我不知道有一个自动化工具可以准确执行不透明盒测试所需的功能，即“那边接口(interface)的通用、宽容的实现，以及所有需要的‘按契约(Contract)编程’检查”其他”。

在项目的整个生命周期中，我倾向于为所需的主要接口(interface)建立一个“不太模拟”的库。在某些情况下，这些从一开始可能就有些明显，但在其他情况下，当我考虑一些重大重构时，它们会逐渐出现，如下(典型场景)...:

重构的早期阶段打破了我最初廉价地实现的脆弱的强烈期望 mock 的某些方面，如果我决定这不是一次性的，我会考虑是否只是调整期望或全力以赴(即 future 重构和测试的返回将证明投资的合理性)然后我手工编写一个好的“不太模拟”并将其存放在项目的特定技巧包中——实际上通常可以跨项目重用；诸如 MockFilesystem、MockBigtable、MockDom、MockHttpClient、MockHttpServer 等类/包进入与项目无关的存储库并被重用以测试各种 future 项目(事实上，如果几个团队正在使用文件系统接口(interface)、bigtable 接口(interface)、DOM、http 客户端/服务器接口(interface)等，这些接口(interface)在团队中是统一的)。

我承认，如果您将“mock”特指接口(interface)的“用于测试目的的假实现”的精确期望风格，那么在这里使用“mock”一词可能有点不合适。也许 Stub、Shim、Fake、Test 或其他一些前缀可能更可取(出于历史原因，我确实倾向于使用 Mock，除非我记得专门称其为 Fake 或类似的；-)。

如果我使用的语言能够以清晰而精确的方式用语言本身表达界面中的各种按契约(Contract)设计的规范，我想我会获得对大多数功能的自动工具支持这种伪造/填充/等等；然而我主要用其他语言编写代码，所以我必须在这里做更多的手动工作。但我认为这是一个单独的问题。