CODEWITHSUNDEEP
meteorwebdriver-iometeor-cucumber
Jirik
Jirik

Reputation: 1502

Step definitions library for Meteor-cucumber/chimp

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.

behat -dl

Upvotes: 0

Views: 1076

Answers (2)

Jirik
Jirik

Reputation: 1502

To test my UI I will use Mocha. I don't need cucumber specs.

As a task runner I will use Chimp (Chimp uses webdriver.io).

Here is quick Mocha+Chimp how to.

Upvotes: 0

Xolv.io
Xolv.io

Reputation: 2533

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:

You might also want to read:

Upvotes: 4

Related Questions