测试ReST应用程序接口控制器时，是否谨慎地在单个测试文件中测试所有操作(创建、更新、获取、删除等)？
这显然是一个实际的问题。互联网智慧建议合理地组织可维护性测试。当涉及到ReST应用程序接口控制器时，可以在单个文件中包含控制器所有操作的所有集成测试。
假设我们每个控制器有4个CRUD操作，每个操作平均有6个测试，我们最终在一个文件中至少有24个测试。在工业级web服务器中，我怀疑这个数字会进一步上升。
问题是，尽管这些操作是一个类(控制器)的一部分，但它们是复杂和规范的(测试每个组所需的不同资源/工件/模型，等等)。
我很难接受所有这些测试应该放在一个文件中，因为它们测试的几乎是完全不同的东西，可以放在4个单独的文件中。这不是更符合TDD的精神吗？
我的直觉放错地方了吗？
回答 1
Stack Overflow用户
发布于 2020-01-28 16:52:16
没有什么能阻止你以任何对你的项目有意义的方式来组织你的测试。
网络智慧与此无关，做对你有用的事吧。您希望每个crud方法有一个测试文件吗？那就这么做吧。
你的测试在哪里并不重要，重要的是你实际测试的是什么以及如何测试。
只需注意一点，我见过人们花了很长时间测试完全错误的东西。
让我们实例化控制器来调用它们的方法(不要这样做，这是一个非常糟糕的SOC的标志)，让我们来模拟一下谁知道什么。
如果你对应该进行单元测试的功能类和方法进行单元测试，你会得到更好的结果。对于API来说，这意味着业务规则、数据转换、模型转换，诸如此类。
对于其余部分，我会坚持集成测试，像普通用户一样调用端点，这意味着主要是集成测试。使用Postman之类的工具来组织测试集合。
你将有更少的模拟，如果你改变你的实现细节，你的测试不会受到太大的影响，你将能够在你的端点上进行测量，你将实际测试真正的东西，一直到你的存储并返回，这是任何模拟都不会给你的。
https://stackoverflow.com/questions/59935653
复制相似问题
腾讯云开发者
