Do you know Tricentis Tosca.... has made CI/CD integration even easier? (part 2)

Welcome back again!

At the time of writing this article, Tricentis has released a patch 4 for the Tosca Test Suite and a patch 3 for the Tosca Server (both version 15.2 LTS), although no significant changes or improvements to the Tosca Execution Client and the Tosca Server Execution API. In my previous blog I showed how you can successfully realize the first piece of “CI”. In this blog we will continue using CI tool Jenkins, and then configure it with an existing GitHub repository. It concerns Javascript code that we further edit or develop in, for example, Visual Studio Code (IDE). More about this later in the configuration steps. First, let's take a step back with some important test news!

As you know, Tricentis has been very active in the meantime with developments in the field of testing in the cloud, such as Elastic Execution Grid, which is still a tech preview. But more interesting to mention is that Tricentis will stop supporting and further developing TestProject as of March 1st 2023, as an opensource cloud test platform. Already mentioned in one of my Tosca blogs. For many "open source enthusiasts" this will be a bitter pill to swallow, especially since TestProject (with Selenium under the hood) has proven itself as a reliable, and not unimportant to mention, a "community driven" test framework with worldwide support. What is the most common alternative?

According to Tricentis, the full focus is on Testim, a SaaS-based and AI-powered test automation tool for “tailor-made” web applications. Nevertheless, TestProject also offered (free) “on premise” options with the (local) TestProject server, especially good for organizations that attach great importance to (data) security, control and their own management and maintenance. If we look at other developments around cloud, the most common alternative is (yet again) Elastic Execution Grid, a cloud test variant within the Tosca spectrum itself. As of Tosca version 16.x, Elastic Execution Grid will be part of the so-called "Tricentis Test Automation" cloud-based toolkit.

Last but not least, another important announcement for the "die hard" Jenkins and Tosca fans, who have used the Tricentis Jenkins plugin; The plugin in question is no longer suitable from Tosca version 15.2, and has not been updated for 3 years, so there is a high risk of vulnerabilities. The Tosca Execution Client makes your life easier! And now back to the configuration!

Configure DEX and Tosca Execution Client in Jenkins

What do we need to successfully implement the 2nd part? The 1st part (with the DEX server in the leading role) should have been successfully realized (check part 1 of this blogseries). Furthermore, a healthy dose of common sense, a CI tool, an IDE tool and a cloud repository will suffice for now. For the CI tool, we're going to use Jenkins this time, and we're going to configure it with a GitHub repository. We use Visual Studio Code to edit Javascript code to realize a "trigger", a check-in, for running a CI pipeline (see this previous blog). For those who don't know how to install Jenkins, I refer to the Jenkins website (see link at the bottom).

Of course it is also important that you also have a valid GitHub account (see also the link at the very bottom), if you want to edit and update the code yourself. After the (local) Jenkins server has started up, we create a Jenkins project folder in the context of the project structure, as shown in figure 1. This is the folder called “Component Testing”. Component Test was deliberately chosen because of the test type, since a frontend test must be performed on a React application due to a code change.

In the same folder we then create a Jenkins job with the name “Component Test” (see figure 1). The intention is that Jenkins will arrange the test output of the Tosca TestEvents. But how do you set this up without the well-known “Tosca CI”? This is very easy with the Tosca Execution Client (TEC)! Before configuring the Jenkins job, let's briefly describe the pipeline test scenario. This is a component test that must be performed by Tosca following a code change (check-in) in the front-end, a React web application, maintained in a GitHub repository. We have prepared a TestEvent for this in the Tosca workspace (see previous blog). 

To keep the test process clear, we first create a local “component test” folder, see figure 2.

In the “component test” folder we make a copy of the “tosca_execution_client.ps1” file and change the name to “component_test”. The intention is that we store and maintain the component test results and logs in a separate folder. Moreover, this is much clearer and we do not have to change the original “tosca_execution_client.ps1” file. The contents of the folder will then look like this (see figure 3).

Next, we're going to make "hardcoded" parameter changes in the "component_test" powershell script. For example, you can use the user-friendly Notepad++ for this or add it as a local test project in an IDE, such as Visual Studio Code. To keep it simple, we will use Notepad++ for now (see figure 4).

It concerns the following parameters:

• $toscaServerUrl
• $projectName
• $events

Why add the parameters in question “hardcoded”? Because this is about 1 specific test, and mainly for "simplification" when configuring in Jenkins. Of course, this will be slightly different in practice. Save changes and return to Jenkins! In Jenkins, all we need to do is add a build step and configure it for test output using the Tosca Execution Client. This is well illustrated in figure 5.

Save the configuration changes for the Jenkins job and check by means of a dry run, by executing build “Component Test”, whether this part of the “build process” is running properly. If everything has been executed successfully, 2 extra subfolders will be created in the local subfolder “component test”, namely “logs” and “results”. These include the test result files (see figure 6).

Let’s go on GitHub!

The Jenkins piece is now almost fully configured, and the next step is the integration with GitHub! We use an existing GitHub repository, of course you can also choose a different repository. Then complete the following data in Jenkins, namely, “Repository URL” and “Poll SCM” (see figures 7 and 8).

Option “Poll SCM” is used to “periodically” check the GitHub repository for updates. In the above situation this is done per minute. Depending on the performance or release planning of the (OTA) environment and the associated infrastructure, you as an organization can decide to do this per hour or, for example, per day. If we then save the above data, then the complete "CI" configuration with the help of the Tosca Execution Client accomplished. Nice and simple right?

What’s next? The Tosca Server Execution API?

The “Tosca Execution Client” (TEC) configuration part has now been successfully completed. Are there other ways to communicate with the DEX server in a CI/CD process? The alternative to TEC, or rather the complement, is the so-called “Tosca Server Execution API”. With the “Execution API” of the Tosca Server, you get a little more flexibility in your CI pipeline. The integration of CI pipeline and Tosca works with the Tosca Server Execution API in combination with TestEvents, but on a “service” level.
As a Tosca Test Engineer, if you first want to try things out about APIs, you can do so in a simple way. The (Tosca Server) API structure is represented by a so-called Swagger definition (in my case):

http://localhost:81/automationobjectservice/swagger/index.html

The URL above consists of 2 parts, the first part is the Tosca Server URL, and the addition “/automationobjectservice/swagger/index.html” refers to the Swagger definition.

Would you like to know more about “Tosca Server Execution API”? More information can be found below or just follow my blogs!

Learn more about Tosca CI/CD, Jenkins, and GitHub:

• Tosca CI/CD documentation
• Tosca Execution Client
• Tosca Server Execution API
• Jenkins
• GitHub