进行自动验收测试来测试字段是否保存到数据库是否重要？
我使用 SpecFlow 来实现自动化验收测试框架，使用 NHibernate 来实现持久性。我正在开发的 Intranet 应用程序的许多 UI 页面都是基本数据输入页面。 之外，我想不出此功能的任何场景
Given that I enter data X for field Y on Record 1
And I click Save
When I edit Record 1
Then I should data X for field Y
显然，向这些页面之一添加字段被认为是一种“功能”，但除了自动化这样的测试有多常见和必要 ？此外，我正在使用 NHibernate，所以这不像我在手动处理我自己的数据持久层。一旦我将属性添加到映射文件中，它很可能不会被错误删除。考虑到这一点，“一次性”手动测试还不够吗？我渴望听到您在这件事上的建议和经验。
I'm using SpecFlow for the automated Acceptance Testing framework and NHibernate for persistance. Many of the UI pages for an intranet application that I'm working on are basic data entry pages. Obviously adding a field to one of these pages is considered a "feature", but I can't think of any scenarios for this feature other than
Given that I enter data X for field Y on Record 1
And I click Save
When I edit Record 1
Then I should data X for field Y
How common and necessary is it to automate tests like this? Additionally, I'm using NHibernate so it's not like I'm handrolling my own data persistance layer. Once I add a property to my mapping file, there is a high chance that it won't get deleted by mistake. When considering this, isn't a "one-time" manual test enough? I'm eager to hear your suggestions and experience in this matter.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我通常会有类似“成功创建...”这样的场景来测试成功案例（您填写所有必填字段，所有输入都有效，您确认，最后真的保存了）。
我认为您无法轻松地为一个字段定义单独的场景，因为通常成功创建的场景需要“同时”满足多个其他标准（例如，必须填写所有必填字段）。
例如：
稍后我可以向此场景添加其他字段（例如帐单地址）：
当然，可以有更多与新字段相关的场景（例如验证等），您必须定义或扩展它们。
我认为如果你采取这种方法，你可以避免出现很多“琐碎”的场景。我可以说，这是“创建客户功能”的成功案例，至少值得进行一次测试。
I usually have scenarios like "successful creation of ..." that tests the success case (you fill-in all required fields, all input is valid, you confirm, and finally it is really saved).
I don't think that you can easily define a separate scenario for one single field, because usually the scenario of successful creation requires several other criteria to be met "at the same time" (e.g. all required fields must be filled).
For example:
Later I can add additional fields to this scenario (e.g. the billing address):
Of course there can be more scenarios related to the new field (e.g. validations, etc), that you have to define or extend.
I think if you take this approach you can avoid having a lot of "trivial" scenarios. And I can argue that this is the success case of the "create customer feature", which deserves a single test at least.