Testing the Swagger Petstore: Manually Testing An API Using Swagger UI

With the last post, Testing the Swagger Petstore: Reviewing API Documentation Formatted in OpenAPI 3.0 with Swagger UI we started exploring an API with Swagger UI, such as the Swagger Petstore at https://petstore3.swagger.io/

Here, we will start exploring how to test an API using the Swagger UI.

The tests we can run are:

• Happy Path Testing, checking the Positive Scenarios
• Negative Testing, reviewing the Invalid Inputs & Error Handling
• Boundary & Edge Case Testing, checking how the API handles the extreme limits of allowed input ranges
• Authentication & Authorization Testing
• Contract and schema validation

We can see in the Swagger PetStore there are three tag groups: Pet, Store, and User. 

Because this is a Swagger UI doc, we can perform manual testing using only the "Try it out" feature in Swagger UI. No external tools needed! Live HTTP requests can be executed directly from your browser.

Types of Testing for the API

Here are a few types of testing and examples you can do in Swagger UI

Happy path Functional Testing

Pet

• POST /pet: add a new pet with a complete, valid payload. Verify 200 and that the response echoes the submitted fields.
• PUT /pet: update the pet you just created. Verify the change persists on a follow-up GET.
• GET /pet/{petId}: retrieve the pet by the ID returned from the POST.
• GET /pet/findByStatus: query with each valid status value (available, pending, sold) individually.
• GET /pet/findByTags: query with a tag that exists on a pet you created.
• POST /pet/{petId} (form data): update name/status via form fields instead of JSON body.
• POST /pet/{petId}/uploadImage: upload a valid image file, verify response message and metadata.
• DELETE /pet/{petId}: delete a pet you created, then confirm GET on that ID now fails.

Store

• POST /store/order: place an order with valid petId, quantity, shipDate, status.
• GET /store/order/{orderId}: retrieve the order just placed.
• GET /store/inventory: verify it returns a status-to-count map without needing auth.
• DELETE /store/order/{orderId}: delete the order, confirm subsequent GET fails.

User

• POST /user: create a user with all fields populated.
• POST /user/createWithList: create multiple users in one call.
• GET /user/{username}: retrieve the user just created.
• PUT /user/{username}: update user details.
• GET /user/login and GET /user/logout: exercise the session flow, check the response headers for any session/rate-limit info.
• DELETE /user/{username}: delete the user, confirm GET now fails.

Negative testing

• Omit required fields (e.g. POST /pet with no name, POST /store/order with no petId) and confirm the API rejects or documents the discrepancy if it doesn't.
• Send wrong data types: string where an integer is expected (petId, orderId, quantity), or a malformed date in shipDate.
• Send an invalid enum value for status (pet or order) that isn't in the documented list, e.g. status=deleted.
• Request a non-existent ID: GET/PUT/DELETE on /pet/{petId}, /store/order/{orderId}, /user/{username} with an ID or username that was never created.
• Use a negative or zero orderId/petId, since the spec marks these as int64 without an explicit floor documented in the UI.
• Send an empty request body where one is required.
• Submit extra, undocumented fields in the payload and see if they're silently accepted, rejected, or reflected back.
• Try invalid characters/encoding in path parameters (e.g. username with special characters or spaces).
• Upload a non-image file to /pet/{petId}/uploadImage or exceed a large file size.

Boundary and edge cases

• Very long strings in name, username, tags fields.
• Empty string values in string fields that are technically optional vs required.
• Minimum/maximum int64 values for petId/orderId.
• Unicode and emoji in name/tag/comment fields.
• Duplicate creation: POST the same username or petId twice, check whether the API allows duplicates or returns a conflict.
• Repeat DELETE on the same resource (idempotency check), confirm the second call fails gracefully rather than erroring unexpectedly.
• Repeat identical PUT calls and confirm the result is stable (no unintended side effects on repeated identical updates).

Contract and schema validation

• For every response, expand the "Model" / "Schema" tab in Swagger UI and confirm the actual response body matches the documented schema, including field names, types, and nesting (e.g. category and tags as nested objects/arrays on Pet).
• Check that all documented HTTP status codes for an endpoint are reachable in practice (200, 400, 404, 405) not just the happy-path 200.
• Confirm response Content-Type header matches what's declared (application/json vs application/xml, since Petstore documents both for some endpoints).
• Verify example values shown in the UI docs actually produce the documented example response when submitted as-is.

Authentication Testing

• Where api_key is documented (e.g. DELETE /pet/{petId}), test the call with the key present, with an invalid key, and with it omitted entirely, and compare behavior.
• Exercise GET /user/login with valid and invalid credentials and observe whether/how it differentiates in status code or message.

UI-specific / exploratory checks

• Use the auto-generated curl command (Swagger UI shows this after "Execute") to confirm the request it built matches what you intended, useful for catching parameter-encoding issues.
• Check response time shown in the UI for anomalies on larger payloads (e.g. uploadImage).
• Toggle between the documented request body examples and hand-edit them to confirm the "Try it out" editor validates JSON syntax before allowing submission.
• Cross-check the UI's rendered documentation (descriptions, required markers) against actual server behavior to catch doc drift, a common defect class in Swagger-driven APIs.
• Since this is a shared public demo instance, run a read-only check (GET /store/inventory, GET /pet/findByStatus) before and after your write tests to see if state persists or resets, which matters for repeatable test design.

Parameter & Header Testing

• Targets how the API handles different ways data can be sent.
• Query Parameters: Test GET endpoints that filter data (like /pet/findByStatus) by selecting different dropdown values or entering multiple statuses to verify the filtering logic.
• Path Parameters: Verify how the API reacts to special characters or spaces injected directly into the URL path.

Now that we have some possible testing examples, in our next post, we can start investigating the Swagger Petstore. 

Happy Testing!

-T.J. Maher
Software Engineer in Test

BlueSky | YouTube | LinkedIn | Articles