🏗️ Framework Architecture (SOLID + POM)

Framework Architecture (SOLID + POM): Every piece you have learned up to this tab (given/when/then, POJO, auth, JSON path, test chaining) works on its own but has NOT yet been wi

Every piece you have learned up to this tab (given/when/then, POJO, auth, JSON path, test chaining) works on its own but has NOT yet been wired into an architecture — the "@BeforeAll static RequestSpecification spec" pattern you saw in `raBaseTestStep` at the top of this file is EXACTLY the foundation of this tab; now we build all its layers. RequestSpecBuilder is a print shop's letterhead template: no document (no request) redraws the same logo/address (baseURI, shared headers, filters) from scratch, they all use ONE template. Second analogy: compare it to Selenium's DriverManager/WaitFactory — there, the problem was "which thread gets which driver"; here that problem does NOT exist, because an HTTP request is stateless — what gets shared is not a browser session, it is the REQUEST CONFIGURATION (baseURI, content-type, filters). But since given().baseUri(...).header(...) can already be written in every test, why do you need RequestSpecBuilder — isn't copying those four-five lines enough? It is, but ONLY for one test class; if you rewrite those lines in EVERY one of 30 test classes, an environment change (staging→prod baseURI) means scanning 30 files by hand. Java comparison: this is the SAME motivation as setting up a shared `RestTemplate`/`WebClient` bean in Spring — centralize expensive, repeated configuration. QA context: without RequestSpecBuilder, adding a new required header to the API (e.g. `X-API-Version`) breaks 30 files; with a centralized spec, it is a ONE-line change.

Build Your REST Assured Framework Step by Step

The 4 pieces below are the BIG PICTURE of the architecture you are about to build piece by piece in this tab. They all start locked — the first time you correctly finish that step's "Try It Yourself" practice, that piece flips from locked to BUILT.

Core / RequestSpec Layer

Service Object Instead of "POM"

🧭 Step 1 — The Big Picture: The RequestSpec Chain Mindmap

The same architecture is shown here from five angles: first the main flow (how a request gets built when a test runs), then the setup flow (from pom.xml to BaseTest, then to the test class), then "parallel execution" (why the class-level isolation of a static spec in JUnit5 DIFFERS from Selenium's ThreadLocal), then the data-sharing scope (static/instance/parameter scope), and finally a "does / does not" list for every class.

3️⃣ Parallel Execution — Why Does a static spec DIFFER from Selenium's ThreadLocal?

Class-Level Isolation

JUnit5 Parallel Classes

In Selenium, ThreadLocal was needed because what was shared was a WebDriver SESSION — isolation was required so different threads in the same process would not MIX UP the same browser. In REST Assured, what is shared is a RequestSpecification CONFIGURATION — since an HTTP request is stateless by nature, even if 10 different test methods USE the same spec at the same time, they never interfere with each other (every `given().spec(spec)` call builds its own independent request). So what matters FOR your framework architecture is not ThreadLocal, but the static field being set up correctly at the CLASS level (each class builds its own spec in its own @BeforeAll).

4️⃣ Data-Sharing Scope — How Long Does Each Thing Live?

static (class level)

instance (method level)