I wanted to share two significant updates to the cypress-cucumber-preprocessor tool that were released over this weekend.
UPDATE #1 - Smart @focus
First update is the @focus functionality, that mirrors what people knowing chimp (currently chimpy - http://github.com/TheBrainFamily/chimpy) got to use and love. It’s very straightforward - put a @focus on the scenario (or scenarios) you want to focus on while development or bug fixing.
Take a look at this gif that shows it in action:
As you can imagine, the ability to focus will speed up the productivity tremendously, by shortening the feedback loop. Please let us know what you think about this feature and whether you are able to incorporate it into your everyday workflow.
UPDATE #2 - New proposed folder structure.
First of all - I believe I can proudly call our users a community now. We grew from 1.5k installs a week to over 7k a week, in 5 months! We have had some great contributions, discussions, and because of all the people the tool matured tremendously in this time period. So - thank you guys so much, and welcome aboard! Cypress is such a fantastic tool, it’s great to be able to use Cucumber ideas with it.
One of the recurring questions in this community was around hooks. People have been able to use all the mocha hooks, but, with the way cucumber treats the step definiton files is that everything becomes global. You can either create hooks to start before ALL tests, or EACH scenario, but you couldn’t create a hook that would work for only a particular .feature. The way this is taken care of in pure cucumberjs is tags, and hooks per tags. Personally I feel like tags like that introduce the ratio of noise to the signal a bit too much. They make the .feature files less readable and more scary to the non-programmer side of the equation. Which is against the purpose of the tool.
I personally have many years of experience working with cucumber tests. I’ve worked on a few applications with over thousand cucumber steps, which caused us to have a countless number of feature and step definition files. Once you get to that level of scale having everything global starts to seem more and more like an anti-pattern, for the same reasons we don’t like to have global things in our code.
I wondered what would be a better, non-global way. We came up with the idea of .feature file only looking for step definitions ONLY from:
- it’s closest surrounding (children)
- shared folder with common steps (I imagine mostly for Given steps, like setting up a user authentication/authorization, or bootstrapping the app with some common data)
You can take a look how it looks like in code at (cypress-cucumber-example) but here is the gist:
I have GoogleNews.feature open. When you run it, the plugin looks for the step definitions in two places:
CYPRESS_INTEGRATION_PATH/common/*.js (typescript also supported!)
- we don’t have to worry about step definition collisions. Sometimes you DO want to name the step the same way as it was named in some other test. But the name is taken, and you have fallback to some other, less fitting name. Against the programmers intuition - you do want to LIMIT the reusability between different features. They are not code. They are a human-readable documentation. If your feature files are full of “I click this” and “I see this” you are in a wrong place - you should probably use cypress directly. Gherkin should NOT talk about UI layer. This is a common misconception. Your feature in 95% of cases has nothing to do with the UI. UI is an implementation detail. Feature description should be high level and make sense no matter if you are creating a feature to work with a web app, Alexa, or even a phone call. To be honest - this is not always easy or doable, but this should be your direction. Please ping me if you disagree or if you want to learn more about our thinking.
- and finally - we can create per feature hooks easily! Just create a file in the folder assigned to the particular l
feature and you are good to go. (take a look at ./GoogleNews/beforeEach.js)
We want the preprocessor to tell you when it can't find step definitions related to your steps. It will fail the test (or skip it), and hopefully print out a pre-filled template for the missing step definitions so you can copy/paste them to your codebase. Currently it just brakes.
There is also a number of open issues on github. If any of them resonates with you, please comment, or make a PR. We will try to prioritize.