Aller au contenu principal

Post and Put

What are we going to test and how?

Scope​

Test cases for the User Management API.

API version: 1.0.0

Endpoints covered​

MethodEndpointDescription
POST/usersCreate a user
PUT/users/{id}Update a user
Test data details
users:
  valid:
    id: "123"
    name: "Username"
    email: "username@example.com"

  invalid:
    email: "username@"
    empty_name: ""

  non_existing:
    id: "999999"

POST /users — Create a user​

TC-USER-001 — Create a user with valid data​

Objective

Verify that a user can be created with valid required data.

Request

POST /users
Content-Type: application/json

{
  "name": "Username",
  "email": "username@example.com"
}

Expected result

  • HTTP status code is 201.

  • Response body contains the created user.

  • Response contains:

    • id
    • name
    • email

  • Returned name matches the request.

  • Returned email matches the request.

Technique

Positive testing

TC-USER-002 — Create a user without name​

Objective

Verify that name is required.

Request

POST /users
Content-Type: application/json

{
  "email": "username@example.com"
}

Expected result

  • User is not created.
  • API returns an appropriate client-error status code, such as 400.
  • Response explains that name is required.

Technique

Equivalence Partitioning

TC-USER-003 — Create a user without email​

Objective

Verify that email is required.

Request

POST /users
Content-Type: application/json

{
  "name": "Username"
}

Expected result

  • User is not created.
  • API returns an appropriate client-error status code, such as 400.
  • Response explains that email is required.

Technique

Equivalence Partitioning

TC-USER-004 — Create a user with an invalid email​

Objective

Verify that the API validates the email format.

Request

POST /users
Content-Type: application/json

{
  "name": "Username",
  "email": "username@"
}

Expected result

  • User is not created.
  • API returns an appropriate client-error status code, such as 400.
  • Response indicates that the email format is invalid.

Technique

Equivalence Partitioning

TC-USER-005 — Create a user with an empty name​

Objective

Verify the behavior when name is provided as an empty string.

Request

POST /users
Content-Type: application/json

{
  "name": "",
  "email": "username@example.com"
}

Expected result

  • The API rejects the request if empty names are not allowed.
  • No user is created.
  • API returns an appropriate client-error status code.

Note

The OpenAPI specification declares name as required but does not define minLength. Therefore, whether an empty string is accepted is a business/API validation rule that should be clarified.

Technique

Boundary Value Analysis

PUT /users/{id} — Update a user​

TC-USER-006 — Update a user name​

Objective

Verify that an existing user's name can be updated.

Preconditions

  • User 123 exists.

Request

PUT /users/123
Content-Type: application/json

{
  "name": "Updated Username"
}

Expected result

  • HTTP status code is 200.
  • Response contains the updated user.
  • User ID remains 123.
  • Name is updated to Updated Username.

Technique

Positive testing

TC-USER-007 — Update a user email​

Objective

Verify that an existing user's email can be updated.

Preconditions

  • User 123 exists.

Request

PUT /users/123
Content-Type: application/json

{
  "email": "updated@example.com"
}

Expected result

  • HTTP status code is 200.
  • Response contains the updated user.
  • Email is updated to updated@example.com.

Technique

Positive testing

TC-USER-008 — Update a user with invalid email​

Objective

Verify that an invalid email cannot be used to update a user.

Preconditions

  • User 123 exists.

Request

PUT /users/123
Content-Type: application/json

{
  "email": "updated@"
}

Expected result

  • User is not updated.
  • API returns an appropriate client-error status code, such as 400.
  • Response indicates that the email format is invalid.

Technique

Equivalence Partitioning

TC-USER-009 — Update a non-existing user​

Objective

Verify that the API returns 404 when updating a user that does not exist.

Request

PUT /users/999999
Content-Type: application/json

{
  "name": "Updated Username"
}

Expected result

  • HTTP status code is 404.
  • Response indicates that the user was not found.

Technique

Equivalence Partitioning

TC-USER-010 — Update a user with an empty request body​

Objective

Verify the behavior when no fields are provided for the update.

Preconditions

  • User 123 exists.

Request

PUT /users/123
Content-Type: application/json

{}

Expected result

  • API behavior should be defined.
  • If at least one field is required for an update, the API should reject the request.
  • If an empty update is allowed, the API should return 200 without modifying the user.

Note

UserUpdate contains only optional properties. The OpenAPI specification therefore does not explicitly prohibit an empty object.

Technique

Error guessing