我使用django-rest-framework创建了一个休息API。
我有多个API端点。一些用于创建对象，一些用于列出对象，一些用于获取对象的数量等。
在我的测试中，我测试每个端点以确保创建，例如，创建端点只接受POST请求。我测试列表端点以确保它们只接受GET，而不是POST / PUT / PATCH / DELETE。每个端点对应一个视图，该视图具有确定它们允许的请求的设置，但测试确保这些设置有效。测试主要断言返回一定的状态代码。
测试非常重复。评论API的测试大约是600行。这种测试是否必要，和/或是否有简化的替代方案？
答案 0 :(得分：2)
这属于测试反模式的类别，您正在测试框架/库而不是您自己的代码。
这样的一些测试是值得的，特别是如果你不熟悉框架，它们用于验证你对它的使用。但是，尽管如此，对其进行全面测试却是您在测试应用程序代码时花费的精力。
如果你真的觉得框架或库是不稳定的，你仍然想要使用它，你最好直接测试它，即分叉项目（假设它是开源的），添加一些测试，并制作一个拉请求。
答案 1 :(得分：2)
我偶然发现了这个很酷的库：django-rest-assured，它似乎占用了很多关于测试这种REST访问的样板。这使得测试该功能变得更加微不足道，甚至可能值得花时间。
答案 2 :(得分：0)
在编写冗余测试和获得系统关键区域足够级别的代码覆盖率之间总会有一个很好的平衡。
由于您应用中的端点很可能会有很多移动部件（即响应/请求解析，HTTP调用，访问数据存储等），您可能会发现太多测试可能会大大减慢测试套件的速度
您经常会发现，结合大量标准单元测试（无i / o），少量有针对性的端到端测试就足够了。 关键是要在关键代码覆盖率和测试套件的可靠性能之间找到一个健康的平衡。
有一个很棒的Stack Overflow主题，其中Kent Beck讨论了一个有效的测试套件：