Skip to Content
Technical Articles
Author's profile photo Jakob Marius Kjær

Run your ABAP Unit test in CI pipelines

Hello all,

In this blog we will take a look at how to run your ABAP Unit tests in CI pipeline when publishing from AbapGit.

There are some really cool stuff already in this area such as:

The difference between Felipe’s blog and mine is that in this blog I will explain how to run the unit tests without relying on additional source code installed on the Abap server.

Why would you even want to consider this approach. You could just keep running your Unit tests like normal.

While this is certainly true, I don’t think you can test too often, so adding another layer of testing in a pipeline where you could also integrate other packages as well is pretty cool. Or possibly you could use this setup to potentially shift your development to a server off the common transport path (See Graham Robinson‘s blog for inspiration) to later integrate into the test system via a pipeline.

Let me explain my setup for this blog, everything is running in separate Docker containers.

If you want me to write a second blog on how to set up the gitlab stuff, let me know in the comments below.

For this example I’ve created a local package $TEST_UNIT2 with a single class in it called ZCL_ABAP_UNIT2

In this class I’ve got a simple method called test2

 

And a local test class

Sidenode: In case you are wondering about about the screenshots, I’m using Marcello Urbani’s VSCode extension

While this obviously isn’t a very elaborate scenario, it does the job for this blog 😉

When I execute this locally in VSCode by pressing CTRL + SHIFT + F11 or using the command palette and typing abapfs ‘run unit tests’ I can then see the test result in the test explorer window

Now let’s add this to a pipeline.

Firstly on my gitlab server I create a new repository.

 

Afterwards we copy the http link to be used in AbapGit

Now we clone the repository in AbapGit and then we commit and push the changes to the git repository

 

Now that we have pushed out code, it’s time to build the pipeline. Click the new file.

Select the .gitlab-ci.yml template and paste the following in.

image: node:latest

# This folder is cached between builds
# https://docs.gitlab.com/ee/ci/yaml/index.html#cache
cache:
  paths:
    - node_modules/
abap_unit:
  script:
    - npm install -g abap_test_runner_cli
    - abaptr

In the pipeline we will install an NPM package I have created. This will execute the unit tests and give us the output.

Commit the changes afterwards we need to maintain the variables. You can maintain these variables in different ways. This is the simplest. We need a server, package or class, username and password.

Here I use the package. If you want to use the class, then replace the ABAP_PACKAGE with ABAP_CLASS.

Now let’s save this and try to run our pipeline.

We can see under the Pipeline –> CI that our pipeline has executed correctly

And checking the job log it’s passed all unit tests as expected

Now let’s change the source code to make the test fail.

After committing the code to Gitlab via AbapGit we see that our pipeline is now failing

 

Checking the details of the job we get the expected fail on the unit test. 1 is actually different to 2. Who knew!

Alright,not it’s time to get creative. How about we let the pipeline create a gitlab issue directly on a failed test.

Check this out

# This file is a template, and might need editing before it works on your project.
# To contribute improvements to CI/CD templates, please follow the Development guide at:
# https://docs.gitlab.com/ee/development/cicd/templates.html
# This specific template is located at:
# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Nodejs.gitlab-ci.yml

# Official framework image. Look for the different tagged releases at:
# https://hub.docker.com/r/library/node/tags/
image: node:latest

stages:
  - abap_unit
  - create_issue
abap_unit: 
  stage: abap_unit
  script:
    - npm install -g abap_test_runner_cli
    - echo "$( abaptr --skip_image true )" >> test.txt
  artifacts:
    paths:
      - test.txt
create_issue:
  stage: create_issue
  script:
    - apt-get update 
    - apt-get install python3 -y
    - |- 
        if [[ $( grep -q 'Error' test.txt && echo true || echo false ) == true ]]; then
            echo "Creating issue"
            curl --request POST --header "PRIVATE-TOKEN: $private_token" "https://gitlab.agilux.com.au:44388/api/v4/projects/$CI_PROJECT_ID/issues?title=Unit%20test%20failed&description=$(cat test.txt | python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.stdin.read()))")"
            exit 1
        else 
            echo "success"
            exit 0
        fi
  dependencies:
    - abap_unit

 

Alright let’s go through this step by step.

Stages

The stages section of the yml file is to indicate that the jobs are to be run sequentially and not in parallel

Abap Unit

abap_unit:
  stage: abap_unit <= which stage does the job belong to
  script:
    – npm install -g abap_test_runner_cli
    – echo “$( abaptr –skip_image true )” >> test.txt <= Take the output from the abaptr command and copy into a text file called test.txt
  artifacts: <= Tells the pipeline that new files are to be stored in the context of the pipeline, in this example the text file test.txt
    paths:
      – test.txt

Create_Issue

create_issue:
  stage: create_issue
  script:
    – apt-get update <= Update the package manager as we will install python3. I’m to lazy to find a docker image that has both node and python 🦥
    – apt-get install python3 -y <= Install python3
    – |- <= Execute a multi line command
        if [[ $( grep -q ‘Error’ test.txt && echo true || echo false ) == true ]]; then <= The if statement uses a grep query command to check for the word Error in test.txt, if present it evaluates to true, otherwise false
            echo “Creating issue”
            curl –request POST –header “PRIVATE-TOKEN: $private_token” “https://gitlab.agilux.com.au:44388/api/v4/projects/$CI_PROJECT_ID/issues?title=Unit%20test%20failed&description=$(cat test.txt | python3 -c “import urllib.parse, sys; print(urllib.parse.quote(sys.stdin.read()))”)” <= The curl command creates the issue via the API. We set the title Unit Test Failed and the description from the test.txt file URL encoded using the python3 command. The private_token is a personal access token stored in the CI variables. This isn’t best practice, but for demo purposes and since i’m the only user on this gitlab instance, i’ll let that little security issue pass 🙈
            exit 1 <= Tell the pipeline to fail
        else
            echo “success”
            exit 0
        fi
  dependencies:
    – abap_unit <= Tell the job that it needs the artefacts coming from the abap_unit job.
Now when we run our abap_unit job will always execute as success, but the second will validate the output from the abap_unit job and decide whether to create an issue or not.
Checking the new pipeline we can see that the first job passes now as expected, but second fails.
And upon checking our issue log, we now have a newly created issue
Text looks a bit weird as Gitlab expects markdown formatted text, but currently it’s not.
You could take a look at pandoc to handle that.
Also if you want to see the actual test output as well, then add the line
cat test.txt before the exit 1 line.
You could also assign the user to the issue automatically by adding the parameter assignee_id=$GITLAB_USER_ID to the curl command.
I hope you enjoyed this little nerdy read. Hopefully it’s inspiring you to take a closer look at this if you are already using AbapGit or maybe an inspiration to get started.
Good luck!

 

Assigned tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Lars Hvam
      Lars Hvam

      Cool, its good to have the code versioned, and regular feedback on unit tests.

      I guess the unit tests will be run with the code in the system, which might be different than what is in git? Depending on the timing and what is committed by the developer.

      Author's profile photo Jakob Marius Kjær
      Jakob Marius Kjær
      Blog Post Author

      Correct. The demonstration here is the system you are running on. But you could have it deploy the code to another system and execute the tests on another system. If it's the same system the code should always be the same.