【发布时间】：2014-04-08 08:45:26
【问题描述】：
测试端点的结果很简单。
但是，如果（即）我发布的数据被正确保存，我不应该也看看 db 层吗？我不清楚如何/是否应该测试 REST 调用背后的业务逻辑。
【问题讨论】：
标签： unit-testing testing tdd integration-testing
【发布时间】：2014-04-08 08:45:26
【问题描述】：
在我的完美世界中（有一天我想住在那里...）有几个不同的测试涉及完全验证我提供的 RESTful 服务。
应用程序的每个逻辑层都有单元测试，它们使用依赖注入来模拟下一个较低层并验证每个单元是否正常工作。这可能是一个编组/解组参数和响应的单元，一个执行业务逻辑的单元，以及一个管理持久性的单元。 （可能有多个单元，每个单元在每一层都有自己的测试。）这些测试在测试框架之外没有依赖关系，除了必须执行持久性实现的持久层。
还有需要运行系统的集成测试。这是您调用正在运行的服务的地方，并验证您是否获得了预期的响应。您还可以检查通话的副作用。在我的团队中，我们经常通过根据第一次调用的结果进行不同的服务调用（或调用）来做到这一点。这锻炼了更多的系统。我们发现，直接检查持久层的副作用很少能告诉我们很多我们无法通过使用不同的服务调用获得的信息。
【讨论】：
是的，您应该在某个时候测试 db 层，但可能不在与测试端点结果的单元测试相同的单元测试中。
在单元测试级别，您希望进行小型/快速/独立测试，因此您最终可能会得到一个用于 REST 部分的测试/套件和另一个专注于 db 层的测试/套件。
然后你可能会有更多的集成/端到端测试来检查整个系统：执行请求并检查数据库是否正确更新。
我自己作为 QA 工作的经验是，涉及 DB 的测试是通过集成/端到端测试完成的，QA 使用第三方工具从功能角度进行（我们为此使用 Robot Framework )。
【讨论】：
-
REST 调用不是真正意义上的“端到端”测试吗？
-
当然。我从测试人员的角度使用它，试图传达这样一个想法，即对于这样的测试，我们不仅会检查服务器返回的 JSON，还会检查系统其他部分的预期结果（比如“在这个表中添加了一个用户那个分贝”）
一种方法是使用 restful 服务本身来测试数据是否正确持久化，
例如，您可以使用 PUT 消息来持久化一个实体并使用 GET 操作来检索它，并确保所有属性都相等。这更像是一个涵盖端到端的集成测试。
尤其是您的应用程序正在执行更多的 CRUD 操作，如果您使用这种方法，您可以避免为每一层（例如存储库）创建测试
【讨论】：