如何使用 SpecFlow、Cucumber 或其他 BDD 验收测试框架在不同的测试类型之间进行选择？
我正在查看 SpecFlow 示例，它的 MVC 示例包含多种测试替代方案：
- 基于验证控制器生成的结果的验收测试；
- 使用 MvcIntegrationTestFramework 进行集成测试；
- 使用 Selenium 进行自动化验收测试；
- 当提示测试人员手动验证结果时进行手动验收测试。
我必须说，SpecFlow 示例的编写程度给我留下了深刻的印象（我在下载后几分钟内就成功运行了它们，只需配置数据库并安装 Selenium 远程控制服务器）。看看测试替代方案，我可以发现它们中的大多数是相互补充的，而不是替代的。我可以想到这些测试的以下组合：
- 控制器以 TDD 风格进行测试，而不是使用 SpecFlow（我相信 Give/When/Then 类型的测试应该应用于更高的端到端级别；它们应该提供良好的代码各个组件的覆盖率；
- 在开发会话期间运行集成测试时，MvcIntegrationTestFramework 非常有用，这些测试也是日常构建的一部分；
- 尽管基于 Selenium 的测试是自动化的，但它们速度很慢，并且主要在 QA 会话期间启动，以快速验证页面和站点工作流程中没有损坏的逻辑；
- 当提示测试人员确认结果有效性时，手动验收测试主要是为了验证页面外观。
如果您在 Web 开发中使用 SpecFlow、Cucumber 或其他 BDD 验收测试框架，您可以吗？请分享您在不同测试类型之间进行选择的做法，
提前致谢。
I am looking at SpecFlow examples, and it's MVC sample contains several alternatives for testing:
- Acceptance tests based on validating results generated by controllers;
- Integration tests using MvcIntegrationTestFramework;
- Automated acceptance tests using Selenium;
- Manual acceptance tests when tester is prompted to manually validate results.
I must say I am quite impressed with how well SpecFlow examples are written (and I managed to run them within minutes after download, just had to configure a database and install Selenium Remote Control server). Looking at the test alternatives I can see that most of them complement each other rather than being an alternative. I can think of the following combinations of these tests:
- Controllers are tested in TDD style rather than using SpecFlow (I believe Given/When/Then type of tests should be applied on higher, end-to-end level; they should provide good code coverage for respective components;
- MvcIntegrationTestFramework is useful when running integration tests during development sessions, these tests are also part of daily builds;
- Although Selenium-based tests are automated, they are slow and are mainly to be started during QA sessions, to quickly validate that there are no broken logic in pages and site workflow;
- Manual acceptance tests when tester is prompted to confirm result validity are mainly to verify page look and feel.
If you use SpecFlow, Cucumber or other BDD acceptance test framework in you Web development, can you please share your practices regarding choosing between different test types.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这都是行为。
在给定特定上下文的情况下，当事件发生（在特定范围内）时，应该会发生某种结果。
范围可以是整个应用程序、系统的一部分或单个类。即使函数也以这种方式运行，输入作为上下文，输出作为结果（您也可以将 BDD 用于函数式语言！）
我倾向于在类或集成级别使用 Unit 框架（NUnit、JUnit、RSpec 等） ，因为观众是技术性的。有时我会在评论中记录给定/何时/那么。
在场景层面，我试图找出谁真正想要帮助阅读或编写场景。即使是业务利益相关者也可以阅读包含一些点和括号的文本，因此拥有像 MSpec 或 JBehave 这样的自然语言框架的主要原因是他们想要自己编写场景，或者向那些真正会被这些点推迟的人展示场景和括号。
之后，我将研究框架如何与构建系统配合使用，以及我们如何为感兴趣的利益相关者提供适当的读写能力。
这是我编写的示例来展示您可以在使用简单 DSL 的场景中执行此类操作。这只是用 NUnit 编写的。
以下是同一代码库中的示例，显示给定, When, then 在类级示例注释中。
我抽象了后面的步骤，然后将屏幕或页面放在这些步骤后面，然后在屏幕和页面中我调用我正在使用的任何自动化框架 - 可以是 Selenium、Watir、WebRat、Microsoft UI Automation 等。
我提供的示例本身就是一个自动化工具，因此这些场景通过演示假 GUI 的行为来演示自动化工具的行为，以防引起混淆。无论如何希望它有帮助！
It's all behaviour.
Given a particular context, when an event occurs (within a particular scope), then some outcome should happen.
The scope can be a whole application, a part of a system or a single class. Even a function behaves this way, with inputs as context and the output as outcome (you can use BDD for functional language as well!)
I tend to use Unit frameworks (NUnit, JUnit, RSpec, etc.) at a class or integration level, because the audience is technical. Sometimes I document the Given / When / Then in comments.
At a scenario level, I try to find out who actually wants to help read or write the scenarios. Even business stakeholders can read text containing a few dots and brackets, so the main reason for having a natural language framework like MSpec or JBehave is if they want to write scenarios themselves, or show them to people who will really be put off by the dots and brackets.
After that, I look at how the framework will play with the build system, and how we'll give the ability to read or write as appropriate to the interested stakeholders.
Here's an example I wrote to show the kind of thing you can do with scenarios using simple DSLs. This is just written in NUnit.
Here's an example in the same codebase showing Given, When, Then in class-level example comments.
I abstract the steps behind, then I put screens or pages behind those, then in the screens and pages I call whatever automation framework I'm using - which could be Selenium, Watir, WebRat, Microsoft UI Automation, etc.
The example I provided is itself an automation tool, so the scenarios are demonstrating the behaviour of the automation tool through demonstrating the behaviour of a fake gui, just in case that gets confusing. Hope it helps anyway!
由于验收测试是一种功能测试，因此总体目标是用它们端到端地测试您的应用程序。另一方面，您可能需要考虑测试自动化的效率（实现测试自动化需要付出多少努力）、可维护性、性能和可靠性。同样重要的是，测试自动化可以轻松地融入开发过程，以便它支持一种“测试优先”方法（支持由外向内的开发）。
因此，这是一种权衡，每种情况都可能有所不同（这就是我们提供替代方案的原因）。
我非常确定，当今最广泛适用的选项是在控制器层进行测试。 （也许以后随着 UI 和 UI 自动化框架的发展，这种情况将会改变。）
Since acceptance tests are a kind of functional tests, the general goal is to test your application with them end-to-end. On the other hand, you might need to consider efficiency (how much effort is to implement the test automation), maintainability, performance and reliability of the test automation. It is also important that the test automation can easily fit into the development process, so that it supports a kind of "test first" approach (to support outside-in development).
So this is a trade off, that can be different for each situation (that's why we provided the alternatives).
I'm pretty sure, that today the most widely fitting option is to test at the controller layer. (Maybe later as UI and UI automation frameworks will evolve, this will change.)