在大约（2）个工作日为我想要实现的目标寻找正确类型的单元测试之后，我觉得我想要一些无法获得的东西。阅读（8）年前的一篇文章后： 单元测试中的“坏”属性是什么？ 我现在相信我要求测试一个荒谬的配置。
我本质上是在尝试使用 Google 测试框架对各种因素的组合（如 n=729 不同配置中的各种）进行黑盒测试，似乎我在问不可能的事情。我只是想一次测试太多东西，就像评论中的某个人写的那样。
我知道自动化是软件 QA 中非常有用的工具（我的应用程序是基于桌面的，以供将来参考），但是在此之前我的简单单元测试只更改了每个配置的一个参数，并且仍然需要我做大量的工作。与我现在想做的相比，这很容易。由于我需要多少思考/外部行动，我基本上排除了这个选项。
我从昨天的帖子中复制了一个旧链接，该链接描述了我的问题以及我究竟想测试什么以供参考： 是否有有效的黑盒测试方法可以避免冗余？
我会很感激任何人对他们认为对单元测试提出太多要求的意见。
您所做的可能不是真正的单元测试。
单元测试是关于在小的、孤立的代码片段中发现错误。这意味着，您通常会测试一个类的单个函数或方法，在极少数情况下会稍微（！）较大部分的代码。请参阅https://stackoverflow.com/a/55153145/5747415，或者，要了解单元测试与其他测试阶段（如集成测试）的区别，请参阅https://stackoverflow.com/a/56120843/5747415。
还在想你在做单元测试吗？那么也许黑匣子不是要走的路。
虽然您可以在单元测试期间应用黑盒测试方法，但单元测试是最接近代码级别的测试阶段（例如，与集成测试相比）：开发人员通常为自己的代码创建单元测试，而他们在代码上工作，这意味着当时他们无论如何都牢记在心。由于这个和其他原因，单元测试更自然地以玻璃盒测试风格执行。
详尽的黑盒测试会导致大量测试用例，因为您正在创建输入值集的笛卡尔积。但是，在典型代码中，有一些特殊情况（例如错误情况）会提前处理。例如，如果第一个参数无效，则代码可能会立即退出并出现异常。然后，用剩余参数的笛卡尔积的每个组合来测试场景“第一个参数无效”是没有价值的。在严格的黑盒测试中，您无法知道“第一个参数无效”情况下的提前退出，但在单元测试中，您会利用这些知识。
仍然相信所有组合都很重要吗？
那么很可能函数/方法/类或任何你正在单元测试的东西太大了，应该分成更小的函数。您尚未在问题中显示任何代码，这对于单元测试问题是不典型的。
我相信您面临的问题不是因为单元测试本身，而是因为单元测试中缺少方法。
如果您的特定问题是您的测试用例太多（检查的可能性太多），我强烈建议使用以下两种方法进行选择（基于https://www.guru99.com/equivalence-partitioning-boundary-value -analysis.html）：
等价类划分
定义在系统中执行相同路径的输入值类。例如，如果您有一个方法 isAdult 来检查输入整数是否 >= 18，您可以将输入分为三个类：
边界值分析
让您从等价类中选择最有效的代表。这是通过探索两个等价类之间的边界来完成的，其中通常存在大多数错误检测潜力。但我不想详细介绍 - 如果您有兴趣，可以查看例如https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html以获取一些示例和视觉效果（在这两种方法上）。
工具支持
在定义等价类时，您甚至可以（理论上）在这个元级别上工作并与您的测试用例交互。无需关心从等价类生成的许多测试用例。在实践中，诸如https://www.devmate.software/（我个人使用的工具）或https://www.tricentis.com/products/automate-continuous-testing-tosca/之类的工具（对我来说太贵了） - 并且不确定它 tosca 是否明确支持等价类分区）允许您通过从等价类自动生成和管理测试用例代码来做到这一点。
单元测试最佳实践
如果您还有其他问题（除了“测试用例过多”方面），您还应该评估您的单元测试并尝试坚持常见的最佳实践。您可以在此处找到有关好/坏单元测试的一些示例，例如：https ://www.devmate.software/good-unit-tests-vs-bad-unit-tests-with-c-and-nunit-examples/ 基本上，他们归结为