@JPostmanAssert

Overview

This page describes the proposed @JPostmanAssert feature for annotation-based JPostman tests.

The goal is to keep test methods small while moving reusable response validation into an assertion rules file. This works with both single-request tests using @JPostmanResponse and folder/root runners using @JPostmanRunner.

Properties

Add an assertion rules file to jpostman.properties.

assertions=classpath:jpostman-assertions.ini

This global file can be used by any namespace.

You can also override the assertion file for a specific namespace:

assertions.product=classpath:product-assertions.ini

Resolution order:

1. @JPostmanAssert(rules = "...")
2. assertions.<namespace>
3. assertions

This means you do not need assertions.product if the global assertions file already contains the product rules. Add assertions.product only when you want a separate file for that namespace.

Assertion File Format

The assertion file uses INI-style sections.

[default]
statusCode=200
exists=id

[product]
extends=default
exists=title,price

[Add a new product]
extends=product
statusCode=201
pathNotNull=id
pathEquals=minimumOrderQuantity=1

Supported Rule Keys

The first version supports these assertion keys:

statusCode=200
exists=id,title
notExists=error,message
pathNotNull=id
pathEquals=active=true,quantity=10,name=Phone

Rule behavior:

Rule	Meaning
statusCode=200	Verifies the HTTP response status code.
exists=id,title	Verifies that the listed response paths exist.
notExists=error,message	Verifies that the listed response paths do not exist.
pathNotNull=id	Verifies that the listed response paths are not null.
pathEquals=active=true	Verifies that a path equals the expected value.

Section Inheritance with extends

A section can extend another section:

[product]
extends=default
exists=title,price

Inheritance order is parent first, then child:

default -> product

Child rules override parent rules when the same rule key is defined.

Example:

[default]
statusCode=200
exists=id

[product]
extends=default
exists=title,price

The resolved product rules become:

statusCode=200
exists=title,price

exists=id from the parent is replaced by exists=title,price from the child.

To keep id, include it again:

[product]
extends=default
exists=id,title,price

Request Name Section Priority

If a section name matches the current Postman request name, that section is applied last and has the highest priority.

Example request:

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

Assertion file:

[default]
statusCode=200
exists=id

[product]
extends=default
exists=title,price

[Add a new product]
extends=product
statusCode=201
pathNotNull=id

Final order:

default -> product -> Add a new product

Final resolved rules:

statusCode=201
exists=title,price
pathNotNull=id

The request-name section overrides statusCode=200 from [default] with statusCode=201.

Using @JPostmanAssert with @JPostmanResponse

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

When @JPostmanAssert is present, JPostman uses the assertion rules file instead of the default verify() value from @JPostmanResponse.

So this is not needed:

verify = 201

The assertion file should define it instead:

[Add a new product]
statusCode=201

Using @JPostmanAssert with @JPostmanRunner

@JPostmanRunner can execute multiple requests from a folder. @JPostmanAssert applies 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 in the folder, JPostman applies:

configured sections + current request-name section if it exists

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

[Get all products]

If that section exists, it is applied last.

Normal Verify Behavior

Without @JPostmanAssert, JPostman uses the normal annotation verify value:

@JPostmanResponse(request = "Get all products", verify = 200)

With @JPostmanAssert, JPostman skips the normal verify() call from @JPostmanResponse or @JPostmanRunner and uses the assertion rules file instead.

This avoids duplicate status checks and keeps all assertion behavior in one place.