restassured-test-generation

Purpose

Generate production-ready Rest Assured automation that integrates seamlessly into the existing automation framework.

The generated code must:

• Follow repository conventions.
• Reuse existing implementations whenever possible.
• Be maintainable and reusable.
• Be statically correct.
• Require minimal or no manual modification before execution.

This skill focuses on API test implementation and does not define repository analysis, Java coding standards, or code quality validation, which are covered by their respective skills.

---

Objective

Generate only the API automation required for the supplied test scenarios.

Reuse existing implementations wherever possible.

Extend the existing automation framework.

Do not create a new framework.

---

Repository Analysis

Before generating any API automation, inspect the repository.

Identify:

• Existing Rest Assured test classes
• Existing API clients
• Existing Request Specifications
• Existing Response Specifications
• Existing authentication utilities
• Existing serialization/deserialization models
• Existing DTOs
• Existing payload builders
• Existing helper methods
• Existing API utilities
• Existing constants
• Existing environment configuration
• Existing configuration management
• Existing reporting framework
• Existing folder structure
• Existing naming conventions

Repository implementations are the authoritative source.

---

Reuse Strategy

Before creating any new implementation, search for reusable components.

Reuse existing:

• API clients
• Request Specifications
• Response Specifications
• Authentication helpers
• Payload builders
• DTOs
• Utility methods
• Assertions
• Environment configuration
• Test data
• Base classes

Do not duplicate existing functionality.

Extend existing components whenever practical.

---

Test Generation

Generate only the required automation.

Possible outputs include:

• API test classes
• Helper classes
• Request builders
• Payload builders
• DTOs
• Utility methods
• Test data
• Configuration updates (only when required)

Never overwrite unrelated code.

---

API Request Construction

Construct requests using reusable components.

Prefer:

• RequestSpecification
• Base URI configuration
• Base Path configuration
• Common headers
• Shared authentication
• Path parameters
• Query parameters
• Request payload builders

Avoid:

• Hardcoded URLs
• Hardcoded headers
• Hardcoded authentication
• Duplicate request construction

---

Response Validation

Validate every API response appropriately.

Where applicable verify:

• HTTP status code
• Response headers
• Content-Type
• Response body
• Mandatory fields
• Optional fields
• Data types
• Field values
• Business rules
• Error payloads

Prefer reusable validation methods.

Avoid duplicated assertions.

---

API Workflow Support

Support complete API workflows where applicable.

Examples include:

• Create
• Read
• Update
• Delete
• Search
• Authentication
• Logout
• Session lifecycle

Reuse identifiers generated by previous requests when validating end-to-end workflows.

---

Authentication

Reuse the repository's existing authentication mechanism.

Examples include:

• OAuth2
• Bearer Token
• Basic Authentication
• API Keys
• JWT
• Session Cookies

Never introduce duplicate authentication implementations.

Never hardcode credentials.

Always use existing environment configuration.

---

Payload Management

Reuse existing payload models whenever available.

Prefer:

• DTO classes
• Builder pattern
• Object serialization
• External JSON payloads

Avoid:

• Inline JSON strings
• Duplicate payload models
• Repeated request bodies

---

Assertions

Generate meaningful assertions.

Validate:

• Functional behavior
• Business rules
• Response schema (when available)
• Returned data
• Side effects
• State transitions

Avoid weak assertions such as verifying only HTTP status codes unless explicitly required.

---

Error Handling

Generate tests for:

• Invalid requests
• Missing required fields
• Invalid field values
• Unsupported methods
• Unauthorized requests (when part of functional requirements)
• Forbidden operations
• Resource not found
• Conflict scenarios
• Validation failures

Reuse common validation utilities whenever available.

---

Test Data

Reuse existing test data.

Prefer:

• Existing builders
• Existing fixtures
• Existing JSON files
• Existing environment variables

Do not duplicate test data.

---

Folder Structure

Always follow the repository's existing folder structure.

Generate files only in locations consistent with the existing project.

Validate:

• Package names
• Folder hierarchy
• Imports
• Build configuration

Do not introduce new folder structures unless required.

---

Framework Integration

Ensure generated automation integrates with:

• Existing Request Specifications
• Existing Response Specifications
• Existing API clients
• Existing authentication
• Existing utilities
• Existing reporting
• Existing logging
• Existing retry mechanisms
• Existing test framework (JUnit/TestNG/Cucumber)

Do not duplicate integrations.

---

Duplicate Prevention

Never duplicate:

• Request Specifications
• Response Specifications
• Authentication helpers
• API clients
• DTOs
• Payload builders
• Utility methods
• Assertions
• Constants

Extend existing implementations instead.

---

Validation

Before completion verify:

• Imports resolve correctly.
• Package names are correct.
• No duplicate implementations exist.
• Request construction reuses existing components.
• Response validation is complete.
• Authentication is reused.
• Generated code follows repository conventions.
• Every test maps to its originating Test Case ID.
• Static validation passes.

If runtime risks are detected (such as unavailable endpoints, authentication dependencies, missing test data, unavailable schemas, or undefined environment variables), report them separately.

---

Constraints

• Do not create a new framework.
• Do not duplicate existing implementations.
• Do not overwrite unrelated code.
• Reuse existing Request Specifications.
• Reuse existing authentication.
• Reuse existing payload builders.
• Follow repository conventions.
• Generate only the required automation.
• Perform static validation only.

---

Expected Outcome

The generated Rest Assured automation should:

• Integrate seamlessly into the existing repository.
• Follow repository conventions.
• Reuse existing framework components.
• Contain no duplicate implementations.
• Produce maintainable and reusable API tests.
• Require no manual restructuring before execution.
• Be production-ready and statically valid.