Guestpost: Testautomation with best4Automic

A guestpost by Sebastian Weha.

You probably know the Software Development Lifecycle (SDLC). It describes the process from requirements analysis to a finished software and its evaluation. To implement the SDLC, there are many methods (and lots of discussion about which of them is best): agile software development, the waterfall principle, DevOps, ….

But there’s one thing, all of them have in common: testing the software is crucial.

So of course, this also applies to the Automic development — at least in theory. In practice, however, testing is often neglected.

I made this experience in many projects. That’s why I came up with the idea of automating the testing process and providing a solution for it in best4Automic (b4A).

The solution is based on b4A packages, which are based on the structure of Automic Action Packs. In the default configuration, it uses the structure of the action packs so that customers who already use action packs can start immediately.

In test specifications, you define which tests are to be carried out.

What does a Test Specification Look Like?

The tests are described in Cucumber and the Gherkin syntax.

Basically, the tests are structured as follows:

• Feature: Describes a set of test cases (scenarios) that are thematically related
• Scenario: Describes a single test case

• Given: Describes the steps to be checked before the actual test execution (preconditions)
• When: Describes the actual test execution
• Then: Describes the steps to be checked after the test execution (post-conditions)

To illustrate this with an example, I have created a simple workflow. This consists of a PromptSet for text input and a script that returns the input.

We test this workflow with the following test specification.

@PCK.PCK.PHILIPPELMER_TEST
Feature: Test the package for Philipp Elmer blog post!
	
	@PRINT_OUT @TEST0001
	Scenario: Test Script and check if input is contained in report
		Given Object PCK.PHILIPPELMER_TEST.JOBP.PRINTOUT exists
		And Object PCK.PHILIPPELMER_TEST.SCRI.PRINTOUT exists
		And Object PCK.PHILIPPELMER_TEST.PRPT.PRINTOUT exists
		
		When Execute PCK.PHILIPPELMER_TEST.JOBP.PRINTOUT
			|Key				|Value			|
			|INPUT#				|Test Input	|

		Then Task status of PCK.PHILIPPELMER_TEST.JOBP.PRINTOUT is 
			|Task									|status		|
			|PCK.PHILIPPELMER_TEST.SCRI.PRINTOUT(1)	|ENDED_OK	|
		
		And Check report ACT of PCK.PHILIPPELMER_TEST.SCRI.PRINTOUT 
		from PCK.PHILIPPELMER_TEST.JOBP.PRINTOUT for ".*Test Input.*"
		
		
		

The specification contains a feature with a very simple scenario.

First of all, we check with GIVEN whether all three objects exist in the client. If one does not exist, the test aborts.

The WHEN section describes the execution of the workflow and passes the PromptSet parameters. The table shows the PromptSet parameters that are passed (Key: INPUT#, Value: Test Input).

THEN checks if the task in the workflow has the status ENDED_OK and if the report contains the entered text.

Of course, we could also test other scenarios, like other inputs. However, this is not necessary for our example.

How to run a test specification

The Gherkin syntax runs tests on the Cucumber framework and retrieves the results from there. This step is not trivial, as we need an interpreter that translates Automic into the expected results and into a language that Cucumber understands.

We implemented this as the module ta.Execute in the best4Automic Solution.

With the module, test cases specified in Gherkin can be executed. You can either pass the test definition in a text file or store the test definition in a DOCU object. In this case, I specified the DOCU object. It also stores the test results of the last run.

After running the test, you get a report with the results.

You can also find this report in the object that you specified for the report. This allows you to analyze and process the test results using Automic scripting tools. For example, you can forward the test results as an e-mail or transfer them to your test management software.

The example here is of course very simplified. Usually you have to test significantly more scenarios. But they all work the same way I described here.

Do you have your own ideas for testing your Automic workflows? Then get started on the implementation.

Sebastian Weha

Automic Expert and b4A Developer

Sebastian is a certified Automic Expert and b4A Developer. With great passion he meshes Automic with other products, controls them with Automic, and simplifies and automates workflows. He spends his free time with his family and traveling to new places in the world.

best-blu — Consulting with Energy

best-blu specializes in the automation of business processes of large and medium-sized companies. With approximately 35 employees, they work in the four core areas of digitalization: Business Process Automation, Business Process Management, Software Development and ERP Processes (SAP). As a Premium Service Partner of Automic, with the excellence initiative bestXperts and, of course, through successful automation projects at well-known companies, they have made a name for themselves as a specialist for automation and digitalization of business processes.