编写集成测试来测试数据库、Web 服务调用
我们刚刚开始编写集成测试来测试数据库、数据访问层、Web 服务调用等。 目前我有一些想法来编写集成测试,例如 1)总是在初始化函数中重新创建表。 2) 如果您在同一函数内保存新数据,请务必清除函数内的数据。
但我想知道更多好的做法。
We are just starting to write integration tests to test database,data access layer, webservice calls etc.
Currently I have some idea to write integration tests like
1) Always recreating tables in initialize function.
2) Always clear the data inside a function, if you are saving new inside the same function.
But I would like to know some more good practices.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
与所有测试一样,必须从已知状态开始,并在测试完成后清除到干净状态。
此外,测试代码经常被忽视,因为它不是真正的代码,因此没有得到正确的维护......它比代码更重要。至少应将同样多的设计纳入测试架构中。规划合理的抽象级别,即,如果您正在测试 Web 应用程序,请考虑采用这样的层:浏览器交互的抽象、页面上组件的抽象、页面和测试的抽象。测试与页面和组件交互,页面与组件交互,组件与浏览器交互层交互,浏览器交互层与您的(可能是第三方)浏览器自动化库交互。
如果您的测试代码没有得到正确维护或考虑周全,它们就会成为编写新代码的障碍而不是帮助。
如果您的团队是测试新手,那么有许多编码套路可以实现这一目标为了教导良好测试的重要性(并由此产生良好的代码),他们通常专注于单元测试级别,但许多原理是相同的。
As with all testing, it is imperative to start from a known state, and upon test completion, clear down to a clean state.
Also, test code often gets overlooked as not real code and hence not maintained properly... it is more important than code. At least as much design, should go into the architecture of your tests. Plan reasonable levels of abstraction, ie if you are testing a web app, consider having tiers like so: an abstraction of your browser interaction, an abstraction of your components on pages, an abstraction of pages and your tests. Tests interact with pages and components, pages interact with components, components interact with the browser interaction tier and the browser interaction tier interacts with your (possibly third party) browser automation library.
If your test code is not maintained properly or well-thought out, they become a hindrance more than an aid to writing new code.
If your team is new to testing, there are many coding katas out there that aim to teach the importance of good tests (and out of this comes good code), they generally focus on a unit testing level, however many of the principals are the same.
一般来说,我建议您考虑模拟数据库访问层和 Web 服务调用类,以使其更具可测试性。有很多关于这个主题的书,比如 Osherove 的《单元测试的艺术》。
话虽如此,集成测试应该是可重复的。因此,我会选择选项 1,编写一个可以使用测试数据从头开始重新创建数据库的脚本。选项 2 更困难,因为很难确定清理功能不会留下不需要的数据残留。
In general, I would suggest you look into mocking your database access layer and web service call classes in order to make it more testable. There are lots of books on this subject, like Osherove's The Art of Unit Testing.
That having been said, integration tests should be repeatable. Thus, I would choose option 1, to write a script that can recreate the database from scratch with test data. Option 2 is more difficult, because it can hard to be sure that the cleaning function does not leave unwanted data residue.
当对 DAL 进行单元测试时,我这样做:
When unit testing the DAL, I do it like this: