在测试 API 时编写用于验证数据库条目的测试代码答案

【问题标题】：Writing test code for verifying database entries when testing an API在测试 API 时编写用于验证数据库条目的测试代码
【发布时间】：2023-04-04 03:45:01
【问题描述】：

我正在编写测试代码来测试客户端-服务器应用程序。被测应用程序由

我基本上是在编写使用此客户端 API 连接到服务器的测试代码。

除了广泛测试 API 操作之外，我的上级还建议我连接到服务器上的数据库并验证字段是否正确填充。我已经为我的一些测试用例做到了这一点，但它在回归期间并没有真正发现任何错误。

当特定功能失败时会发现错误，但无论如何都会在测试 API 本身的代码中显示出来。似乎数据库数据验证并不是真正有用，尤其是考虑到编写和维护所有代码所需的额外工作。

我的问题是：

以这种方式编写用于连接数据库和验证条目的测试代码有什么真正的好处吗？编写此类代码所产生的成本是否得到回报？

【问题讨论】：

【解决方案1】：

此类测试不需要读取数据库。您可以通过以下测试获得更好的结果：

如果您测试数据库内容，您的测试不能用于查看数据库中的更改是否有效，因为测试期望数据库中的某个状态。如果更改此设置，即使系统正常工作，您的测试也会失败。

【讨论】：

【解决方案2】：

查看数据库可能会发现错误，但可能性不大，所以我会尽量减少对数据库的检查。只要 API 正确保存和恢复数据，您就不必真正关心它是如何存储的。

您可以检查数据库，但我个人不会系统地这样做。

您问的问题是正确的，测试的目的是发现错误。您在此测试中发现了多少错误？

自动化回归测试有时被认为是免费的，但如果您需要不断更新测试，那就不是了。

如果您对必须维护这些测试不满意，我会记录您花在这些测试上的时间，然后您可以争辩说您可以做更有成效的工作，进行其他形式的测试，或者发展。

【讨论】：

【解决方案3】：

通过此类测试，您可以验证数据库的内容。其他测试只验证 API 操作，而不验证结果到数据库中。

【讨论】：

重点是，在我使用 API 发送一些数据后，我使用 API 调用自己来检索大部分数据，然后验证我得到了什么。不过，感谢您的回答。
但这是一次测试多个级别，而不是逐级测试。从 API 开始，将一些东西放入 API 并检查数据库中的结果。然后从数据库中获取一些东西并通过 API 将其返回。这些至少是您可以测试的两个级别，我认为您应该测试。
这可能是一个好点......但它不是真的被 API 测试覆盖了吗？如果遵循 jmz 概述的步骤，API 最终将返回相同的数据。对我来说，这两个级别的测试感觉就像以两种不同的方式执行相同的测试，其中一种方式（API 方式）是另一种方式的超集。

【解决方案4】：

要求 API 进行自我验证就像询问某人是否诚实，让他们回答“因为我是诚实的”并接受这一点。这是循环推理。有没有办法摆脱这个循环？正确性未经过彻底测试的结果让我感到不安。

【讨论】：