我是否应该在发出 POST 请求后验证发布的内容？

Question

我正在尝试为基于 HTTP REST API 的 Web 应用程序编写一些测试。我曾经使用 GET 请求验证通过 POST 请求上传的内容。但我意识到我已经使用其他请求测试了一个请求。换句话说，我的测试在大多数情况下都是相互依赖的。由于这种情况，每当我更改 API 规范时，我经常不得不更改所有间接受影响的测试。

例如，

testGetA() =>
    expect(app.get('/A')).to.have.json('this', '{"foo":"bar"}')
testPostA() => {
    expect(app.delete('/A')).to.have.status(200)
    expect(app.post('/A', '{"foo":"bar"}')).to.have.status(200)
    expect(app.get('/A')).to.have.json('this', '{"foo":"bar"}')
}

testPostA 按顺序使用 DELETE、POST 和 GET 来测试发布 resource A。但是，如果我更改 GET /A 的规范，以便 GET /A 响应 {"foo":"barzoo"}，我不仅必须更改 testGetA，而且还必须更改 testPostA。

Answer 1

对于 HTTP REST API 的单元测试，如果 POST 请求 returns 200 OK，我认为您不需要通过 GET。 HTTP API 单元测试的目的是验证客户端和服务器之间的通信，而不是验证服务器端逻辑（例如发布的数据是否存储在数据库中）。

这里有一些详细的原因：

如果 POST /A 100% 有效但 GET /A 仅在 90% 的情况下有效（由于某些服务器端错误），将会发生什么。在这种情况下，POST /A的测试用例有时会失败，这没有任何意义。
如果POST /A的服务器端逻辑只将数据保存在一个全局变量中然后return 200 OK会发生什么？（此行为是错误的，因为第二个 POST /A 请求将覆盖第一个请求）。在这种情况下，你的POST-GET验证会通过，但显然它不能保证任何服务器端逻辑。
因为测试用例取决于服务器端状态。多个测试执行之间，或多个测试用例之间会发生冲突，当测试用例数量增加时会变得非常复杂。

总而言之，HTTP 的单元测试API 和服务器端逻辑的单元测试是两回事。最好让 HTTP API 测试只关注通信（如果 POST /A 请求以正确的格式发送，它应该得到 200 OK。如果格式错误，它应该得到 400 BAD REQUEST等），让服务端逻辑测试以逻辑为主。

我是否应该在发出 POST 请求后验证发布的内容？

Should I verify the posted contents after making a POST request?

testing

rest

bdd

http