我可以使用单元测试工具进行集成测试吗？

Question

我正准备创建我的第一个单元测试，或者至少我是这么想的。在本周末阅读单元测试后，我怀疑我实际上是想做集成测试。我有一个来自第 3 方供应商的黑盒组件（例如数字比例 API），我想创建测试来测试它在我的应用程序中的使用情况。我的目标是确定该组件的新发布版本在集成到我的应用程序时是否正常工作。

这个组件的使用深深地隐藏在我的应用程序代码中，如果没有我目前无法进行的大量重构，使用它的方法将很难进行单元测试。我打算，最终。 考虑到这一事实，我计划编写自定义单元测试（即不从我的类方法或属性之一派生），以使这个第 3 方组件通过我的应用程序需要的相同操作。我确实怀疑这样做会规避单元测试的显着优势，但正如我之前所说，我现在不能停止并重构我的应用程序的这个特定部分。

我想知道我是否仍然可以编写单元测试（使用 Visual Studio）来测试这个组件，或者这是否违背了最佳实践？从我的阅读来看，Visual Studio 中的单元测试工具似乎就是为了做到这一点而设计的——单元测试方法和组件的属性。

我在脑子里转了一圈，我无法确定我想要的是单元测试（第 3 方组件的）还是集成测试？我喜欢单元测试是因为它是一个执行测试的托管系统，但我不知道它们是否适合我正在尝试做的事情。

Answer 1

1. 您计划围绕第 3 方组件进行测试，以证明它执行您认为的操作（系统的其余部分需要它执行的操作）是一个好主意。这样，当您升级组件时，您可以快速判断它是否发生了变化，这意味着您的系统需要进行更改。这将是该组件与系统其余部分之间的Integration Contract Test。

2. 展望未来，您应该将该第 3 方组件放在系统其他组件所依赖的接口后面。然后可以独立于第 3 方组件来测试这些其他部分。

我会参考 Micheal Feathers 的Working Effectively with Legacy Code，了解如何将单元测试添加到不适合单元测试的代码中。

Answer 2

以您的方式测试第 3 方组件当然不违反最佳实践。

但是，此类测试将被归类为（子）系统测试，因为 a) 将第 3 方组件作为独立的（子）系统进行测试，并且 b) 您的测试目标是验证API 级别的行为，而不是测试较低级别的实现方面。

该测试绝对不会被归类为集成测试，因为您只是没有将组件与您的代码一起测试。也就是说，例如，您不会发现您的组件是否以违反 3rd 方组件期望的方式使用 3rd 方组件。

也就是说，我想说两点：

• 测试不是单元测试这一事实并不会降低它的价值。我遇到过这样的情况，我告诉人们他们的测试不是单元测试，他们对我很生气，因为他们认为我想告诉他们他们的测试没有意义——这是一种不幸的误解。
• 测试属于哪个类别不是由技术细节定义的，例如您使用的测试框架。它是由您希望通过测试实现的目标来定义的，例如，您希望找到哪些类型的错误。