在定义表单输入功能的规范时测试每个边缘情况是否实用？
我开始学习验收测试，并且想使用 SpecFlow 测试 ASP.NET MVC 应用程序。目前我正在为 CRUD 场景编写测试
我知道这完全是一个菜鸟问题，但是在我的 SpecFlow 场景中测试每个边缘情况是否实用？我有一个表格要填写，它有大约 15 个字段，我是否需要测试，例如，“如果字段 A 有效而字段 B 无效，我应该在屏幕上看到此验证消息”？或者写“如果表格填写正确，我应该看到“任务已添加”消息”就足够了？在这种情况下，我应该单独对模型验证进行单元测试吗？ 在此先感谢
I'm starting to learn acceptance testing, and I want to test an ASP.NET MVC app using SpecFlow. Currently I'm writing tests for CRUD scenario
I know it's a completely noobie question, but is it practical to test every edge case in my SpecFlow scenarios? I have a form to fill, it has about 15 fields, do I need to test that, for example, "if field A is valid and field B is not, I should see this validation message on the screen"? Or it should be sufficient to write "if form is correctly filled, I should see "Task added" message"? Should I unit-test model validation separately in this case?
Thanks ahead
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我倾向于在场景或验收测试中寻找比单元测试更高级别的行为。特别是，我正在寻找对用户或其他利益相关者有价值的行为。
在这种情况下，高级行为可以表述为“用户获得有关如何填写表单的反馈”。然后，您可以仅使用一两个示例来说明用户如何获取反馈，并检查是否显示验证消息。
然后，您可以将逻辑放在单元测试中的特定消息中。
验收测试，尤其是当您使用 BDD 场景时，并不是真正的测试。它们是如何使用系统的示例，以便您可以使用这些示例来推动与业务利益相关者的对话，我倾向于以业务利益相关者感兴趣的相同粒度和术语来表达它们。BDD 不是手动测试的替代品，尽管它肯定有助于减轻负担。
I tend to look for higher-level behavior in scenarios or acceptance tests than I do with unit tests. Particularly, I'm looking for behavior that's valuable to users or other stakeholders.
In this case, the high-level behavior might be phrased as "the user gets feedback on how to fill in the form". You can then just use one or two examples of how the user gets that feedback, and check that the validation message appears.
You can then put the logic around the specific messages in a unit test.
Acceptance tests, especially if you're using BDD scenarios, aren't really tests. They're examples of how to use the system so that you can use those examples to drive conversation with your business stakeholders, and I would tend to phrase them in the same granularity and terms that the business stakeholder is interested in. BDD isn't a substitute for manual testing, though it can certainly help to reduce the burden.