@JPostmanRunner

Overview

@JPostmanRunner runs multiple Postman requests from a selected folder or from the root of the collection.

Use it when you want one test method to execute many requests without writing one @JPostmanResponse method for every request.

Basic Folder Example

@JPostmanRunner(
    namespace = "product",
    folder = "Product"
)
@Test
public void runProductFolder() {
}

This runs all requests inside the Product folder.

Root Collection Example

If folder is empty, JPostman runs root-level requests from the collection.

@JPostmanRunner
@Test
public void runRootRequests() {
}

Include Specific Requests

Use include to run only selected requests from the folder or root.

@JPostmanRunner(
    namespace = "product",
    folder = "Product",
    include = {
        "Get all products",
        "Search products"
    }
)
@Test
public void runSelectedProductRequests() {
}

Exclude Specific Requests

Use exclude to skip selected requests.

@JPostmanRunner(
    namespace = "product",
    folder = "Product",
    exclude = {
        "Add a new product",
        "Update a product",
        "Delete a product"
    }
)
@Test
public void runProductReadOnlyRequests() {
}

Skip Explicit @JPostmanResponse Methods

If a request already has an explicit @JPostmanResponse method with the same namespace, folder, and request name, @JPostmanRunner skips that request.

Example explicit test:

@JPostmanResponse(
    namespace = "product",
    folder = "Product",
    request = "Add a new product",
    log = true,
    verify = 201
)
@Test
public void addNewProduct() {
}

Folder runner:

@JPostmanRunner(
    namespace = "product",
    folder = "Product"
)
@Test
public void runProductFolder() {
}

The runner skips Add a new product because it already has a dedicated response test.

Main Attributes

Attribute	Meaning
namespace	Selects the configured JPostman context. Empty means default context.
folder	Optional Postman folder name. Empty means root requests.
rule	Optional secure rule section.
filter	Optional response fields to keep.
dependsOn	Dependency method names to run first.
include	Request names to include. Empty means include all.
exclude	Request names to exclude.
cache	Optional cache key for storing this method result.
verify	Expected HTTP status code. Default is 200.
executor	Named executor method. Empty means default executor.
log	Attach secure log details to assertion failures.
soft	Use soft assertion verification.

Custom Executor

@JPostmanRunner can use the same custom executors as @JPostmanResponse.

@JPostmanRunner(
    namespace = "product",
    folder = "Product",
    executor = "defaultExecutor"
)
@Test
public void runProductFolder() {
}

Executor with current request name:

@JPostmanExecutor
public ApiExecutor myExecutor(TestNgContext context, String methodName, String requestName) {
    log.debug("=== {}::{} ==={}\n", methodName, requestName, context.log());
    return RestAssuredExecutor.apply(context.request());
}

For each request, requestName is the current Postman request being executed.

With @JPostmanAssert

@JPostmanAssert applies assertion rules to each executed request.

@JPostmanRunner(
    namespace = "product",
    folder = "Product",
    exclude = {
        "Add a new product",
        "Update a product",
        "Delete a product"
    },
    log = true
)
@JPostmanAssert(sections = { "product" })
@Test
public void runProductReadOnlyRequests() {
}

For each request, JPostman applies:

configured sections + current request-name section if it exists

For example, when the runner executes Get all products, it also checks for:

[Get all products]

If that section exists, it is applied last and has highest priority.

Normal Verify Behavior

Without @JPostmanAssert, the runner uses the normal verify() value.

@JPostmanRunner(
    folder = "Product",
    verify = 200
)
@Test
public void runProductFolder() {
}

With @JPostmanAssert, the runner skips the normal verify() call and uses assertion rules instead.

Summary

@JPostmanRunner runs many Postman requests from a folder or root collection. It supports include/exclude filtering, skips explicit response tests, works with custom executors, and can apply reusable assertion rules to every executed request.