Interview Corner — "Describe Your API Framework"

A: Our framework uses REST Assured with TestNG, Jackson for serialization, and Allure for reporting. It has 6 layers. Config layer reads environment-specific properties files using a ConfigReader. Base layer has BaseTest which creates a common RequestSpecification with base URI, content type, and AllureRestAssured filter. POJO layer has separate request and response model classes with Jackson annotations. Endpoint layer has one class per API resource — each method wraps a REST Assured call and returns a raw Response. Test layer uses DataProvider for data-driven tests and TestNG groups for smoke vs regression. Allure captures every request and response automatically. We run smoke tests on every PR in GitHub Actions and full regression nightly against staging. Switching environments is just -Denv=staging.

A: It depends on the auth mechanism. For token-based auth, BaseTest has a method that calls the auth endpoint, extracts the token, and adds it to the RequestSpec as a header. The credentials come from ConfigReader. For OAuth2, we store client_id and client_secret in config and generate a token in @BeforeSuite. For API key auth, the key is in config.properties and added as a header or query parameter in the RequestSpec. The key point is that individual test classes never deal with auth — BaseTest handles it once.

A: Three approaches depending on the scenario. For simple parametrized tests, we use TestNG DataProvider with inline data. For larger datasets, the DataProvider reads from CSV or JSON files in src/test/resources/testdata/. For tests that need dynamic data, we have a TestDataGenerator utility that creates random but valid data using Faker or custom logic. For cleanup, tests that create data also delete it in @AfterMethod. We follow the pattern: create data, use it, clean it up — so tests are independent and repeatable.

A: First, I check the Allure report. For each test, it shows the exact HTTP request (method, URL, headers, body) and the exact response (status, body). This is captured automatically by the AllureRestAssured filter. I can see exactly what was sent and received. If the issue is environmental, I check the config file to confirm the right base URL was used. If it is a data issue, I check the DataProvider. REST Assured also logs request and response details on validation failure, which shows up in the console. Between Allure and console logs, I can reproduce most issues within minutes.

A: Each test creates its own test data and cleans up after itself. We do not rely on shared state or test execution order. If testCreateUser creates a user, it stores the ID and deletes the user in @AfterMethod. DataProviders supply fresh data for each test run. We do not use static variables to share data between test classes. The BaseTest @BeforeClass creates a fresh RequestSpec for each class. If tests need a known starting state, we use API calls in setup methods to create it — never manual database inserts.