编写测试代码以在测试 API 时验证数据库条目
我正在编写测试代码来测试客户端服务器应用程序。被测应用程序由在
- Tomcat 上运行的应用程序 组成 或另一个 Java EE 应用程序服务器，以及
- 公开 API 的客户端 jar。
我基本上正在编写使用此客户端 API 连接到服务器的测试代码。
除了广泛测试 API 操作之外，我的上级还建议我连接到服务器上的数据库并验证字段是否已正确填充。我已经为我的一些测试用例做到了这一点，但在回归过程中它并没有真正发现任何错误。
当特定功能失败时，错误就会被捕获，但无论如何，这些错误都会在测试 API 本身的代码中暴露出来。看来数据库数据验证并不是真正有用，特别是考虑到编写和维护所有代码所需的额外工作。
我的问题是：
编写用于连接到数据库并以这种方式验证条目的测试代码有什么真正的好处吗？这些好处是否能抵消编写此类代码所产生的成本？
I'm writing test code to test a client-server application. The application under test consists of
- an application that runs on Tomcat
or another Java EE application server, and - client jars that expose an API.
I'm basically writing test code that uses this client API to connect to the server.
In addition to extensively testing the API operations, my superiors have advised me to connect to the database on the server and verify that fields are being populated properly. I have done that for some of my test cases, but it hasn't really caught any bugs during regression.
Bugs are caught when a particular functionality fails, but that anyway gets revealed in the code that tests the API itself. It seems that DB data verification is not really useful, especially considering the extra effort required to write and maintain all that code.
My question is:
Is there any real benefit to write test code for connecting to the DB and verifying entries in this manner? Do the benefits pay off for the costs incurred in writing such code?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
此类测试不需要读取数据库。您可以通过测试获得更好的结果：
如果您测试数据库内容，则您的测试不能用于查看数据库中的更改是否有效，因为测试期望数据库中存在某种状态。如果更改此设置，即使系统正常工作，您的测试也会失败。
Reading the database is unnecessary for such tests. You can achieve better results by testing that:
If you test the database contents, your test cannot be used to see if a change in the database works, because the tests expect a certain state in the database. If this is changed, your tests fail, even if the system works.
查看数据库可能会发现错误，但可能性不大，因此我会将数据库检查保持在最低限度。只要 API 正确保存和恢复数据，您并不真正关心它是如何存储的。
你可以检查数据库，但我个人不会系统地这样做。
您提出了正确的问题，测试的目的是发现错误。通过这次测试您发现了多少错误？
自动化回归测试有时被视为免费的事情，但如果您需要不断更新测试，那么事实并非如此。
如果您对维护这些测试感到不满意，我会记录您花费了多少时间来做这件事，然后您可以争辩说您可以做更有成效的工作，进行其他形式的测试或开发。
Looking at the database may find bugs, but it's not very likely, so I would keep the checking of the database to a minimum. As long as the API saves and restores data correctly, you don't really care how it has been stored.
You can check the database, but personally I would not do this in a systematic way.
You're asking the right questions, the purpose of testing is to find bugs. How many bugs have you found with this testing?
Automated regression testing is sometimes looked upon as a no-cost thing, but if you're continually having to update the tests then it isn't.
If you're unhappy at having to maintain these tests, I would record how much time you're spending doing it, and then you can argue that you could be doing more productive work instead, doing other forms of testing, or development.
通过此类测试，您可以验证数据库的内容。其他测试仅验证 API 操作，而不验证数据库中的结果。
With such kind of tests you are verifying the content of the database. The other tests only verify the API operations but not the results into the DB.
要求 API 进行自我验证就像询问某人是否诚实并让他们回答“因为我很诚实”并接受这一点。这是循环推理。有办法跳出这个循环吗？接受未经彻底测试正确性的结果让我感到不安。
Asking an API to verify itself is like asking someone if they are honest and having them answer "because I am honest" and accepting that. It is circular reasoning. Is there a way out of this loop? It makes me feel uneasy to accept the results of something whose correctness has not been thoroughly tested.