Not yet registered? Try Yulup with a free account!
Yulup Logo

User Manual


Yulup has the following USPs:

  • Yulup guides and supports you through the overall process of a software project: From gathering business requirements, to agile development, to continuous testing, and continuous deployment for operations. Just as DevOps bridges the gap between Development and Operations, Yulup bridges the gap between all major project stages.
  • Testing starts already when the specification is being written. And then you re-use the specification for development and testing itself. This means less misunderstandings and much more efficiency.
  • Let's be real, there are always a lot of manual tests. Because they are either still too complicated to automate, or it is not worth the effort. Hence Yulup allows to mix manual and automatic tests.
  • Incremental testing, which means faster test results, scales better and code/test associations are documented.

Please see this elaborate blog post of Atlassian for a good introduction to Continuous Inte­gra­tion, Delivery, and Deployment.

Table of Contents

Getting Started

  1. Create an account:
  2. (what you obviously already have done ;-)
  3. Log in and create a project or have yourself invited to another project
  4. Write the specification for your project (Personas, User Stories, and BDD Scenarios) directly in Yulup
  5. Associate the project with your SCM repositories
  6. Connect your SCM repositories using post-receive with Yulup
  7. Create associations between code files and tests directly in Yulup or write meta files inside your SCM repositories containing references to the tests
  8. Start updating your source files. And when pushing them, see how Yulup will take care of the rest :-)
For more extended instructions on how to get started please have a look at the Quick Start Guide!

Table of Contents



First define Personas. They describe who is going to use your existing or new system/product. The Personas should comprise at least the customer/user groups, which are most likely to use your system. Keep them in focus when designing your system/product.

Some examples of Personas are:

Please do have a look at the corresponding chapter of the Quick Start Guide!

Table of Contents

User Stories

User Stories do describe what and why a functionality should be provided. But User Stories do not describe how a specific functionality is being implemented. That is where BDD Scenarios come into play.

Some examples of User Stories are:

Please do have a look at the corresponding chapter of the Quick Start Guide!

Table of Contents

BDD Scenarios Acceptance Criteria and Test Cases

Use BDD Scenarios to describe acceptance criteria and test cases. The BDD approach is well structured, simple and intuitive.

A BDD Scenario describes how a user experiences a particular functionality. Remember, the corresponding User Story depicts the reason why a certain functionality exists.

A required functionality can be implemented in many different ways. Therefore it is very important to specify as detailed as possible how a functionality should be implemented. This avoids misunderstandings as well.

The most convenient way is to directly write the BDD Scenarios in Yulup. But Yulup supports also the usage of third party systems for this task. In this case you can set the type of the BDD Scenario to external and store the URL of the BDD Scenario of the third party system.

Some examples of BDD Scenarios are:

A workflow is applied to each version of a BDD Scenario.

Please do have a look at the corresponding chapter of the Quick Start Guide!

Table of Contents

Supported SCM Repositories

Yulup currently supports the following SCM [Software Configuration Management] repositories:

Please send an email if you would like Yulup to support another SCM repository, like for example SVN.

Table of Contents

Connecting a SCM Repository with Yulup

Yulup currently supports two ways to connect a SCM repository with it:

Using a Webhook

Depending on the SCM you can set a webhook notifying Yulup when the SCM has been updated. Yulup currently supports webhooks of the following systems:

  • GitHub
  • GitLab
  • bitbucket
  • Gitolite
whereas you can find information about it below.

Please send an email if you would like Yulup to support another webhook, like for example Stash.


Set a webhook according to
pointing to


Set a webhook according to
pointing to


Set a webhook according to
pointing to


A Github-like webhook shell script can be downloaded at
whereas please see the following links about how to install and use it

Table of Contents

Pulling Periodically

If you cannot set a webhook, then you might want to configure the repository being pulled periodically.

Table of Contents

Agile Testing out of the Box

There is a basic principle in agile testing: Every file change is associated with one or multiple tests. The tests can be different for the various environments (development, staging, production). For example when the Yanel README.txt file is being changed, then various tests should be done, e.g.:

  • A spell checker should be applied
  • A person should check whether the instructions actually make sense

Let's assume, that all code files of your project are associated with tests. If now a developer is pushing changes - i.e. "storing an updated version of some files in the repository" - Yulup will conduct all automatic tests. And it will list all relevant tests that need to be done manually.

Of course things are more complicated behind the scenes. But as always the basic principle is very simple :-)

Start now associating tests with the source files inside your repository and learn how to do that by reading the following sections.

Table of Contents

Meta Files

Set Associations directly in Yulup instead of using meta files.
The easiest way to start to associate code files with tests needs no technical knowledge: After a code file has been added to or changed in the repository, it will be listed in Yulup within the 'Changes'. There you can connect it with any available test.

If you want to use meta files, please read on.

Files inside the code repository are associated with tests (automatic and manual) by creating meta files containing references accordingly.

Some examples are:

Looking at the examples, you will notice that each code file (e.g. is mapped onto a meta file by adding a suffix '_cd.xml' (e.g. UserRegistrationResource.java_cd.xml).

Instead of mapping each code file onto a meta file, you can also use patterns by using a meta map file. Here is an example inside the Yanel code repository:

As you can see, this way, all html files (e.g. testing-framework.html) are mapped onto the same meta file: If there is a 1-to-1 mapping as described above, then the patterns of the meta map won't be checked and applied.

The meta files (and the meta map) can be located

  • either inside the code repository itself, whereas by convention the meta files need to be located inside a directory called '.wyona-continuous', see for example
  • or inside Yulup, see for example

Meta files can also be generated dynamically using java, which allows dynamic parameterisation, e.g.

To achieve this you have to implement the class com.wyona.yanel.​impl.resources.​github.Meta

Table of Contents

Automatic Tests / Workers

A worker is a virtual server instance where your automatic tests will be executed within a safe environment.

See for example a junit test.

Table of Contents

Deployment Environments

For each project you can configure various deployment environments. Yulup currently supports

  • Production/Live
  • Staging
  • Testing/Development
When all automatic tests are successful (or no automatic tests exist), then the testing environment gets updated automatically, such that manual tests can be performed, too. This is done by adding a shell script '' to the folder '.wyona-continuous/scripts'.

Table of Contents

Create Release or/and Automatic Deployment

When all tests of a change are successful, then you can create a new release or/and do an automatic deployment. This is done by adding a shell script '' to the folder '.wyona-continuous/scripts', see for example Yanel.

If a project is based on multiple code repositories, then you can set a flag for one or more repositories in order to determine which shell script(s) should be triggered.

Challenging examples:

  • Additional Reverse Proxy configuration, e.g. new specific URLs will be introduced which are not within the existing URL space
  • Replacement of backend implementation, e.g. data repository will be replaced

Table of Contents

Made with in Zurich:

Stockerstrasse 32
8002 Zurich

© YEAR Wyona | Contact | Twitter

Yulup Logo