我正准备创建我的第一个单元测试，或者至少我是这么想的。在这个周末阅读了单元测试后，我怀疑我真的想做集成测试。我有一个来自第三方供应商的黑盒组件(例如API数字秤)，我想创建测试来测试它在我的应用程序中的使用情况。我的目标是确定所述组件的新发布版本在集成到我的应用程序中时是否正常工作。
这个组件的使用深深地埋在我的应用程序代码中，如果没有广泛的重构，使用它的方法将很难进行单元测试，而我现在无法做到这一点。我计划，最终。考虑到这一事实，我计划编写自定义的单元测试(即不是从我的类方法或属性派生的)，以使这个第三方组件通过与我的应用程序所需的相同操作。我确实怀疑我这样做是在规避单元测试的重大好处，但正如我之前所说，我现在无法停止并重构应用程序的这一特定部分。
我想知道我是否仍然可以编写单元测试(使用Visual Studio)来测试这个组件，或者这是否违反了最佳实践？从我的阅读中可以看出，VisualStudio中的单元测试工具在很大程度上就是为了实现这一点而设计的——组件的单元测试方法和属性。
我在脑子里兜圈子，我无法确定我想要的是(第三方组件的)单元测试还是集成测试？我被单元测试所吸引，因为它是一个执行测试的托管系统，但我不知道它们是否适合我想要做的事情
-
您围绕第三方组件进行测试的计划是一个好主意，以证明它做了您认为它做的事情(系统的其他部分需要它做的)。这样，当你升级组件时，你可以快速判断它是否发生了变化，这意味着你的系统需要改变。这将是该组件和系统其他部分之间的集成合同测试。
-
展望未来，您应该将第三方组件放在系统其他组件所依赖的接口后面。然后，这些其他部件可以与第三方组件隔离进行测试。
我想参考Micheal Feathers的《有效地使用遗留代码》，了解如何将单元测试添加到单元测试中，而单元测试并没有很好地考虑到这一点。
测试第三方组件的方式肯定不会违反最佳实践。
然而，这样的测试将被归类为(子)系统测试，因为a)第三方组件被测试为独立的(子)体系，b)您的测试目标是在API级别验证行为，而不是在测试较低级别的实现方面。
该测试肯定不会被归类为集成测试，因为您根本没有将组件与代码一起进行测试。也就是说，例如，您将不会发现您的组件是否以违反第三方组件期望的方式使用第三方部件。
话虽如此，我想提出两点：
- 测试不是单元测试这一事实并没有降低它的价值。我遇到过这样的情况，我告诉人们他们的测试不是单元测试，他们对我很生气，因为他们认为我想告诉他们他们的测试没有意义——这是一个不幸的误解
- 测试属于哪一类并不是由技术细节来定义的，比如你正在使用哪个测试框架。它是由您想要通过测试实现的目标来定义的，例如，您想要查找哪些类型的错误