← Back to libraryQuestion 246 of 468
🔌REST AssuredAdvanced

Common Pitfalls and Best Practices

📌 Definition:

Frequent REST Assured mistakes include: missing static imports, asserting only the status code, wrong GPath for root arrays, null JsonPath results, not setting contentType, SSL/certificate errors, and leaking static config between tests.

📖 Detailed Explanation:

Key gotchas: (1) Forgetting static imports (given/equalTo won't compile). (2) Status-only assertions that miss body defects. (3) GPath errors — root arrays use [0], collection projections vs single objects. (4) Extracting a path that doesn't exist returns null, causing confusing NPEs downstream — assert presence first. (5) 415 from missing contentType. (6) SSL handshake failures against self-signed certs — use .relaxedHTTPSValidation(). (7) Static RestAssured.baseURI/config leaking across test classes — reset() in teardown. Best practices: use specs, POJOs, schema validation, externalized config, conditional logging, and clean up created data.

🔑 Key Points:
  • Assert body + schema, not just status; fix GPath for root arrays
  • Null JsonPath extraction → NPE; validate presence first
  • Missing contentType → 415; SSL → relaxedHTTPSValidation()
  • Reset static config between classes; use specs/POJOs/cleanup
🌍 Real-World Example:

A suite intermittently fails because one test set RestAssured.baseURI and another relied on the default; adding RestAssured.reset() in @AfterClass isolates them and stops the cross-test leakage.

🎯 Scenario-Based Interview Question:

One test class works alone but breaks when run after another class. What REST Assured behavior likely causes this and how do you fix it?