这显然是一个实际问题。互联网专家建议从逻辑上组织可维护性测试。对于ReST API控制器，可以在一个文件中包含该控制器所有动作的所有集成测试。
[假设每个控制器有4个CRUD操作，每个操作平均要进行6个测试，那么最后在一个文件中至少要进行24个测试。在工业级Web服务器中，我怀疑这个数字会进一步膨胀。
事实是，即使这些动作属于一个类（控制器）的一部分，它们也是复杂且符合规范的（测试每个小组所需的不同资源/工件/模型）。
我很难说所有这些测试都应该放在一个文件中，因为它们测试的是几乎完全不同的东西，并且可以放在4个单独的文件中。毕竟这是否更符合TDD的精神？
我的直觉放错了位置吗？
没有什么可以阻止您以对项目有意义的任何方式来组织测试。
Internet智慧与此无关，做对您有用的事情。您想要每种Crud方法一个测试文件吗？然后做。
您进行的测试所处的位置远不如实际进行的测试以及如何进行那么重要。
请注意，我已经看到人们花了很长时间并完全测试了错误的东西。
让实例化控制器从它们中调用方法（不要，这是SOC确实很差的迹象），让我们嘲笑谁知道什么。
如果您对应该进行单元测试的单元进行单元测试，那就是更好的结果，那就是功能性的东西，可以完成工作的类和方法。对于API，这意味着业务规则，数据转换，模型转换等。
[对于其余部分，我将坚持集成测试，像普通用户一样称呼您的端点，这主要是指集成测试。使用类似Postman的工具来组织测试的集合。
您将减少很多模拟，如果您更改实现细节，测试不会受到太大影响，您将能够在端点上进行测量，并且您实际上将测试真实的东西，然后进行所有操作通往存储和返回的方式，没有任何嘲笑内容可以提供给您。