CucumberStudio | #1 BDD Collaboration Tool

Introduction

In this tutorial, we’ll see how to use the sample project called “Coffee machine – CucumberStudio publisher samples”.

To follow this tutorial, you’ll need a few pre-requisites:

a CucumberStudio account
a GitHub account
a Travis CI account
a computer setup to execute tests (you will be able to choose your preferred language later on)
a text editor (and preferably a code editor)
git installed on your machine
hiptest-publisher installed on your machine

A quick word on the system under test

For this tutorial, we’ll be testing an automated expresso machine. Sadly, there is no real coffee provided by it, just plain code.

Originally, this project was meant to test the exports done by hiptest-publisher in any language supported. Later on, we decided to open the project to every user so everyone could also easily try the exports.

When you have a look at the project in CucumberStudio, you can see it is following the Behavior Driven Development standards (each feature is represented as a folder, we use the Gherkin syntax and declarative scenarios). This is not a pre-requisite for automation, just a preference of the development team.

Step one – Getting the project

Login to CucumberStudio and go to the projects list. On the left menu click on , select the Example projects section, then select Coffee machine to generate the project.

A few seconds later, you will see a new project in your list called “Coffee machine – CucumberStudio publisher sample“.

Open the Github repository “CucumberStudio publisher samples”. There, you will have access to multiple repositories links named “hps-<language>-<framework>”. Pick the language and test framework you want to try out and click on the link to the repository.
For example, if you want to try Python and UnitTest, click on the “hps-python-unittest” link:

python repositories for Hiptest publisher samples

In the repository you have selected, click on the Fork button located in the top-right corner:

Hiptest fork repository

You should now own a copy of the repository, named “<your Github username>/hps-<language>-<framework>”.

Open a terminal on your machine and clone the newly created repository.

Note: if you have just installed Git for this tutorial, there are chances you will not be able to clone using SSH. You can try this command:

git clone

https://github.com/<your

 GitHub username>/hps-<language>-<framework>.git

Step two – Configuring the code to use your CucumberStudio project

Currently, the code you have forked does not point to the sample project you generated earlier (in fact, nothing in its settings points to a specific CucumberStudio project). We have to fix that to make the code on your machine point to the Coffee machine you generated in the first step.

Inside the CucumberStudio project, go to the Project Settings panel. At the bottom of the page, you can see a section named Test code generation containing a secret token. Copy this token:

Copying the Hiptest token

Now open the hiptest-publisher configuration file on your machine. This file should be called “<language name>-<framework name>.conf” (or sometimes simply <framework name>.conf).
Add the line “token = <your secret token>” in this configuration file and save it:

Now, we are going to use hiptest-publisher to regenerate the actionwords.yaml file. This file is used to match the current status of the action words inside your CucumberStudio project.
To update it, run the following command:

hiptest-publisher -c <path to the config file> --actionwords-signature

The output should look something like that:

Before committing the changes we just made, let’s check if our tests are still working. First, we have to update the test files by running one of those command (you can also check the README.md file, the exact command line should be provided in the “Update tests” section):

hiptest-publisher -c  <path to the config file> --without=actionwords

This will give you this kind of output (once again the filenames will differ depending on the framework you have chosen):

Potentially, we will see some minor differences in the generated test files by running “git diff” (for example new tags being added) but no changes in the core idea of the tests themselves.

Step three – Running the tests locally

In the README.md file of your repository, a section called “Run tests” provide a commands list to execute to run the tests.

For example, here’s what need to be done when using Python/UnitTest:

python bootstrap.py
bin/buildout
bin/test --with-xunit

Note that, in most cases, the first commands are just there for setup (fetching libraries etc.) and you do not need to run them every time.
Once you run the commands, you should get an output similar to this:

Now your tests are working fine, commit all your changes but do not push them to Github yet, as we first have to setup the CI.

Step four – Setting up the CI

Go to Travis-CI and sign-in (or sign up) using your GitHub account. Open your profile and activate the GitHub Apps Integration to link GitHub repositories with Travis CI. Look for the repository you forked earlier and activate Travis CI for it:

You can change Travis-CI activated repositories at any time by clicking on the “Manage repositories on GitHub” button.

After activating the repository and clicking on its name, you should access a page telling “No builds for this repository”.

Go back to your CucumberStudio project and click on the Test runs section. You already have a test run called CI there, open it and copy its ID:

Now open the file called .travis.yml. This file is the config file for the CI and is currently pointing to another test run than yours.
You should see two commands lines starting with “hiptest-publisher”. In those lines, replace the test run id with the one of your test run and remove the “––token=$SECRET_TOKEN” part.

Running the command “git diff” should output something close to that:

Commit those changes too and push all the commits to GitHub. Now open again the Travis CI page for your repository and wait for all the tests to run:

A few seconds later, the test run pie-chart in CucumberStudio should also turn all green as the results for each test has been updated:

Tests updated in Hiptest

One last thing to do, update the badge in the README.md file to show the status for your own repository. In Travis CI, click on the “build passing” badge next to your repository name and in the pop-up, select the markdown format:

Copy the given code and replace the existing one in the README.md file. Commit that last change and push it to Github.

Wrap up

As you can see after this tutorial, integrating CucumberStudio and a CI tool is a pretty fast operation. Of course, in the case of this tutorial, the hardest part (implementing the action words) was done previously but you now see how to quickly integrate your CucumberStudio project in your CI process.

In a next blog post, we’ll see how to manage the creation of new scenarios in the project, handle refactoring and upgrade the action words so the code match the definitions in CucumberStudio.