我想确保我的单元测试是可读和可维护的，而不是将我的组件(或类)的所有测试转储到一个文件中，因为这似乎是现在的"最佳实践"。我认为这种做法对除了琐碎的代码或组件之外的任何东西都是有害的，并且在我见过的所有 JS/TS 代码库中都可能成为一种负面力量。
我自己不是前端开发人员，我正在努力寻找或看到更好的替代方案，但到目前为止，解决"胖测试文件"问题的唯一选择是为每个组件/服务创建一个specs文件夹，并且：
- 为每个方法创建一个测试文件
或
- 为每个描述"上下文"创建一个测试文件
当需要通用状态或设置时，我可以创建一个"帮助程序"服务或一些其他通用功能，这些功能可以从需要它的测试中调用。
这是否被认为是可以接受的方法，还是这个问题在最佳实践方面仍未真正确立？
以另一种方式看待问题：为什么你的测试如此繁重？
根据样式指南，您应该考虑将文件限制为 400 行代码。
删除样板、导入和空格，相当于大约 300 行代码。您的ng功能是否仅限于此？
如链接中所述，您应该依靠一个规则，该规则基本上表明您的功能应该具有单一责任。您的功能是否遵循该规则？
除此之外，假设您遵循这些规则并且仍然拥有大量的测试文件，有几种解决方案可以减少测试所需的代码量：
- 对于模拟，您可以在ng功能的同一文件夹中创建一个单独的文件
- 您可以将测试拆分为多个文件，每个文件专用于特定任务(
***.ui.spec.ts，***.http.spec.ts... - 您还可以在类/常量中分解测试代码，使其可重用
最后，
但到目前为止，解决"胖测试文件"问题的唯一选择是为每个组件/服务创建一个规格文件夹
错了。根据风格指南，
为了有效地工作，您必须能够快速找到文件，尤其是当您不知道(或不记得)文件名时。将相关文件放在直观的位置可以节省时间。描述性文件夹结构对您和您的后人产生了天壤之别
Si 您应该将测试文件保留在其功能旁边。