This tutorial shows how you can easily run all your tests from a Gitlab pipeline. We assume that your current pipeline is already able to build and deploy your software. This tutorial contains the following steps to complete this task:
Get your ApiKey from testup.io to authenticate your Gitlab pipeline
Insert the ApiKey into a secure space as a Gitlab variable.
Extract the Id of your schedule
Setup the Gitlab pipeline to run your tests
Optional: Make temporary changes to the settings in your test
1) Get your ApiKey from Testup
Go to your testup.io start page and click on the “Profile” tab. Find your ApiKey und the section “Api Keys”
2) Provide your ApiKey to Gitlab
Since the api key gives full access to your testup settings it should be provided to the Gitlab pipelines in a secure way. To do this open Gitlab and follow these steps:
Open the project settings
Open the CI/CD section
Expand the Variables section
Press “Add variable”
Once you successfully opened the add variable dialog you can provide your details as follows:
Change your variable’s name to “TESTUP_APIKEY”
Paste the Testup ApiKey into the value field
Uncheck the “Protect variable” box (or alternatively protect your pipelines that should run your tests)
Press “Add variable” to complete the setup
3) Find your Testup schedule Id
In this step you must find the numeric Id of the schedule running your tests. For this step you navigate to your project in the browser. From there you open (or create) the schedule, such that you see a domain that it has the form http://app.testup.io/schedule/<scheduleId>?… Keep that schedule Id ready as you will need it in the next step.
4) Setup your Gitlab Pipeline
We assume that you already have a running pipeline that builds and deploys your project. Testup can only run your tests with access to a deployed version of your software. Therefore, you need to add the end-to-end test as a final stage in your build pipeline. Go to your stages section and add e2e-test. Your file .gitlab-ci.yml will probably look something like this:
stages: # List of stages for jobs, and their order of execution
- build
- unit-test
- deploy
- e2e-test # Add this stage here
As a next step you add your end-to-end test step at the end of your pipline description. Your new pipeline step can be inserted as shown below. Don’t forget to provide the correct schedule Id.
How exactly does this step work technically? First, it starts with an image that provides the “curl” command. Then it builds the url that triggers the start of the pipeline. This url contains the schedule id to run as well as the Gitlab job id to distinguish update requests from new runs. Following these preparations two curl commands are issued. The first calls Testup and retries until the test is either marked as failed or passed. Until ready the endpoint returns a 504 timeout code along with some early debug information. This first curl also makes sure that your pipeline’s debug messages contain useful information and a link to the corresponding resource in Testup. The second curl is necessary to make the pipeline fail if the tests failed.
Once your pipeline is set up you will see a debug message in your pipeline that looks something like this:
5) Optional: Provide additional settings to your test
Very often it is necessary to run your pipeline tests with other values than the ones used in interactive editing. Common cases are temporary domains or changing parameters for users, passwords etc. You can provide additional parameters in the message body of the curl. It is possible to replace urls and text contents that occur in your test. Your pipeline would then look like this:
When the anchor area is not found and your test fails, the Robot suggests you the new anchor area. The Candidate is marked with grey rectangular and an orange [use] button.
Make sure you are in mode or mode.
Click on button, if you agree with a new candidate for anchor area.
Randomly appearing content such as popup windows shows up mostly due to the following reasons: unknown user for a website, deep scrolling or longer time on the webpage. In Editor, mode, you can control the flow depending on weather the pop up appears or not.
Precondition Make sure the pop up appears during test creation.
Switch to mode.
Click on .
Draw an anchor area around close button and play it.
Add a conditional jump .
Insert actions to close the popup content.
Add actions below created #Tag to continue your test.
Please notice:
Next time when the popup content would not appear, the Robot will jump directly to the #Tag.
Enter Login and Password in URL of the website under test as follows:
https://<user>:<password>@example.com.
Open Test Settings.
Enter URL, including your Login and Password; or
Click as a new test step.
Enter URL, including your Login and Password.
Your Website shows Password dialog
Make sure you are in mode. Make sure the entry field is active.
Click to enter Login.
Enter Login and press [ENTER] to confirm the action.
Press [TAB].
Click to enter Password.
Enter Password and press [ENTER] to confirm the action.
Please notice
If your user name is an e-mail address, you will need to encode the @ symbol before you can include it in the URL. To do this, simply replace the “@” with “%40”.
Conditional jump , enables you to control execution flow depending on true/false value in Clipboard Content. Conditional Jump is only possible to a certain place in Action List that is marked with #Tag.
Preconditions: Make sure you are in mode. Introduce a condition using or .
Click on .
Type in name for a Tag to jump in case of false return. #Tag is created automatically.
Press Enter and record the action.
Insert actions for true and false paths.
Replay the test to check the expected behaviour. Once the condition is met and Clipboard content returns a true result, false path will end. Test actions will continue playing.
Please Notice
Click to control execution flow if the value in Clipboard content is true.
There are many use cases where you want to start a test from a script. A common scenario is a regular execution from a server cron job or within a CI/CD build pipeline.
The first thing you need is your personal API-key. In the testup.io App (https://app.testup.io) you will find the API Key under the tab “Profiles”:
Now you can use the following APIs in a shell, for example:
Run a test.
curl -X POST "https://app.testup.io/api/v1/project/run-all/<Project ID>?testIds=<Test Case ID>"
-H "accept: */*"
-H "Content-Type: application/json"
-H "Authorization: ApiKey-v1 <APIKEY>"
-d "{\"message\":\"New run by curl\",\"threads\":1}"
where
<APIKEY> is your API-key (see above), <Project ID> is the Project ID of your test (see URL of your project, e.g. 6607334), <Test Case ID> is the Test Case ID of your test (see URL of your test). "New run by curl\" is the name of the new execution the command will create. You can change this freely. "threads\" is the number of parallel test executions.
This curl returns a JSON with the execution id <id>. Using this <id> you can get the status of the results: