最近我发现我对不同类型测试的理解可能并不完全正确。
例如单元测试 是测试一个单元，其中与其他单元的交互基于模拟（假货、存根）。所以，没有与文件系统、线程、时间的交互......
组件测试，对我来说，是围绕一个组件（更多单元）进行的测试，我同时使用了模拟和“真实”资源。我将它们都用于输入模拟和输出测试。任何看起来更合适的东西。例如。我在嘲笑当前仲裁状态的变化，但我断言事件存储在 RTDB 中。
对我来说，这些组件通常是一个应用程序的切片。
功能测试我认为是围绕我在生产中运行的应用程序 (exe) 的（黑盒）测试。
嗯，这是真的还是假的？ 组件测试是否仅基于模拟？如果是，为什么？我如何确定模拟足够好？ 我们是否应该从功能测试中运行应用程序？为什么它与线程中应用程序主例程的引导不同？ 什么是集成测试？
我想听听其他意见以及您是如何做到的。您有哪些测试，如何维护它们以及团队中谁负责这些测试？
干杯！
【问题讨论】：
标签： .net unit-testing testing functional-testing
你的问题有点没有重点，但我还是会尽力给出答案。
这里已经讨论了各种测试：What is Unit test, Integration Test, Smoke test, Regression Test?
然而，区分不同类型测试的主要不是使用双精度数（如模拟、存根等）。 目标你通过不同的测试来区分它们。
在单元测试中，目标是测试您编写的代码片段的行为是否符合您的预期。也就是说，您正在根据您对代码应该如何表现的假设来测试您的代码。加倍（模拟）只是实现此目标的一种手段，同时确保 a) 测试所有场景（包括错误情况） b) 确定性测试结果（独立于时间/调度/环境条件） c) 快速测试构建和执行 d) 简单的测试设置 e) 独立于库问题（不完整、有问题，...）。如果您可以通过使用真正的库来达到所有这些标准，那么您不必将库翻倍。例如，在大多数情况下，您不会为作为编程语言标准库的一部分的容器库（列表、集合、映射...）创建双精度对象——您通常只需通过使用图书馆。
识别关于如何与其他软件部分交互的误解不是单元测试的目标。而且，由于将与您的单元交互的软件部分加倍不是强制性的，但完全可以，在这种情况下，您甚至无法识别此类误解：每当您将其中一个依赖项加倍时，您就是在根据您的理解实现加倍（可能还有你的误解）其他组件。因此，识别关于如何与其他组件交互的误解是集成测试的目标。在集成测试中，您将这些组件以及您想要测试的交互组合在一起。同样，其他组件可以链接或加倍，具体取决于与单元测试类似的标准。
一旦您意识到单元测试和集成测试的不同目标，您也会意识到不同的目标将导致构建不同的测试用例集。因此，单元测试套件仍然是单元测试套件，无论您是否可以通过链接真正的库而不是使用双精度库来相处。
然后，(sub-)system-testing 再次引入不同的目标，例如测试一组组件是否一起实际实现了该（子）系统的所需功能。例如，组件 A 和 B 对结构列表进行操作，除其他外，最终列表应进行排序。现在，A 和 B 的开发人员可能会假设另一个将进行排序。并且，如果它们都不需要为自己的代码对数据进行排序，a) 两个组件都将具有不测试被排序输出的单元测试套件，并且 b) 将有集成测试来测试它们之间的交互A 和 B 不一定测试来自另一个的输入是否已排序。但是，通过（子）系统测试，将测试所有必需功能的存在，并检测到缺失的排序。同样，（子）系统测试环境中的其他组件可以链接或加倍 - 这两种情况都是可能的。
但是，您询问的是 component-testing，它很可能是（子）系统测试的同义词，或者描述（子）系统测试组合的术语以及构成这个（子）系统的组件的集成测试。而且，您提到的功能测试很可能是软件系统级别的（子）系统测试（因此，不是子测试，而只是系统测试）。而且，最后按照我的理解回答这个问题，现在应该很清楚，使用双精度不是对测试套件进行分类的可靠标准，但测试的各自目标是。
【讨论】：