Create executable scripts

Using Hiptest publisher as a service

In order to get a quick look at how hiptest-publisher generates executable code, you can use Hiptest publisher as a service. Go to the “Exports” tab of your project and you will see a list of links to quickly download code generated from your project:


After clicking on one of the links, you get a zip file containing two files: one with the scenarios transformed into tests and one containing all the action words (two particular cases: Robot framework exports generates one file for each scenario and Selenium IDE does not have action words. Note that Selenium IDE export has some particularities, check this specific documentation. Extract those files to your existing test folder and add them to your test suite. Then implement the action words and you can start playing your tests. If you followed those guidelines, the action words needing implementation should be easy to find by searching for the tag you defined for the leaf action words.

The Hiptest publisher as a service solution provides a quick way to get your tests as executable code. But if you need to do some customization on the code or ease the integration in a continuous integration process, the best way is to use the hiptest publisher tool.

Using Hiptest publisher

In this part of the documentation, we’ll consider you use a version control system (such as Git or SVN) to version your test code.


hiptest-publisher is the Ruby gem used by hiptest publisher as a service to generate the executable code. It is open-source, so you can freely get and even modify it.

To install it, you first have to install Ruby on a development machine. Then type the command:

gem install hiptest-publisher

Note: for windows user, have a look at this documentation for installing hiptest-publisher

To ensure the tool is correctly installed, type the following command in a terminal:

hiptest-publisher --help

This should give you the list of options used by Hiptest publisher.

Configuring the tool

Even if the tool does not need a configuration file (you can use command line arguments) it is easier to store its configuration in a file. You can download the template for this file from Hiptest. In your Hiptest project, go to the “Exports” tab and unfold “Publish your tests with Hiptest-Publisher”.


Select your favorite language and test framework and click on the link to download the configuration file. Add this file to your application source code. If this is possible with your test framework, create a folder for the Hiptest related tests and store the file in it. If you use a Version Control System like Git, you should add this file to your code repository.

You can edit this file to add some more control on how the tests are generated. Here is a few options that you might need:

  • output_directory = : when set, this will generate the executable code to the given path. This option can be useful if you created a folder specific to your Hiptest tests.
  • split_scenarios = 1: add this to your configuration file if you want to get one file for each scenario. Note: this option is mandatory for Robot framework exports.
  • leafless_export = 1: add this line if you want to have the high level action words interpreted when generating the code. The high level action words will not be generated as code (so you will not have to implement them) but you will not be able to use this option with a test run (so you will not be able to push the results back to Hiptest). Note that this option is mandatory for Selenium IDE export.

Generating the tests

Now that the tool is installed and configured, you simply have to run the following command to generate the test code:

hiptest-publisher -c 

As with Hiptest-publisher as a service, this should generate one or more files for the scenarios and one for the action words. Implement the action word, declare the tests in the test suite and you should be able to run the tests. You should save the generated files in your source code repository too.

Customizing the export

One possibility given by the tool is to override the templates used to generate the code. This can be pretty useful when the outputed code does not match your needs (for example you need an extra import at the scenario level, you want to add some comments, you want to change the name of the test module ….)

To do so, the first step is to create a new folder where you will store the customized templates. For example at Hiptest, we have a subfolder inside the folder where the tests are outputed. Then, in the hiptest-publisher configuration file, add the following line:

overriden_templates = 

Then go to the Github repository of hiptest publisher and find the template you need to override, based on your language and test framework.

For example, at Hiptest, we have overriden the template generating the tests to include some comments and import another module. The original file is located in lib/templates/ruby/scenarios.hbs. We have copied this file in our overriden template and modified it this way:

# encoding: UTF-8
require 'spec_helper'
require_relative 'actionwords'

# Do not modify this file manually, use:
# hiptest-publisher -c spec/features/hiptest4hiptest/hiptest4hiptest.config

describe '{{{ camelize project_name }}}' do
  include HiptestActionwords
{{#each rendered_children.scenarios}}{{{this}}}


Now there is a comment to avoid getting any manual change in it and instead of including Actionwords, we include HiptestActionword(which is our own intermediary layer).

The language used for the template is Handlebars, we chose it as it is pretty easy to understand. If you need any help to customize the template, do not hesitate to contact us via the in-app chat or via the support email.

Customizing multiple versions of a template

To make templates reusable accross multiple languages/frameworks combinations, templates are looked up from multiple directories. The directories to use for lookup are defined in config files.

For exports like Cucumber Java, there can be multiple version of a template with the same name: cucumber/java/actionwords.hbs is used to generate the file, and java/actionwords.hbs is used to generate the file. So overriding actionwords.hbs would impact both and files.

The solution to modify one but not the other is to recreate the directory structure in the overriden template folder so that hiptest-publisher picks the matching template. So, in this example, adding a custom template in overriden-templates/cucumber/java/actionwords.hbs will only impact the generation of the file.

Updating the scenarios

When your test scenarios have been changed (but not the action words), you can update them using hiptest-publisher, by using the following command:

hiptest-publisher -c  --only=tests

This will regenerate the test file(s) but not the action words.

Updating the action words

As for the scenarios, it is possible to regenerate only the action words code, by using the following command:

hiptest-publisher -c  --only=actionwords

This will regenerate the action words content file. If you managed the content of this file in a Version Control System like Git, you should be able to get the changes in the action word signatures. We are aware of the difficulties that the update can bring. It is the reason why we are currently experimenting solutions to ease this part of the process.

Now that your first tests are executed, you certainly want to get the execution results back to Hiptest. The best way to do so it to integrate the Hiptest test inside a Continuous Integration process.