Changes Summary - details below

big-one touches almost all files with adding the formatter as requested by the coding guidelines
introduction of a BaseTest class to reduce complexity and increase maintainability
prep for keycloak OAuth
adding ServiceRegistry

ServiceRegistry

Abstraction Layer: ServiceRegistry acts as an abstraction layer over the ConfigProvider, hiding the direct interaction with raw configuration data and providing a more domain-specific interface for service-related operations.
Service-Oriented Organization: While ConfigProvider is a general configuration repository, ServiceRegistry specifically organizes and manages service configurations, making it easier to work with service-specific settings.

Centralized Service Access: As noted in its JavaDoc comment, ServiceRegistry "provides centralized access to service configurations" and "replaces the need for each test class to implement ServiceNameProvider." This centralizes service configuration logic in one place.

Filtering and Processing: ServiceRegistry filters out non-service entries (like "DEV_ENV_PARAMS" and "INT_ENV_PARAMS") and only registers valid service configurations, providing cleaner access to just service-related data.

Package-Based Service Discovery: The getServiceConfigForClass() method enables discovering the appropriate service configuration based on a class name, which is particularly useful in a test framework where you might need to determine which service a test class belongs to.

Lazy Loading of Base URIs: The ServiceConfig inner class implements lazy loading of base URIs, only retrieving them from ConfigProvider when needed.

Encapsulation: The ServiceConfig inner class encapsulates service-specific information (name, package, URI) in a cohesive object, rather than requiring consumers to work with separate maps as in ConfigProvider.

Reduced Dependency: Test classes can depend on ServiceRegistry without needing to know about the underlying ConfigProvider implementation details.

In summary, ServiceRegistry implements the Repository pattern on top of ConfigProvider, providing a more specialized, service-oriented interface that simplifies service configuration access for test classes and other components in the framework.

ConfigProvider:

Singleton pattern implementation that loads configuration from a YAML file
Provides access to various configuration settings like test classes, base URIs, packages, etc.
Manages environment-specific parameters (DEV, INT)
Primarily focused on raw configuration data access

ServiceRegistry:

Also uses a Singleton pattern
Uses ConfigProvider internally
Creates a mapping of service configurations
Provides methods to look up service configurations by name or by class
Includes a ServiceConfig inner class that encapsulates service-specific information

Here’s a summary highlighting why this BaseTest.java is a top-notch approach for REST Assured testing:

Why This `BaseTest.java` is a Top-Notch Approach for REST Assured Testing

1. Code Reusability & Maintainability

✅ Less Redundant Code – Common API actions (e.g., statusCode validation, headers, request initialization) are centralized in BaseTest.java, reducing repetition in test classes.
✅ Easier Maintenance – Adding a new mandatory response field only requires updating verifyResponseContainsField() in one place.

2. Clean Test Design with Separation of Concerns

✅ Keeps Tests Focused on Business Logic – The test classes (SearchTest.java, etc.) only contain the specific test logic, while BaseTest.java abstracts generic API interactions.
✅ Encapsulated API Client – BaseTest.java uses an ApiClient that manages API requests, headers, and authentication. This ensures consistency and avoids hardcoded API details in test cases.

3. Robust Response Validation

✅ Centralized HTTP Status Checks – verifySuccessResponse() and verifyErrorResponse() ensure uniform response validation across all tests.
✅ Flexible Field-Level Verification – verifyResponseContainsField(String field) allows easy validation of response content without repeating assertions in every test.
✅ (Optional) JSON Schema Validation – validateResponseSchema(String schemaFile) enforces standardized response structures, ensuring backward compatibility and API contract integrity.

4. Structured Request Handling

✅ Built-in Support for Headers & Parameters – Methods like addHeader(), addQueryParam(), and addPathParam() provide a clean way to modify API requests dynamically.
✅ Ensures a Clean State Before Each Test – initializeRequestSpecification() resets the API client’s request configuration before every test, preventing unintended state carryover.

5. Advanced Error Handling & Logging

✅ Structured Test Failure Handling – handleTestFailure(String testName, AssertionError e) ensures errors are logged consistently before being rethrown, aiding debugging.
✅ SLF4J Logging Integration – Provides clear logs for API requests, responses, and failures, improving test traceability.

Why This Approach is Ideal for REST Assured Testing

🚀 Scalable – Easy to extend when adding more API endpoints.
🔍 Reliable – Prevents test failures due to inconsistent API calls or missing validations.
🛠️ Maintainable – Centralized logic reduces effort when updating API-related code.

rest

   +---------------------------+
   |     BaseTest              |  (Superclass)
   +---------------------------+
   | - requestSpec             |
   | - response                |
   | + get()                   |
   | + post()                  |
   | + addHeader()             |
   | + verifySuccessResponse() |
   | + handleTestFailure()     |
   +---------------------------+
            ▲
            │
            │ (inherits)
            │
   +---------------------------+
   |    SearchTest             |  (Subclass)
   +---------------------------+
   | + testAdvancedSearch()    |
   | + testQuickSearch()       |
   +---------------------------+

Simpl 10952 test architecture + code formatter