Skip to content

JPostman Tutorial Part 7: Multi Executor Support and Secure Rules

Jump to bottom
David Gofman edited this page Jun 20, 2026 · 1 revision

Multi Executor Support and Secure Rules

Overview

In this tutorial, we continue from the JUnit and TestNG fluent API examples and run the tests from Maven.

We configure the Maven build so the same project can run TestNG by default and JUnit 5 through a Maven profile. Then we add multiple JPostman executor adapters and run the same test flow with REST Assured, Java HttpClient, Playwright, and Unirest.

The tutorial also reviews advanced secure rule syntax for masking sensitive data and reducing response output, including redact, regular-expression matching, redactRegex, filter, and filterList.

What You Will Learn

By the end of this tutorial, you will know how to:

  • Run JPostman tests from Maven.
  • Fix Maven compiler source and target version errors.
  • Configure the Maven Compiler Plugin with a Java release version.
  • Configure the Maven Surefire Plugin for modern TestNG and JUnit 5 execution.
  • Use Maven profiles to control JUnit and TestNG test execution.
  • Run JUnit tests with mvn test -Pjunit.
  • Avoid duplicate JUnit failure output with -DskipPrintFailures.
  • Run the same JPostman fluent test flow with multiple executor adapters.
  • Use RestAssuredExecutor, HttpClientExecutor, PlaywrightExecutor, and UnirestExecutor.
  • Create a product rule profile in the secure INI policy file.
  • Mask selected fields with redact.
  • Use case-insensitive regular expressions with (?i).
  • Mask part of a value with redactRegex.
  • Reduce response fields with filter.
  • Reduce child-array fields with filterList.

Prerequisites

Before starting this tutorial, make sure you completed the previous tutorials:

  • Part 1: Create a Java Maven API testing project with JPostman.
  • Part 2: Execute REST API requests using RestAssured.
  • Part 3: Chain API requests using an access token.
  • Part 4: Protect request and response logs with jpostman-secure.
  • Part 5: Use native TestNG support and fluent API testing.
  • Part 6: Use the fluent API with TestNG and JUnit.

You should already have:

  • A Maven test project.
  • Exported Postman collection and environment JSON files.
  • A secure rule policy file such as demo_test_rule.ini.
  • jpostman-testng configured.
  • jpostman-junit configured.
  • jpostman-restassured configured.
  • Working TestNG and JUnit examples that cache an access token and run authenticated API requests.

Step 1: Run the JUnit Test from Maven

First, run the current JUnit test from Eclipse and then from Maven.

From the command line, navigate to the project directory and run:

mvn clean test

If Maven is not configured with a modern Java release version, you may see an error similar to:

Source/Target option 5 is no longer supported. Use 7 or later.

This can happen because Eclipse uses its own compiler settings, while command-line Maven uses the project pom.xml.

Step 2: Add the Maven Compiler Plugin

To make the build consistent in Eclipse, command line, and GitHub Actions, configure the Maven Compiler Plugin in pom.xml.

Example:

<properties>
    <java.version>11</java.version>
    <maven.compiler.release>${java.version}</maven.compiler.release>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.15.0</version>
            <configuration>
                <release>${java.version}</release>
                <encoding>${project.build.sourceEncoding}</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>

The release setting tells Maven which Java version to use when compiling the code.

The UTF-8 encoding setting keeps text handling consistent across Windows, Linux, and CI environments.

Step 3: Add the Maven Surefire Plugin

To run modern TestNG and JUnit 5 tests correctly, add the Maven Surefire Plugin.

Example:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>3.5.6</version>
</plugin>

Surefire is responsible for discovering and running tests during the Maven test phase.

Step 4: Use Maven Profiles for JUnit and TestNG

In this project, the default Maven command runs the TestNG test.

To run the JUnit test explicitly, add a Maven profile that includes the JUnit test class.

Example:

<profiles>
    <profile>
        <id>junit</id>
        <build>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <configuration>
                        <includes>
                            <include>**/DemoUnitTest.java</include>
                        </includes>
                    </configuration>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

Run the default TestNG test with:

mvn test

Run the JUnit test with:

mvn test -Pjunit

Step 5: Handle Duplicate JUnit Failure Output

When using @JPostmanJUnit(printFailures = true), JPostman can print failure output for Eclipse.

When running from Maven, you may see duplicate failure output: one message from JPostman and another from Maven.

One option is to remove:

printFailures = true

However, that also removes helpful console failure output in Eclipse.

Another option is to disable JPostman failure printing only for Maven:

mvn test -Pjunit -DskipPrintFailures

With this option, Maven prints the assertion output only once.

Step 6: Add More JPostman Executor Adapters

So far, the tutorial series used only the REST Assured executor adapter.

JPostman also supports other execution engines, so add the additional executor dependencies and imports you want to test.

Example imports:

import io.jpostman.executor.HttpClientExecutor;
import io.jpostman.playwright.PlaywrightExecutor;
import io.jpostman.unirest.UnirestExecutor;

The same fluent JPostman request flow can be executed with different adapters in different test methods.

Step 7: Reuse the Same Code with JUnit and TestNG

Copy the working code from DemoUnitTest into DemoTest.

After saving the file, run the tests again.

The same code pattern works with both providers:

  • JUnit 5
  • TestNG

This makes it easier to reuse the same JPostman flow across different test frameworks.

Step 8: Create a Product Rule Profile

For the getAllProducts test, create a new product rule section in the secure rule file.

Example:

[product]
extends=default
redact=/**/tags,/**/dimensions,/**/meta,/**/images,thumbnail
redact=regex:(?i).*email.*
redactRegex=(?i).*name.* -> [regex:\S+]***
filter=id,title,description,price,/**/reviews
filter=/**/products[0]
filterList=/**/reviews[0],/**/reviews/*/rating,/**/reviews/*/reviewerName,/**/reviews/*/comment

The product section extends the default section, so it keeps common rules and adds product-specific masking and filtering.

Step 9: Review redact and Regex-Based Masking

The first redact rule masks selected product fields such as tags, dimensions, metadata, images, and thumbnail values.

The second redact rule uses a regular expression to find keys that contain email.

Because the expression uses (?i), the match is case-insensitive.

Step 10: Review redactRegex

redactRegex provides more advanced value masking.

In this example, the key pattern looks for any key that contains name.

The value pattern keeps the first non-whitespace part of the value and masks the rest.

For example, a first and last name can be shown with the last name replaced by three stars.

Step 11: Review filter

The filter rule reduces the number of fields shown in the response.

For example, the product response can display only:

  • id
  • title
  • description
  • price
  • reviews

A second filter can act as an exception, so only the first product in the array keeps all fields.

Step 12: Review filterList

filterList is similar to filter, but it is used for child arrays.

In this example, the reviews array displays only selected fields for each review:

  • rating
  • comment
  • reviewerName

The first review record is the exception and keeps all fields.

What the Test Does

This test flow:

  1. Loads the Postman collection and environment.
  2. Loads secure rule profiles from the INI file.
  3. Caches the access token request result.
  4. Runs JUnit and TestNG tests from Maven.
  5. Uses Maven profiles to select the correct test provider.
  6. Executes the same API test flow with multiple executor adapters.
  7. Masks sensitive values in request and response logs.
  8. Reduces large response output with filter rules.

Why This Is Useful

This approach makes JPostman tests easier to maintain because it:

  • Keeps Maven execution consistent across local development and CI.
  • Allows one project to support both TestNG and JUnit examples.
  • Makes executor adapters interchangeable.
  • Helps compare REST Assured, Java HttpClient, Playwright, and Unirest execution styles.
  • Keeps sensitive values protected in logs.
  • Makes large API responses easier to read.

Summary

In this tutorial, we configured Maven to run JPostman tests with TestNG and JUnit 5, added Maven profiles, reviewed JUnit failure output options, and ran the same fluent test flow with multiple execution engines.

We also reviewed advanced secure rule syntax for masking and filtering product response data.

In the next videos, we will continue with other JPostman modules, such as Vault, GitHub, Kubernetes, Swagger, GraphQL, performance testing, and more.

Related Links

JPostman Core API

JPostman Annotation API

Clone this wiki locally