In REST Assured, what state does RestAssured.reset() actually put back?

middlemust knowfreq 57%

answer

the library's own undo
two constants, only one is used
-1 is a sentinel, not a port
the filter list is emptied too
the wiki says 8080 and is wrong

basics

~20 s

RestAssured.reset() restores baseURI, basePath, rootPath, authentication and urlEncodingEnabled to their constants. It nulls requestSpecification, responseSpecification, defaultParser, sessionId and proxy, empties the filter list, drops parser registrations, installs a fresh RestAssuredConfig, and sets port to UNDEFINED_PORT (-1), not 8080.

solid answer

~50 s

RestAssured.reset() is the library's own undo for its static entry surface. It puts baseURI back to DEFAULT_URI ("http://localhost"), basePath and rootPath back to "", authentication back to a NoAuthScheme, and urlEncodingEnabled back to true; it nulls requestSpecification, responseSpecification, defaultParser, sessionId and proxy; it replaces the filter list with an empty one and the parser registrar and config with fresh instances. The trap is port: reset() assigns UNDEFINED_PORT, which is -1, not DEFAULT_PORT, which is 8080. REST Assured's own wiki repeats the mistake: its Default values section says reset gives you the "standard port (8080)". So a teardown assertion like assertEquals(8080, RestAssured.port) fails against a correct library, and -1 is simply the sentinel for no explicit port was requested. Two consequences bite in practice: emptying the filter list discards a logging filter you registered once at startup, and rebuilding the parser registrar forgets every registerParser(...) call.

`RestAssured.reset()` is the library's own undo for its static entry surface. It puts `baseURI` back to `DEFAULT_URI` (`"http://localhost"`), `basePath` and `rootPath` back to `""`, `authentication` back to a `NoAuthScheme`, and `urlEncodingEnabled` back to `true`; it nulls `requestSpecification`, `responseSpecification`, `defaultParser`, `sessionId` and `proxy`; it replaces the filter list with an empty one and the parser registrar and `config` with fresh instances. The trap is `port`: `reset()` assigns `UNDEFINED_PORT`, which is **`-1`**, not `DEFAULT_PORT`, which is `8080`. REST Assured's own wiki repeats the mistake: its *Default values* section says reset gives you the "standard port (8080)". So a teardown assertion like `assertEquals(8080, RestAssured.port)` fails against a correct library, and `-1` is simply the sentinel for *no explicit port was requested*. Two consequences bite in practice: emptying the filter list discards a logging filter you registered once at startup, and rebuilding the parser registrar forgets every `registerParser(...)` call.

code

java · 17 lines

java

import io.restassured.RestAssured;

// a class that had to deviate puts the JVM back afterwards
RestAssured.baseURI = "https://staging.roster.belltower.test";
RestAssured.port = 9443;
RestAssured.basePath = "/api/v2";

RestAssured.reset();

System.out.println(RestAssured.baseURI);   // http://localhost
System.out.println(RestAssured.basePath);  // "" (empty)
System.out.println(RestAssured.port);      // -1  <- UNDEFINED_PORT, NOT 8080
System.out.println(RestAssured.filters()); // [] - every default filter is gone

// so re-apply the suite defaults reset() just deleted
RestAssured.baseURI = "https://roster.belltower.test";
RestAssured.basePath = "/api/v2";

go deeper

for a junior

Know that RestAssured.reset() exists, that it takes no arguments, and that it puts the RestAssured statics back to their defaults so the next test class starts from a clean entry surface.

for a middle

Be able to enumerate what reset() touches and to say that port goes to UNDEFINED_PORT (-1), not DEFAULT_PORT (8080). Explain that -1 is a sentinel meaning no explicit port was requested.

for a senior

Point out the operational consequences: reset() also empties the filter list and drops parser registrations, so a teardown that resets must re-apply the suite defaults or CI loses its logging from the second class onward.

for a principal

Frame reset() as the escape hatch a mutable-global configuration surface is forced to ship. Decide whether your suite relies on it routinely or treats a static assignment as an exception that has to be argued for.

RestAssured.reset() is a single static method with no arguments and no return value. It exists because the settings it undoes are public static fields on io.restassured.RestAssured — process-wide state that no test owns and that nothing scopes for you. reset() is the one call that hands the JVM back in a known condition, and knowing exactly what "known condition" means is what separates a teardown that works from one that only looks like it does.

Field by field

Static	After `reset()`	Constant used
`baseURI`	`"http://localhost"`	`DEFAULT_URI`
`port`	`-1`	`UNDEFINED_PORT`
`basePath`	`""`	`DEFAULT_PATH`
`rootPath`	`""`	`DEFAULT_BODY_ROOT_PATH`
`authentication`	a new `NoAuthScheme`	`DEFAULT_AUTH`
`urlEncodingEnabled`	`true`	`DEFAULT_URL_ENCODING_ENABLED`
`sessionId`	`null`	`DEFAULT_SESSION_ID_VALUE`
`requestSpecification`	`null`	—
`responseSpecification`	`null`	—
`defaultParser`	`null`	—
`proxy`	`null`	—
`config`	a brand-new `RestAssuredConfig`	—
the filter list	a new empty `LinkedList`	—
the parser registrar	a new `ResponseParserRegistrar`	—

Two entries in that table are easy to miss. The filter list is emptied outright, so every filter you registered with RestAssured.filters(...) is gone — including the logging filter your CI output depends on. And the parser registrar is rebuilt, so any content type you taught the library with RestAssured.registerParser(...) is forgotten too.

The port trap

RestAssured declares both DEFAULT_PORT = 8080 and UNDEFINED_PORT = -1. reset() assigns the second one:

java

RestAssured.port = 9443;
RestAssured.reset();
System.out.println(RestAssured.port);   // -1, not 8080

The names invite the mistake, and REST Assured's own wiki reinforces it — the Default values section of Usage.md says reset() returns you to the "standard port (8080)". It does not. If your bell-tower roster suite asserts assertEquals(8080, RestAssured.port) in a teardown check, that assertion fails on a correct library.

-1 is not a broken value; it is a sentinel meaning "no explicit port was set", and the request-building code branches on port != UNDEFINED_PORT when it decides whether to append a port to the target URI at all. So the post-reset state is "nobody has asked for a port", which is a strictly different thing from "the port is 8080".

What `reset()` does not reach

reset() is thorough about RestAssured's own statics and blind to everything else. It will not help you with:

A RequestSpecification or RequestSpecBuilder object a test class is holding in a field. Those snapshotted the statics when they were constructed and keep their copies.
JsonSchemaValidator.settings in the json-schema-validator module, which is a separate static holder with its own JsonSchemaValidator.reset().
Anything your own harness caches — a token, a created roster id, a client object.
The server. reset() is a local field assignment; it sends nothing and undoes no data your tests created.

Using it well

The mechanical rules are short:

Call RestAssured.reset() in the teardown of any class that assigned a static, then re-apply your suite-wide defaults, because reset() has just deleted those too.
Do not assert 8080 anywhere after a reset — assert RestAssured.UNDEFINED_PORT, or assert nothing about the port at all.
Remember that reset() empties the filter list. A suite that registers a logging filter once at startup and calls reset() between classes loses its logs from the second class onward.
Prefer not needing it. A suite that assigns the statics once and never again does not have a teardown problem to solve.

Why the method exists at all

reset() is a symptom, not a feature. It is the escape hatch a library has to ship when its configuration surface is mutable global state: because nothing else can scope an assignment, the only way to bound one is to undo it manually and hope everybody remembers. Treating reset() as the first line of defence — rather than as a rescue for a suite that already writes globals from many places — is the reading that keeps a REST Assured suite predictable. The best-behaved suites call it exactly once, at the end of the run, because nothing else ever had to change a static in the first place.

`RestAssured.reset()` is a single static method with no arguments and no return value. It exists because the settings it undoes are `public static` fields on `io.restassured.RestAssured` — process-wide state that no test owns and that nothing scopes for you. `reset()` is the one call that hands the JVM back in a known condition, and knowing exactly what "known condition" means is what separates a teardown that works from one that only looks like it does. ## Field by field | Static | After `reset()` | Constant used | |---|---|---| | `baseURI` | `"http://localhost"` | `DEFAULT_URI` | | `port` | **`-1`** | **`UNDEFINED_PORT`** | | `basePath` | `""` | `DEFAULT_PATH` | | `rootPath` | `""` | `DEFAULT_BODY_ROOT_PATH` | | `authentication` | a new `NoAuthScheme` | `DEFAULT_AUTH` | | `urlEncodingEnabled` | `true` | `DEFAULT_URL_ENCODING_ENABLED` | | `sessionId` | `null` | `DEFAULT_SESSION_ID_VALUE` | | `requestSpecification` | `null` | — | | `responseSpecification` | `null` | — | | `defaultParser` | `null` | — | | `proxy` | `null` | — | | `config` | a brand-new `RestAssuredConfig` | — | | the filter list | a new empty `LinkedList` | — | | the parser registrar | a new `ResponseParserRegistrar` | — | Two entries in that table are easy to miss. The filter list is emptied outright, so every filter you registered with `RestAssured.filters(...)` is gone — including the logging filter your CI output depends on. And the parser registrar is rebuilt, so any content type you taught the library with `RestAssured.registerParser(...)` is forgotten too. ## The port trap `RestAssured` declares both `DEFAULT_PORT = 8080` and `UNDEFINED_PORT = -1`. `reset()` assigns the second one: ```java RestAssured.port = 9443; RestAssured.reset(); System.out.println(RestAssured.port); // -1, not 8080 ``` The names invite the mistake, and REST Assured's own wiki reinforces it — the *Default values* section of `Usage.md` says `reset()` returns you to the "standard port (8080)". It does not. If your bell-tower roster suite asserts `assertEquals(8080, RestAssured.port)` in a teardown check, that assertion fails on a correct library. `-1` is not a broken value; it is a **sentinel meaning "no explicit port was set"**, and the request-building code branches on `port != UNDEFINED_PORT` when it decides whether to append a port to the target URI at all. So the post-reset state is *"nobody has asked for a port"*, which is a strictly different thing from *"the port is 8080"*. ## What `reset()` does not reach `reset()` is thorough about `RestAssured`'s own statics and blind to everything else. It will not help you with: - A `RequestSpecification` or `RequestSpecBuilder` object a test class is holding in a field. Those snapshotted the statics when they were constructed and keep their copies. - `JsonSchemaValidator.settings` in the `json-schema-validator` module, which is a separate static holder with its own `JsonSchemaValidator.reset()`. - Anything your own harness caches — a token, a created roster id, a client object. - The server. `reset()` is a local field assignment; it sends nothing and undoes no data your tests created. ## Using it well The mechanical rules are short: 1. Call `RestAssured.reset()` in the teardown of any class that assigned a static, then re-apply your suite-wide defaults, because `reset()` has just deleted those too. 2. Do not assert `8080` anywhere after a reset — assert `RestAssured.UNDEFINED_PORT`, or assert nothing about the port at all. 3. Remember that `reset()` empties the filter list. A suite that registers a logging filter once at startup and calls `reset()` between classes loses its logs from the second class onward. 4. Prefer not needing it. A suite that assigns the statics once and never again does not have a teardown problem to solve. ## Why the method exists at all `reset()` is a symptom, not a feature. It is the escape hatch a library has to ship when its configuration surface is mutable global state: because nothing else can scope an assignment, the only way to bound one is to undo it manually and hope everybody remembers. Treating `reset()` as the *first* line of defence — rather than as a rescue for a suite that already writes globals from many places — is the reading that keeps a REST Assured suite predictable. The best-behaved suites call it exactly once, at the end of the run, because nothing else ever had to change a static in the first place.

Why is UNDEFINED_PORT a meaningfully different state from DEFAULT_PORT?
`-1` means *no explicit port was requested*, and REST Assured's request builder branches on `port != UNDEFINED_PORT` before it appends a port to the target URI. `8080` means *this exact port*, which would be pinned onto every host you call. Collapsing the two would make a fully qualified HTTPS base URI unusable without an explicit port on every request.
Your suite calls reset() between test classes and CI output goes silent after the first class. Why?
`reset()` empties the default filter list. A logging filter registered once at startup with `RestAssured.filters(...)` or `replaceFiltersWith(...)` is discarded by the first `reset()`, and nothing re-registers it. Re-apply your suite-wide defaults — filters included — immediately after every `reset()`, or move the registration to a place that runs again for each class.

It is a clear-the-field button, not a restore-factory-settings one: reset() blanks the port back to "nobody asked" rather than typing 8080 into the box.

saying these in an interview costs you the question

Says reset() restores the port to 8080
Thinks -1 means the port is broken or unset by mistake
Assumes reset() keeps registered default filters
Believes reset() undoes changes the tests made on the server
Expects reset() to clear a RequestSpecBuilder already constructed

In REST Assured, what state does RestAssured.reset() actually put back?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Field by field

The port trap

What reset() does not reach

Using it well

Why the method exists at all

▾common follow-ups2 questions

▾analogy~10 s

▾red flags5 flags

Field by field

The port trap

What reset() does not reach

Using it well

Why the method exists at all

answer

go deeper

What `reset()` does not reach

What `reset()` does not reach