You don’t need to callback cucumber-js, but it will call you… i promise

Although it’s documented on it wasn’t clear to me what the best is to deal with callbacks in step definitions. After working with cucumber-js for a while it is now clear. So let me share my experiences with you in this area.

Basically there 3 ways of handling steps in a scenario:

  1. Use the callback given as the last parameter
  2. Return a A+ promise 
  3. None of the above

Let’s say we have the following scenario:

When you run it for the first time and have not implemented any of the steps you will get the following snippits:

As you can see the default behavior is a callback. So it is easy to implement the Give to set up the stage.

Now usually the When step involves some kind of back-end call and promises are a common way to handle this.
The great thing is that we can you return a promise as-is, but the catch here is to remove the callback from the arguments. There is some magic going on there and if you leave it in you won’t go to the next step and the whole process will keep hanging. I found myself using console.log quite a few times.

In the Then step we assert the outcome the promise by getting the state (for example). Also here we don’t need the callback, because if our assertion fails it will throw an error and your scenario failed. Otherwise it can carry on silently like the documentation indicates.

Now to be honest this made the experience of using cucumber-js a lot better. It is a very good tool to have in my daily work and hope this article will help you in that area as well.

One last thing… All of the above can also be achieved with only callbacks, however this makes the step definitions a whole lot messy-er and that’s bad when your projects grows bigger.

Use sinon.js to easily write stubs for your BDD features in cucumber.js

While using BDD to optimize our current teams workflow there is all kinds of stuff we learn. BDD really drives better software. One of first lessons learned was to separate concerns and that Cucumber.js is certainly not limited to automated testing using selenium etc.

Good learning’s about that came from Jan Stenberg article about BDD/cucumber and for me it helped to reset the reasons why with started walking on this path in the first place.

Currently we are building a dashboard to monitor the health of ad delivery. In the beginning we had a lot of business rules in our Polymer front-end however the BDD features we had described drove naturally towards a more back-end centered application.

Suddenly our development cycle was on steroids, because the only selenium tests we had were limited to some basic behavior when fed a data structure. Our ‘real’ features could now be executed on the API to validate the expected behavior.

The thing I would to share with you today is the hook we made for stubbing some our interfaces.

Now in your step definitions you can stub the interface without worrying about restoring your stubs. All sinon.js stubs are wrapped into this small hooks.

Hope you will find this useful. We certainly do!