Skip to main content

API Agent

Create an agent configured to function as a Technical Specialist in API Testing. This agent should be capable of automatically generating test classes and BDD (Behavior-Driven Development) test scenarios while offering continuous support for API test automation. Be sure to include Knowledge Sources with API data from your project to ensure the agent can provide contextualized and accurate responses.

Steps to create an Agent

Step 1. Access the StackSpot AI Portal

Step 2. Create a new Agent

  • In the main menu, click on ‘Contents > Agents’;
  • Click the ‘Create Agent’ button;
  • Fill in the Agent information:
    • Agent name: Technical Specialist in API Testing
    • System Prompt: Paste the following prompt:
API Automation with Rest Assured
You are a Backend QA Automation Specialist with expertise in API test automation using the Rest Assured framework.
When requested, you must analyze the provided API documentation, including all endpoints and payloads.
Generate test classes in Java 21, using Rest Assured, JUnit 5, and Hamcrest.
Assume the project uses the `org.aeonbits.owner` library for reading properties files.
Consider that the test class will always extend an abstract base class where the API URL will be instantiated in a `@BeforeAll` method.
All endpoints must be tested, along with all possible status codes.
Ensure that all fields returned in the response of the request are validated.
Use the `@DisplayName` annotation for naming the tests.
The test names in `@DisplayName` should follow the Gherkin syntax of the BDD methodology in PT-BR.
Methods should have a simplified and concise camelCase naming convention, always starting with "deve" (should).

Test Scenario Writing
As a QA Automation Specialist, you are responsible for generating test scenarios using the Gherkin syntax in the BDD methodology.
When requested, you must analyze the provided user story, acceptance criteria, functional and non-functional requirements.
Use techniques such as boundary value analysis, equivalence partitioning, and decision tables to ensure that all happy path and alternative scenarios are covered.
The tests must be generated using the Given, When, and Then structure in PT-BR.
Analyze the provided documentation, as well as the API, endpoints, payloads, and all relevant information.

  • Suggested Commands: Add the following suggested commands to help the user start conversations with the Agent:

    Create a test plan for the APIs.
    Generate test classes for the API endpoints.
    Write BDD test scenarios for the API.
    Validate the status codes and response fields of the API.

  • Conversational Mode: Enable conversational mode to allow continuous and complex interactions, which is ideal for conversations involving multiple information exchanges.

  • Knowledge Sources (KSs): Add relevant Knowledge Sources to the Agent, such as API documentation, endpoints, and project payloads. This will enable the Agent to provide more accurate and contextualized responses.

Step 3. Test the Agent

  • After configuring the agent, go to the ‘Try’ section to test the Agent and ensure it works as expected.
  • Ask questions like: "Create a test plan for the APIs."

Use an example of a bank statement API in OpenAPI 3.0 format. This API allows querying the balance, listing transactions, and retrieving details of a specific transaction:

openapi: 3.0.0
info:
  title: Bank Statement API
  description: API for querying account balance and banking transactions.
  version: 1.0.0
paths:
  /balance:
    get:
      summary: Balance Inquiry
      description: Returns the current balance of the bank account.
      responses:
        '200':
          description: Balance successfully returned
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Balance'
        '401':
          description: Unauthorized
  /transactions:
    get:
      summary: List Transactions
      description: Returns a list of transactions performed on the account.
      parameters:
        - in: query
          name: startDate
          schema:
            type: string
            format: date
          description: Start date to filter transactions.
        - in: query
          name: endDate
          schema:
            type: string
            format: date
          description: End date to filter transactions.
      responses:
        '200':
          description: List of transactions successfully returned
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Transaction'
        '401':
          description: Unauthorized
  /transactions/{id}:
    get:
      summary: Transaction Details
      description: Returns the details of a specific transaction.
      parameters:
        - in: path
          name: id
          required: true
          schema:
            type: string
          description: Transaction ID.
      responses:
        '200':
          description: Transaction details successfully returned
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Transaction'
        '404':
          description: Transaction not found
        '401':
          description: Unauthorized
components:
  schemas:
    Balance:
      type: object
      properties:
        currentBalance:
          type: number
          example: 1500.75
    Transaction:
      type: object
      properties:
        id:
          type: string
          example: "12345"
        date:
          type: string
          format: date-time
          example: "2023-10-01T10:00:00Z"
        description:
          type: string
          example: "Grocery store purchase"
        amount:
          type: number
          example: -200.50
        type:
          type: string
          enum: [credit, debit]
          example: "debit"

Step 4. Share the Agent

  • If you want to share the Agent with other team members, click the ‘Share’ button.
  • Choose between:
    • Share with specific users: Add the users' email addresses.
    • Publish to the account: Make the agent available to all account members.

Step 5. Use the Agent

  • The Agent will be available in the StackSpot AI IDE or chat, where you can use it directly to generate tests and API scenarios.
  • The Agent can be used with Quick Commands to automate the testing process further.

Usage example

1. Generate test classes for API

You can ask the Agent to generate test classes for a specific API. For example:

User: "Generate a test class for the endpoint /api/v1/users." Agent:

import io.restassured.RestAssured;
import org.junit.jupiter.api.BeforeAll;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;

public class UserApiTest extends BaseApiTest {

    @BeforeAll
    public static void setup() {
        RestAssured.baseURI = "https://api.example.com";
    }

    @Test
    @DisplayName("Given the user endpoint is accessed, When the request is made, Then the status code should be 200")
    public void shouldReturnStatusCode200() {
        given()
            .when()
            .get("/api/v1/users")
            .then()
            .statusCode(200);
    }

    @Test
    @DisplayName("Given the user endpoint is accessed, When the request is made, Then the 'name' field should be returned correctly")
    public void shouldValidateNameField() {
        given()
            .when()
            .get("/api/v1/users")
            .then()
            .body("nome", equalTo("João"));
    }
}

2. Generate Test Scenarios in BDD
You can also ask the agent to generate test scenarios in BDD. For example:
**User:** "Write BDD test scenarios for the endpoint /api/v1/users."
**Agent:**

Feature: Test the user endpoint

Scenario: Given the user endpoint is accessed, When the request is made, Then the status code should be 200
  Given the user endpoint is accessed
  When the request is made
  Then the status code should be 200

Scenario: Given the user endpoint is accessed, When the request is made, Then the 'name' field should be returned correctly
  Given the user endpoint is accessed
  When the request is made
  Then the 'name' field should be returned correctly