Welcome back! In my previous article about Tosca and CI pipelines I explained, among other things, how you can connect Tosca with Azure DevOps and a GitHub repository. The so-called Tosca CI client was used, which has become “legacy” in Tosca version 15.2. In the ever-transforming and innovative world of information and communication technology, in which cloud technology plays an increasingly important role, Tricentis has opted for more flexible “CI solutions”. For Tosca, these are the Tosca Execution Client, and the Tosca Server Execution API respectively. This article focuses on the Tosca Execution Client, and the Tosca Server Execution API will be discussed in my next article (part 2).
First, let's take a step back and analyze which trends are currently playing in the “Agile and DevOps world”, with a special focus on test tooling. According to Gartner we see a trend of DevOps towards so-called "Value Streams"; from “collaborative approach” to maximize results (DevOps) towards a continuous flow of optimization of value and quality (Value Streams). The CI for “Continuous Integration” is accompanied by the CI for “Continuous Improvement”, a term that has been used many times and can be easily categorized under CI/CD, but is a matter of definition. This is all still abstract, but what do the trends look like for test tooling in concrete terms?
The community further developed Selenium and through innovations in cloud technology, several IT companies came up with new ideas and initiatives for testing in the cloud using. Selenium, think of SauceLabs and BrowserStack . With the introduction of Selenium 4 at the end of 2021, a new “testing” era had begun, especially a period in which test automation was no longer just “a party” for test engineers.
Testing, and quality in general, is an integral and inseparable part of the entire software development process, from start to finish; The entire chain, from blueprint via drawing board and development to the end user. Test automation without CI/CD is not test automation. And this is (fortunately) reflected in the basic principles of DevOps and CI/CD. A test tool that is not “compatible” with other tools or does not have extensive integration options will not last long in the “CI/CD spectrum”. It is not without reason, that Tricentis recently acquired Testim, an “AI-based SaaS test automation platform”. Testim is a cloud platform that covers almost all important “testing facets”. Think, for example, of preparing and executing the scripts, recording, maintenance, error handling, reporting and a number of other useful features. With Selenium “under the hood” in combination with The concept of “dynamic locators” allows more test levels at the same time.
Tosca Execution Client
And now back to what it's all about: the Tosca Execution Client! Let's assume a scenario where the customer hires a specialist to set up a distributed test process in an already set up Tosca infrastructure. To keep it simple, the “already set up Tosca infrastructure” in my case is a locally provisioned Tosca Commander, Tosca Server and DEX Agent. In addition, the Tosca Server is configured with the “http” protocol. For those who want to know more about configuring with “https”, keep an eye on my blogs!
How do we go about my “local scenario” enable a distributed testing process? First of all, we need the tools to build the test tool chain. In this scenario, we first of all need the Tosca Execution Client as a “mediator” for executing the test events. The Tosca Execution Client can be downloaded from GitHub, where it is maintained by Tricentis (see link at the bottom of the article). Once you have downloaded the client, the folder structure will look like this (see figure 1).
In my case I created a local “CI” folder, in which I placed the “Tosca Execution Client” as a subfolder. In the subfolder are 3 files, and for our local Windows machine, we are going to use the Powershell script (“tosca_execution_clent.ps1”), a script-based client. The script uses the “Execution API” of the Tosca Server. The other script is for Linux machines. Before we start with the script, the starting situation on the Tosca server should look like this for the DEX monitor (see figure 2).
In other words, the connection between Tosca Server and DEX Agent must be OK/Successful. Furthermore, it is important to know that DEX in the new Tosca version (from 15.2) only works with AOS (Automation Object Service). Of course you also have to configure a few things in both Tosca Commander and Tosca Server, but this is assumed to be known. In Tosca Commander I have a workspace, in which I have created a Test Event with a simple intake test, see figure 3.
And now it's time for a first test with the Tosca Execution Client! How do we do that? As you know, the Tosca Execution Client is “script-based” and Tosca Commander is not needed for the test execution. The next step is to check in your workspace in question and then close your workspace properly. Next, navigate to the “Tosca Execution Client” folder and open the Powershell window at that level, as shown in Figure 4.
Let's start with a simple script-based test command. In figure 5 I have added a test command in which to execute a Test Event from Tosca workspace called “DEX”.
In the above command, first the client script (“tosca_execution_client.ps1”) is called, and then pass 3 parameters, namely:
The names of the above parameters speak for themselves. Note that the hostname of the Tosca Server can be identified as the URL of the Tosca Server, otherwise the client will not be able to communicate with the “Execution API” of the Tosca Server. In addition, it is important to know that organizational policies can block the running of Powershell scripts. To set up a script-based test infrastructure, it is important to include all stakeholders in the communication lines, including the team or department responsible for infrastructure and security.
If we then click ENTER, the Test Event becomes “0 | Run test” from the “DEX” workspace. When the Test Event on DEX is successfully completed, 2 additional sub-folders will appear in the “root folder” (see figure 6).
This concerns the sub-folders “logs” and “results”. The first folder stores the client logs and the second folder stores the test results. Relevant test results are also loaded into the “ExecutionList” folder of Tosca Commander. If we look at the DEX monitor on the Tosca Server, we see that Test Event “0 | Test” has been successfully executed by the Tosca Execution Client (see figure 7).
If we then open workspace “DEX” in Tosca Commander, we see that the test results in figure 8 are neatly displayed in the “ExecutionList”.
Now we have successfully realized the first part of “CI”, but we are not there yet! Do you want to know more and are you curious how it ends? Then keep an eye on my blogs! In part two, I will use CI tool Jenkins, link it to a GitHub repository and go deeper into the “Tosca Server Execution API”. Stay tuned!
More information about Tosca Execution Client and Tosca CI/CD:
Published: 21 September 2022
Author: Otman Zemouri