Meteor-cucumber/chimp 的步骤定义库 [英] Step definitions library for Meteor-cucumber/chimp
问题描述
我正在寻找 Meteor-cucumber\chimp 的预定义(通用)步骤定义.
我使用了 PHP 的 Behat(BDD 黄瓜框架).有这个
简短回答
这种 step-def 库不存在，我们(Chimp 的作者)不会添加它们，因为我们已经看到从长远来看它们是非常有害的.
看起来您想要编写测试脚本，在这种情况下，您最好将 Chimp 与 Mocha + Customer WebdriverIO 命令一起使用，而不是 Cucumber 来编写这些脚本.
长答案
具有简单语言场景和步骤的功能文件旨在发现和表达您的应用程序的领域.自然的自由格式文本鼓励您使用整个团队都可以使用的语言 - 也称为无处不在的领域语言.
当涉及到 Cucumber 时，您想犯最常见的错误之一，那就是将其用作 UI 测试工具.使用基于 UI 的步骤打破了无处不在的语言原则.
步骤重用应该围绕业务领域，以便您创建无处不在的领域语言.如果你使用 UI 步骤而不是规范，你最终会在不知情的情况下产生技术债务.Gherkin 语法不容易重构，如果您更改步骤实现，则需要在多个地方进行更新.对于领域问题，这通常不是什么大问题，但对于 UI 测试，您可能会大量重复使用步骤.
听起来您对良好的代码重用感兴趣.如果你仔细想想，WebdriverIO 已经有一个很棒的 API，你想要使用的大部分步骤只是围绕 API 的包装器.
与其创建这种无关紧要的翻译，您应该只使用 Mocha 来编写测试并直接访问 WebdriverIO 的 API.这样，您就可以使用完整的 JavaScript 语言来使用一些软件工程实践，而不是简单的 Gherkin 解析器.
WebdriverIO 还有一个很棒的自定义命令 命令，它允许您创建所有你上面提到的方法.添加大量这些脚本的扩展文件将非常有用.
我们编写了一个包含最佳实践和一些注意事项的知识库.特别是，您应该看到:
您可能还想阅读:
Hi I am looking for predefined (common) step definitions for Meteor-cucumber\chimp.
I used PHP's Behat (BDD cucumber framework). There is this extensions and this class. Which allows you to have a common step definitions out of the box. You don't need to write those step definitions by yourself.
Down below it is the list of step definitions you got from Behat.
Short Answer
This sort of step-def library doesn't exist and we (the authors of Chimp) won't be adding them because we have seen they are very harmful in the long run.
It looks like you are wanting to write test scripts, in which case, you would be better off using Chimp with Mocha + Customer WebdriverIO commands and not Cucumber to write these.
Long Answer
Features files with plain language scenarios and steps are intended to discover and express the domain of your application. The natural freeform text encourages you to use language that you can use with the entire team - otherwise known as the ubiquitous domain language.
You are wanting to make one of the most common mistakes when it comes to Cucumber, and that is to use it as a UI testing tool. Using UI based steps breaks the ubiquitous language principle.
The step reuse should be around the business domain so that you create a ubiquitous domain language. If you use UI steps instead of specs, you end up creating technical debt without knowing it. Gherkin syntax is not easy to refactor and if you change your step implementations, you need to update in multiple places. For domain concerns, this is usually not a big issue, but for UI tests, it's likely you will heavily reuse steps.
It sounds like you are interested in good code reuse. If you think about it, WebdriverIO already has a great API and most of the steps you are wanting to use would just be wrappers around the API.
Rather than create this extraneous translation, you should just Mocha to write the tests and access WebdriverIO's API directly. This way, you have the full JavaScript language to employ some software engineering practices instead of the simplistic Gherkin parser.
WebdriverIO also has a great custom commands command that allows you to create all of the methods you have mentioned above. An extension file that adds a ton of these scripts would be VERY useful.
We have written a repository with best practices and some do's and don'ts lessons. In particular, you should see:
- Lesson #1: Test Scripts !== Executable Specifications
- Lesson #2: Say No To Natural Language Test Scripts
You might also want to read:
这篇关于Meteor-cucumber/chimp 的步骤定义库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
