H6 · JUnit 5/TestNG Integration + CI: REST Assured is ONLY an HTTP CLIENT — the answer to "who RUNS the request, who REPORTS it" is JUnit 5 or TestNG.
REST Assured is ONLY an HTTP CLIENT — the answer to "who RUNS the request, who REPORTS it" is JUnit 5 or TestNG. This is the EXACT same role as Newman from G6: Newman RUNS/REPORTS a Postman collection, JUnit/TestNG runs/reports a REST Assured test CLASS. `mvn test` (or `mvn verify`) triggers these tests from the command line/in CI — they live in the SAME Maven project as the app code you wrote in GROUP B. So why does this matter — couldn't tests be a separate project? Because living in the same project GUARANTEES the test runs AUTOMATICALLY in the SAME `mvn install`/CI step when the code CHANGES; if it were a separate project, the "forgetting to run tests too" risk (like in G4) would return. **For a deep JUnit/TestNG+CI setup guide → see the `/rest-assured` page.**
🎬 REST Assured's Newman Counterpart
REST Assured: just a client
JUnit/TestNG runs it
REST Assured alone is just a request-sending tool — WHO will run it?
JUnit 5/TestNG finds `@Test` methods, RUNS them, and REPORTS the result — the REST Assured counterpart of G6's Newman.
`mvn test` wires this into CI — in the SAME project as the GROUP B code, running AUTOMATICALLY on every push.
The Order for Wiring a REST Assured Test into CI
Write with JUnit/TestNG…
Wrap the REST Assured code in a test method with the @Test annotation.
Verify with mvn test…
Run mvn test locally and verify the test passes.
Add mvn test to the workflow AFTER the step that starts the app.
Order the process for wiring REST Assured tests into CI.