A REST Assured Framework, Layer by Layer: 33 Tests, Zero Hardcoded Values

There is a specific moment where a set of REST Assured tests stops being a set of tests and starts being a liability. It usually arrives somewhere around test number forty, on the morning the platform team changes the auth header format, and someone discovers that Authorization is typed out by hand in thirty-eight different files.

Nothing about that morning is a REST Assured problem. The library did exactly what it was asked. The problem is that nobody ever decided where the base URL lives, or who owns the token, or what happens to the user records the suite creates every night. Those decisions get made by default — which means they get made badly — unless somebody makes them on purpose.

Making them on purpose is what people mean by a REST Assured framework: a Java project where the reusable plumbing lives in one place and the test classes stay thin enough to read in a single glance. This guide walks through that architecture one layer at a time, using real code from an open-source framework built against the public GoREST API. You can clone it, run mvn clean test, and read every pattern below in its natural habitat.

What We’re Building

Seven test classes, 33 test methods, seven of them tagged for a smoke run — and not a single URL, token, header or status code typed out inside a test.

1. The library versus the framework
2. The stack, and the version detail most tutorials miss
3. Layer 0: the project layout everything else depends on
4. Layer 1: configuration that never gets committed
5. Layer 2: specs, the highest-leverage pattern in REST Assured
6. Layer 3: endpoints and status codes as constants
7. Layer 4: POJOs instead of hand-built JSON
8. Layer 5: schema validation catches what assertions miss
9. Layer 6: test data that survives a hundred runs
10. Skip, don’t fail: the missing-token problem
11. Suites, groups and CI
12. Reporting for the 2 a.m. failure
13. What this architecture does not solve

The Library Versus the Framework

REST Assured itself is a Java DSL for testing HTTP services. Its entire appeal is that a request and its assertions read as one sentence:

given()
    .header("Authorization", "Bearer " + token)
.when()
    .get("/users")
.then()
    .statusCode(200)
    .body("size()", greaterThan(0));

That is genuinely lovely, and it is also the trap. The syntax is so readable that the natural instinct is to write every test exactly like that — self-contained, fully explicit, sharing nothing. For five tests, that is the correct call. For two hundred, you have quietly built a system where the token appears two hundred times, the base URL appears two hundred times, and the Content-Type header appears two hundred times.

A framework is what you get when you ask a different question. Not “how do I test this endpoint?” but “what in this test will still be true in a year — and what will change?” The endpoint path will change. The auth scheme will change. The response-time budget will be argued about. The business rule the test exists to protect probably will not.

Everything that can change gets pulled out into a reusable layer. What stays in the test class is the part that expresses intent.

The Stack, and the Version Detail Most Tutorials Miss

The reference framework pins these:

Purpose	Library	Version used
HTTP DSL	REST Assured	5.5.0
Schema validation	rest-assured json-schema-validator	5.5.0
Assertions	Hamcrest (transitive via REST Assured)	—
Test runner	TestNG	7.10.2
JSON / POJO mapping	Jackson Databind	2.17.2
Reporting	Extent Reports	5.1.2
Build	Maven, Java 17	—

Now the part that almost no REST Assured tutorial has caught up with, because it happened recently and quietly.

REST Assured 6.0.0 shipped on 12 December 2025, and it is a bigger release than the version number implies. From the project’s own changelog: the minimum Java baseline moved to 17, the Groovy baseline moved to 5.x, Jackson 3 object mapping is supported, and — the genuinely interesting one — json-path was migrated fully to Java and no longer evaluates through GroovyShell. That change fixed real memory leaks that showed up in long-running processes doing heavy JsonPath work.

REST Assured 6.0.1 (10 July 2026) is the current release, and it carries a security fix worth knowing about even if you never upgrade: a JsonPath denial-of-service where oversized numeric literals in untrusted JSON were parsed into arbitrarily large BigInteger values at O(n²) CPU and heap cost. JSON number tokens are now capped at 1000 characters by default, configurable via JsonPathConfig.numberLengthLimit. Queued for the release after that is another one: stripping Authorization and Cookie headers when a redirect crosses to a different host, so a bearer token isn’t handed to whatever the redirect points at.

The practical reading for anyone standing up a framework today:

• If you are already on Java 17+ and not using the Spring modules, moving from 5.x to 6.0.1 is close to a version bump. Do it.
• If you are stuck below Java 17, 5.5.7 (16 January 2026) is the end of the 5.x line — plan the Java upgrade rather than assuming 5.x will keep receiving fixes indefinitely.
• If you use spring-mock-mvc or spring-web-test-client, 6.0.1 is the release that stops those modules dragging their own Spring version onto your classpath, which is what made Spring Boot 4 upgrades require manual exclusions.

On the runner side, TestNG 7.12.0 (22 January 2026) is current; the reference project pins 7.10.2. Extent Reports 5.1.2 is the latest — that artifact has been stable since mid-2024, so a version that looks stale is simply finished.

None of this changes the architecture below. But “which version am I on, and why” is exactly the question a senior reviewer asks about a framework, and “whatever the tutorial said in 2021” is not an answer.

Layer 0: The Project Layout Everything Else Depends On

One rule drives the whole structure:

Reusable code lives in src/main/java. Only thin test classes live in src/test/java.

That sounds like Maven pedantry. It is actually an enforcement mechanism. Test sources can see main sources, but not the other way around — so the moment you put a utility in src/main/java, the compiler guarantees it cannot reach back into a test class. The layering is enforced by the build, not by discipline.

src/main/java/com/gorest
├── config
│   └── ConfigManager.java          # reads config.properties (-D / env override)
├── constants
│   ├── IEndpointLibrary.java       # every endpoint path, one place
│   ├── StatusCode.java             # 200 / 201 / 204 / 401 / 404 / 422
│   └── FrameworkConstants.java     # config keys, folders, domain values
├── pojo
│   ├── User.java                   # request + response model
│   ├── Post.java
│   └── ApiError.java               # 422 field/message entry
├── reporting
│   ├── ExtentReportListener.java
│   ├── ExtentReportManager.java
│   └── ExtentRestAssuredFilter.java
└── utils
    ├── RestAssuredUtility.java     # base URI, auth, request/response specs
    ├── JsonUtility.java            # POJO <-> JSON, payload templates, GPath reads
    ├── TestDataUtility.java        # unique users / posts, invalid ids
    └── LogUtility.java

src/test/java/com/gorest
├── base
│   ├── BaseTest.java               # suite setup + fixtures + cleanup
│   └── AuthenticatedTest.java      # skips write tests when no token is set
├── data
│   └── UserDataProvider.java       # valid / invalid data sets
└── tests
    ├── GetUserTests.java           # READ    (no token needed)
    ├── CreateUserTests.java        # CREATE
    ├── UpdateUserTests.java        # UPDATE  (PUT + PATCH)
    ├── DeleteUserTests.java        # DELETE
    ├── UserValidationTests.java    # 422 validation
    ├── UnauthorizedAccessTests.java  # 401 (no token needed)
    └── UserPostTests.java          # nested resource /users/{id}/posts

Notice what the test package doesn’t contain: no HTTP client setup, no auth handling, no JSON building, no data generation. Seven files, each named after the behaviour it protects.

Layer 1: Configuration That Never Gets Committed

Hardcoded values are the most common reason a framework can’t run anywhere except the machine it was written on. The fix is a small config class with a strict lookup order:

public static String get(String key) {
    // 1. system property  —  mvn test -Dtoken=xxxx
    String value = System.getProperty(key);

    // 2. environment variable  —  TOKEN=xxxx
    if (isBlank(value)) {
        value = System.getenv(key.toUpperCase().replace('.', '_'));
    }

    // 3. config.properties
    if (isBlank(value)) {
        value = PROPERTIES.getProperty(key);
    }
    return isBlank(value) ? null : value.trim();
}

Three sources, first match wins:

1. System properties — mvn test -Dtoken=xxxx. Overrides everything, for a single run, without editing a file.
2. Environment variables — TOKEN=xxxx. This is the one CI uses, injected from a secrets store.
3. config.properties — harmless defaults only. Base URI, base path, timeout. Things that are safe to commit.

The key.toUpperCase().replace('.', '_') line is doing quiet work: it lets a property named max.response.time.ms be overridden by an environment variable named MAX_RESPONSE_TIME_MS, which is the convention every CI system expects. Without it, you end up maintaining two names for every setting.

On top of that, typed accessors give the rest of the framework a clean surface with sensible fallbacks:

public static String baseUri()  { return get(BASE_URI, "https://gorest.co.in"); }
public static String basePath() { return get(BASE_PATH, "/public/v2"); }
public static long maxResponseTimeMs() { return getInt(MAX_RESPONSE_TIME_MS, 5000); }

Nothing in a test class ever calls System.getProperty. It calls ConfigManager.baseUri(), and the day someone adds a fourth configuration source, exactly one file changes.

Layer 2: Specs, the Highest-Leverage Pattern in REST Assured

If you take one thing from this article, take this one. RequestSpecBuilder and ResponseSpecBuilder let you define the repetitive half of every call once and plug it in with .spec(...).

Three request specs cover essentially every scenario an API suite needs:

/** JSON request carrying the bearer token — POST / PUT / PATCH / DELETE. */
public static RequestSpecification requestSpec() {
    return requestSpecWithToken(ConfigManager.token());
}

/** JSON request with no Authorization header — GoREST allows anonymous reads. */
public static RequestSpecification requestSpecWithoutAuth() {
    return new RequestSpecBuilder()
            .setContentType(ContentType.JSON)
            .setAccept(ContentType.JSON)
            .build();
}

/** JSON request with a caller-supplied token — for negative auth tests. */
public static RequestSpecification requestSpecWithToken(String token) {
    return new RequestSpecBuilder()
            .setContentType(ContentType.JSON)
            .setAccept(ContentType.JSON)
            .addHeader("Authorization", "Bearer " + token)
            .build();
}

That third method is the one people forget to build, and it is the one that makes security testing possible. Without it, “what happens when a caller presents a garbage token” is awkward to express; with it, it’s one line. (If the token you’re feeding in is a JWT rather than an opaque string, the JWT debugger is a fast way to check what’s actually inside the one your auth service issued before you assert on the response.)

The response side is where it gets genuinely clever:

public static ResponseSpecification jsonResponseSpec(int expectedStatusCode) {
    return new ResponseSpecBuilder()
            .expectStatusCode(expectedStatusCode)
            .expectContentType(ContentType.JSON)
            .expectResponseTime(lessThan(ConfigManager.maxResponseTimeMs()),
                                TimeUnit.MILLISECONDS)
            .build();
}

A response-time ceiling is baked into the shared response spec. Every test in the suite silently enforces a latency budget, pulled from configuration, with no performance-specific code anywhere. Tighten the number in config.properties and the whole suite starts caring more. That is a lot of value for four lines, and it only becomes possible once specs exist.

There’s a separate responseSpec(...) without the content-type check, because a 204 No Content response legitimately has no body — asserting application/json on it would fail for entirely correct behaviour. Small detail, but it’s the difference between a framework and a framework that actually runs.

With both layers in place, here is what a real test looks like:

@Test(groups = {"smoke", "regression"},
      description = "GET /users returns 200 with a non-empty list "
                  + "matching the user schema")
public void getAllUsers_shouldReturnUserList() {
    given()
            .spec(RestAssuredUtility.requestSpecWithoutAuth())
    .when()
            .get(IEndpointLibrary.USERS)
    .then()
            .spec(RestAssuredUtility.jsonResponseSpec(StatusCode.OK))
            .body("size()", greaterThan(0))
            .body("id", everyItem(notNullValue()))
            .body("email", everyItem(notNullValue()))
            .body(matchesJsonSchemaInClasspath("schemas/user-list-schema.json"));
}

Everything in that method is about this endpoint’s behaviour. Status code, content type, response-time budget, headers and auth are all handled by the two specs. Change the auth scheme tomorrow and this test doesn’t move.

Layer 3: Endpoints and Status Codes as Constants

This layer is almost embarrassingly simple and pays for itself the first time an API version changes:

public interface IEndpointLibrary {
    String USERS       = "/users";
    String USER_BY_ID  = "/users/{userId}";
    String POSTS       = "/posts";
    String USER_POSTS  = "/users/{userId}/posts";
    String USER_TODOS  = "/users/{userId}/todos";
}

Note the {userId} placeholders — those are REST Assured path parameters, so a test calls .get(IEndpointLibrary.USER_BY_ID, userId) and the substitution happens inside the library. No string concatenation, no "/users/" + id scattered through the suite, and no accidental double slashes.

Status codes get the same treatment through a small enum, so assertions read StatusCode.UNPROCESSABLE_ENTITY instead of a bare 422:

public enum StatusCode {
    OK(200), CREATED(201), NO_CONTENT(204),
    UNAUTHORIZED(401), NOT_FOUND(404), UNPROCESSABLE_ENTITY(422);
    // ...
}

Whether this is worth it comes down to whether you’d rather review a diff containing 422 or one containing UNPROCESSABLE_ENTITY. For anyone who has ever confused 401 with 403 in a code review — and everyone has — naming them helps. If those distinctions are fuzzy, the HTTP status codes guide covers what each category actually promises.

Layer 4: POJOs Instead of Hand-Built JSON

Building request bodies as strings is the other habit that doesn’t survive contact with a real API. Escaped quotes, no compile-time checking, and a rename in the API contract that produces a runtime failure three hundred lines from its cause.

Model the resource as a plain Java object and let Jackson do the conversion:

@JsonInclude(JsonInclude.Include.NON_NULL)
@JsonIgnoreProperties(ignoreUnknown = true)
public class User {
    private Integer id;
    private String name;
    private String email;
    private String gender;
    private String status;
    // constructors, fluent setters...
}

Two annotations there carry most of the weight, and they’re worth understanding rather than copying:

@JsonInclude(NON_NULL) keeps unset fields out of the serialized body. That single annotation is what allows one POJO to serve both a full POST (name, email, gender, status) and a partial PATCH that sends only status. Without it, a PATCH would send four fields with three nulls, and a well-behaved API would either reject it or — much worse — accept it and null out real data.

@JsonIgnoreProperties(ignoreUnknown = true) means the provider can add a field to the response tomorrow without every deserialization in your suite throwing. Additive API changes are supposed to be backwards compatible; this is the annotation that makes your framework agree.

Using it is then unremarkable, which is the point:

User user = TestDataUtility.randomUser();

Integer userId =
    given()
            .spec(RestAssuredUtility.requestSpec())
            .body(user)                    // Jackson serializes it
    .when()
            .post(IEndpointLibrary.USERS)
    .then()
            .spec(RestAssuredUtility.jsonResponseSpec(StatusCode.CREATED))
            .extract()
            .path("id");

Writing POJOs by hand for a large API is tedious enough that people skip it and go back to strings. If you have a sample response, the free JSON to POJO generator produces the Jackson-annotated class — including Lombok and record variants — in one paste; there’s a fuller walkthrough in the JSON and Java conversion guide.

Layer 5: Schema Validation Catches What Assertions Miss

Value assertions check that today’s data is right. Schema assertions check that the shape of the response is still the shape you built against — and that’s the failure that slips through everything else.

Consider a field changing from "id": "4471" to "id": 4471. Status code: still 200. Your value assertions: probably still pass, since GPath is forgiving about types. Your mobile client: crashes on the next release, because it was parsing a string.

.body(matchesJsonSchemaInClasspath("schemas/user-schema.json"))

One line, added to the response side of a test you already have, and a type change becomes a loud failure naming the exact field. The schemas live in src/test/resources/schemas/ — in the reference project, user-schema.json, user-list-schema.json and post-schema.json — and the json-schema-validator artifact is pinned to the same version as REST Assured itself, which matters because a mismatch there produces some genuinely confusing classpath errors.

The usual objection is that writing schemas is work. It mostly isn’t: capture a known-good response, run it through the JSON to Schema generator, tighten the required array down to the fields you actually depend on, and commit it. Ten minutes per resource, once. The schema validation guide goes deeper on where schema checks sit relative to OpenAPI and full contract testing.

Layer 6: Test Data That Survives a Hundred Runs

Here is the failure mode that quietly destroys trust in a suite: it passes the first time and fails the second, because the API rejected a duplicate email that the test itself created an hour ago.

Two patterns fix it permanently. First, generate data that cannot collide:

/** Unique by construction: timestamp + random suffix. */
public static String uniqueEmail() {
    return "qa.auto." + System.currentTimeMillis() + "."
            + ThreadLocalRandom.current().nextInt(1000, 9999) + "@testmail.com";
}

A timestamp alone is not quite enough — two tests starting inside the same millisecond will collide, which is exactly what happens the day someone enables parallel execution. The random suffix costs nothing and removes the class of failure entirely. ThreadLocalRandom rather than a shared Random is deliberate for the same reason.

Second, clean up after yourself, in a shared parent so no individual test has to remember:

public class BaseTest {

    private final List<Integer> createdUserIds = new ArrayList<>();

    @AfterClass(alwaysRun = true)
    public void cleanUpCreatedUsers() {
        if (!ConfigManager.isTokenConfigured()) return;
        createdUserIds.forEach(this::deleteUserQuietly);
        createdUserIds.clear();
    }

    /** Best-effort delete used for cleanup — never fails a test. */
    protected void deleteUserQuietly(Integer userId) {
        try {
            given().spec(RestAssuredUtility.requestSpec())
            .when().delete(IEndpointLibrary.USER_BY_ID, userId)
            .then().statusCode(anyOf(is(StatusCode.NO_CONTENT.code()),
                                     is(StatusCode.NOT_FOUND.code())));
        } catch (RuntimeException e) {
            LogUtility.warn("Cleanup of user " + userId + " failed: " + e.getMessage());
        }
    }
}

Three deliberate choices in that teardown, all of which matter more than they look:

• alwaysRun = true — cleanup happens even when the test failed. Especially then, in fact, since a failed test is the one most likely to have left a half-created resource behind.
• anyOf(204, 404) counts as success. If the test already deleted the user itself, the cleanup pass gets a 404. That’s the desired state, not an error.
• The whole thing is wrapped in a try. A cleanup failure logs a warning. It never fails a test, because “the API was briefly unavailable during teardown” is not a defect report anyone wants to receive.

There’s also an untrack(id) helper for the case where a delete test removed the resource on purpose — so the teardown doesn’t bother chasing something that’s already gone.

Skip, Don’t Fail: the Missing-Token Problem

This is my favourite detail in the reference project, and one I rarely see in public frameworks.

GoREST allows anonymous reads, but every write needs a personal access token. A new contributor clones the repo, runs mvn clean test, and — in most frameworks — gets a wall of red, every failure a bare 401 Unauthorized. They now have to work out whether the API is broken, the framework is broken, or they missed a setup step.

A SkipException thrown from a shared parent turns that into a clear message:

public class AuthenticatedTest extends BaseTest {

    @BeforeClass(alwaysRun = true)
    public void verifyTokenIsConfigured() {
        if (!ConfigManager.isTokenConfigured()) {
            throw new SkipException(
                    "No GoREST token configured. Run with -Dtoken=<your-token> "
                            + "or set it in src/main/resources/config.properties");
        }
    }
}

Write-test classes extend AuthenticatedTest; read-only and unauthorized-access classes extend BaseTest directly and keep running normally. The result: a first-time clone produces a green run with a clearly labelled skipped section, not a wall of red that means nothing.

The underlying principle generalizes well beyond tokens. A red test should mean “the system under test is wrong.” Anything else — missing config, unreachable environment, absent credentials — should be a skip with a reason. Suites that blur that line are the ones where people stop reading the failures.

Suites, Groups and CI

Every test carries TestNG groups, which is what makes one codebase serve two different jobs:

@Test(groups = {"smoke", "regression"}, description = "...")

Seven of the 33 tests are tagged smoke. A separate testng-smoke.xml selects that group, and a Maven profile switches which suite file Surefire runs:

<properties>
    <!-- Suite that `mvn test` runs. Override with -Dsuite.file=testng-smoke.xml -->
    <suite.file>testng.xml</suite.file>
</properties>

<profiles>
    <profile>
        <id>smoke</id>
        <properties><suite.file>testng-smoke.xml</suite.file></properties>
    </profile>
</profiles>

Which gives CI a vocabulary:

mvn clean test                          # full regression suite
mvn clean test -Psmoke                  # smoke subset, for every commit
mvn clean test -Dtoken=<your-token>     # full suite including write scenarios
mvn clean test -Dtest=GetUserTests      # one class, while debugging

The full suite is organized into four <test> blocks — Read, Write, Negative, Posts — which is worth doing even before you need parallelism, because a report grouped by intent is far easier to scan than one long alphabetical list.

One honest note: the reference testng.xml does not set parallel or thread-count, so it runs single-threaded. That’s a deliberate choice for a suite hitting a shared public API with rate limits, not an oversight — but it does mean the suite is slower than it needs to be against a private environment. Those two attributes, plus the handful of others that decide whether a suite is fast and survivable in CI, are covered in TestNG suite XML attributes explained; if you’d rather generate a correct suite file than hand-edit one, the TestNG XML generator builds parallel and cross-browser blocks visually.

Reporting for the 2 a.m. Failure

A pipeline that says “18 passed, 1 failed” and nothing else is a pipeline that costs you an hour.

The reference project wires Extent Reports in through a TestNG listener, plus a custom REST Assured Filter — ExtentRestAssuredFilter — that attaches the actual request and response to the report entry for each test. That filter is the part worth copying. Anyone can add an HTML reporter; what makes a report useful at 2 a.m. is seeing the exact payload that was sent and the exact body that came back, without rerunning anything locally.

The initialization hides a REST Assured feature people miss:

RestAssured.enableLoggingOfRequestAndResponseIfValidationFails();

That single call logs the full request and response only when an assertion fails. Always-on logging drowns a CI console and makes real failures harder to find; this gives you complete detail exactly where you need it and silence everywhere else.

Everything lands in predictable places — target/surefire-reports/ for the TestNG output, target/extent-reports/extent-report.html for the rich report, target/logs/api.log for the wire log — so a CI job can archive the whole target/ directory and be done.

What This Architecture Does Not Solve

Being straight about the limits is part of the design, so here’s what six clean layers still leave on the table.

It isn’t parallel-ready as written. Single-threaded execution sidesteps the question, but flipping parallel="classes" on tomorrow surfaces real issues: static state in the REST Assured initializer, shared report context, and fixtures that assume a class owns its data. Getting that right needs ThreadLocal report tracking and genuinely immutable specs — I wrote up those decisions, and an HTTP 418 debugging story that came out of them, in API tests that fail on purpose.

Schema validation is not contract testing. Asserting a response against a committed schema catches drift after the provider deploys. Consumer-driven contract testing catches it in the provider’s own build, before merge. They complement each other; one does not replace the other.

There is no load or resilience testing here. The response-time budget in the response spec is a smoke alarm, not a performance suite. It will tell you something regressed badly. It won’t tell you what happens at 500 requests per second.

And it does not decide what to test. This is the real limit. A framework makes writing the two hundredth test cheap; it has no opinion on whether that test is worth having. Coverage that is 90% happy path is still 90% happy path no matter how cleanly it’s layered — which is the argument the API testing automation guide makes at more length.

Clone It and Read It

Architecture articles are easier to agree with than to apply, so the framework every snippet above came from is public:

github.com/abhay-1994/GoRest_RestAssuredFreamework

It runs against GoREST, a live public API, and the read tests need no token at all — so mvn clean test works on a fresh clone with nothing configured. 33 test methods across 7 classes cover CRUD, pagination, status and gender filtering, nested resources, 401 handling and 422 validation, with schema assertions throughout.

Read it in roughly this order and the design explains itself: ConfigManager → RestAssuredUtility → BaseTest → any test class. Four files, and by the end the reason test classes are so short is obvious.

Frequently Asked Questions

What is a REST Assured framework?

A structured Java project that splits API automation into reusable layers — configuration, endpoint constants, request and response specifications, data models, and test utilities — so test classes stay thin and readable. The defining rule is that everything reusable lives in src/main/java and only thin given/when/then test classes live in src/test/java. That separation is what lets a suite grow from ten tests to several hundred without every API change breaking dozens of files.

Do I need TestNG, or can I use JUnit with REST Assured?

Both work — REST Assured is runner-agnostic. TestNG is more common for API frameworks because it gives you groups (a smoke subset and a full regression suite from the same code), suite XML files, data providers with their own thread count, and configuration policies for what happens when a setup method fails. If your team already runs JUnit 5, tags and extensions cover most of the same ground, and switching purely for REST Assured is rarely worth it.

What is the difference between RequestSpecBuilder and writing given() in every test?

A RequestSpecification built once and reused via given().spec(...) centralizes content type, accept headers and authentication, so changing any of them is a one-line edit rather than a find-and-replace across the suite. Writing given().header(...).contentType(...) in every test duplicates that setup in every file — which is exactly what makes a suite expensive the day a token format changes.

How do you keep API tokens out of a test framework repository?

Read every setting through a small config class that checks, in order: system properties (mvn test -Dtoken=xxxx), then environment variables (TOKEN=xxxx), then a committed config.properties used only for harmless defaults like the base URI. Secrets are injected at run time by CI and never written into the repository, while any value can still be overridden for a single local run.

Should API tests clean up the data they create?

Yes, and the cleanup should be best-effort. A test that creates a resource deletes it in an @AfterClass(alwaysRun = true) teardown, treating both 204 and 404 as success, wrapped so a failed delete logs a warning instead of failing an unrelated test. Without cleanup, environments accumulate junk and suites that assert on counts start failing for reasons unrelated to any defect.

What is the current version of REST Assured?

REST Assured 6.0.1, released 10 July 2026. The 6.0.0 release before it (12 December 2025) raised the minimum Java baseline to 17 and Groovy to 5.x, added Jackson 3 object mapping, and migrated json-path fully to Java so it no longer evaluates through GroovyShell — fixing memory leaks in long-running processes. 6.0.1 also fixed a JsonPath denial-of-service involving oversized numeric literals. The last 5.x release is 5.5.7 from 16 January 2026.

Should a test fail or skip when no API token is configured?

Skip. A missing token is a configuration problem, not a defect in the API, and failing every write test with a bare 401 buries real failures in noise. Throwing a TestNG SkipException from a @BeforeClass hook in a shared parent marks those tests skipped with an explicit reason, while read-only and unauthorized-access tests keep running.

How many tests should a REST Assured framework start with?

Fewer than feels satisfying. Cover the happy path plus failure cases for your highest-risk endpoints first — missing required field, invalid auth, and a boundary value each — and wire the suite into CI before expanding. Twenty well-maintained tests that block a bad merge beat four hundred nobody trusts.

Key Takeaways

• A framework is not more REST Assured knowledge — it’s deciding, on purpose, where every changeable thing lives.
• src/main/java for reusable code, src/test/java for thin tests. The compiler then enforces the layering for you.
• Request and response specs are the highest-leverage pattern in REST Assured. Three request specs and two response specs make most duplication disappear.
• Put a response-time ceiling in the shared response spec and every test enforces a latency budget for free.
• @JsonInclude(NON_NULL) is what lets one POJO serve both a full POST and a partial PATCH.
• Schema validation catches the type-change class of break that value assertions and status codes both miss.
• Unique-by-construction test data plus alwaysRun = true cleanup is what makes a suite rerunnable a hundred times.
• Missing configuration should skip with a reason, never fail. A red test must mean the system under test is wrong.
• Check your versions: REST Assured 6.0.1 is current, 6.0.0 moved the Java baseline to 17, and 5.5.7 is the end of the 5.x line.

The Bottom Line

The framework isn’t the impressive part. Four Java classes and an interface full of string constants is not clever engineering — it’s a couple of afternoons of work that any mid-level engineer could do.

What’s impressive is what it buys: a test class you can read in ten seconds, an auth change that touches one file, and a suite that runs identically on a laptop, in Jenkins, and on a new hire’s first morning without anyone editing a property.

Start with the config class and the specs. Those two alone eliminate most of the duplication a growing suite accumulates, and everything else in this article is easier to add once they exist.

Then go read someone else’s framework — this one, or any other — and pay attention to what its test classes don’t contain. That absence is the whole design.

---

Written by Abhay Kumar — QA engineer and creator of OrbitTest, building practical tools for browser, mobile, and API testing. Browse more API testing articles.