Interview Corner — Walk Me Through Your Project

A: I built an end-to-end API test suite covering two APIs — JSONPlaceholder for CRUD and resource relationships, ReqRes.in for authentication and pagination. The Postman side has a 20+ request collection with environment variables, chained requests, and assertions on every request. I run it through Newman with HTML reports and CSV data-driven iterations. The REST Assured side is a Maven project with TestNG, Jackson, and Allure. It has ConfigReader for environment switching, BaseTest with AllureRestAssured filter, and POJOs for type-safe request/response handling. Tests are split into four classes: PostCrudTests with 10 tests covering all HTTP methods, PostSchemaTests validating JSON schema for 3 resources, PostNegativeTests with 11 tests covering invalid IDs, missing fields, and edge cases, and PostDataDrivenTests using DataProvider with external JSON files. Total 46 test executions. Full suite runs under 2 minutes with Allure report showing request/response details for every test.

A: The negative testing design was the trickiest part. JSONPlaceholder is a mock API — it accepts almost anything. POST with empty body? Returns 201. String where integer is expected? Accepted. In a real API, these would be 400 errors. The challenge was documenting the expected behavior accurately and noting where a real API would behave differently. I added comments in each negative test explaining what a production API would return. This taught me that test expectations must match the API under test, not what you think the API should do.

A: I prioritize by risk and usage. Smoke tests cover the critical path — can I create a resource, can I read it back, does authentication work. These run on every build. Then regression adds filtering, pagination, schema validation, and negative tests. Edge cases come last. I tag tests with TestNG groups — smoke runs in 30 seconds and catches show-stoppers. Full regression runs nightly. If I find a bug in production, I write a failing test first, then add it to the smoke suite so it never regresses.

A: Four steps. First, I add the JSON schema file to resources/schemas/. Second, I create a POJO for the request and response if the body structure is new. Third, I write tests — typically one CRUD test, one schema test, and two to three negative tests. Fourth, I add the test class to testng.xml. The whole process takes about 30 minutes because the framework handles all the boilerplate. ConfigReader, BaseTest, Allure filter — all inherited automatically. The new test class just extends BaseTest and starts writing assertions.

A: Three things. First, I would add an endpoint layer — wrapper classes like PostEndpoint and UserEndpoint that encapsulate REST Assured calls, so tests never see given().when().get() directly. I skipped it here to keep the capstone focused on testing concepts. Second, I would add test data cleanup — create data in @BeforeMethod, delete in @AfterMethod, so tests are truly independent. Third, I would integrate with CI/CD — GitHub Actions running smoke on every PR, regression nightly, with Allure report published as a build artifact and Slack notifications on failure.