我正准备创建我的第一个单元测试，或者至少我正在考虑它。在本周末阅读了单元测试后，我怀疑我实际上是想进行集成测试。我有来自第三方供应商的黑盒子组件（例如数字规模API），我想创建测试来测试它在我的应用程序中的用法。我的目标是在集成到我的应用程序中时确定新发布的所述组件版本是否正常工作。
这个组件的使用深埋在我的应用程序代码中，如果没有进行广泛的重构，那么使用它的方法将非常难以进行单元测试，而目前我无法进行重构。我计划，最终。 考虑到这一事实，我计划编写自定义单元测试（即，不从我的类方法或属性派生），以使第三方组件通过我的应用程序将需要的相同操作。我确实怀疑我通过这种方式绕过单元测试的重大好处，但正如我之前所说，我不能在此时停止并重构我的应用程序的这个特定部分。
我想知道我是否仍然可以编写单元测试（使用Visual Studio）来测试这个组件，还是反对最佳实践？从我的阅读中看来，Visual Studio中的单元测试工具似乎只是为了实现这一点 - 单元测试方法和组件的属性。
我在脑子里徘徊，我无法确定我想要的是单元测试（第三方组件）还是集成测试？我被单元测试所吸引，因为它是一个执行测试的托管系统，但我不知道它们是否适合我正在尝试做的事情。
答案 0 :(得分：0)
您计划在第三方组件周围进行测试，以证明它符合您的想法（系统的其余部分需要它做什么）是一个好主意。这样，当您升级组件时，您可以快速判断它是否已经发生变化，这意味着您的系统需要更改。这将是该组件与系统其余部分之间的Integration Contract Test。
展望未来，您应该将第三方组件置于系统其他组件所依赖的接口之后。然后可以将这些其他部分与第三方组件隔离进行测试。
我会参考Micheal Feathers'Working Effectively with Legacy Code获取有关如何将单元测试添加到代码中的信息，这些代码对于单元测试来说并不是很好。
答案 1 :(得分：0)
按照您的方式测试第三方组件肯定不会违反最佳做法。
然而，这样的测试将被归类为（子）系统测试，因为a）第三方组件作为隔离（子）系统进行测试，并且b）您的测试目标是验证API级别上的行为，而不是测试较低级别的实现方面。
测试绝对不会被归类为集成测试，因为您根本就不会将代码与代码一起进行测试。也就是说，您将不会发现您的组件是否以违反第三方组件期望的方式使用第三方组件。
那就是说，我想提出两点：