Jack
Jack

Reputation: 1

How to test the app using Postman properly?

I have a Java app based on Spring Boot and just started to use Postman and instead of testing a specific endpoint, now I want to check a changes that affect different aspect of assume that I added some endpoints for Employee endpoints for:

//GET
http://localhost:8080/api/v1/employee/getEmployees


//POST
http://localhost:8080/api/v1/employee/createEmployee


// PUT:
http://localhost:8080/api/v1/employee/updateEmployee/id


// DELETE:
http://localhost:8080/api/v1/employee/deleteEmployee/id

In this scene I added all the related methods for these endpoints to:

EmployeeController

EmployeeService

EmployeeRepository

There may also be some additional methods used by these CRUD methods in the Controller, Service and Repository as well.

Note: I already defined unit and integration tests, but just need to get info for Postman aspect with test data in the database.

In this scene:

1. Is sending the requests to the endpoints (Controller) enough for testing all of these EmployeeController, EmployeeService and EmployeeRepository? Or how should I test all of these methods that I added for Employee CRUD operations?

2. I think there is not another alternative to check the Service and Repository methods except from sending the requests via Controller? Is that true?

Upvotes: 1

Views: 1353

Answers (1)

Code-Apprentice
Code-Apprentice

Reputation: 83527

When testing, no matter what tools you use, the first step is to clearly specify exactly what each test is actually testing. For example, "when the user POSTs to endpoint /api/v1/employee/getEmployees, then the response should be...". Fill in the blanks and describe as many tests you need for each of your endpoints.

Note how my example description only uses the path and says nothing about controllers, services, or repositories. From the point of view of a HTTP client such as Postman, only the path is important. The implementation details such as controllers, services, and repositories are completely invisible to Postman.

Side note: I suggest creating a single route /api/v1/employee/ that allows both GET and POST requests. There is no need to name the route /api/v1/employee/getEmployees since that is what the GET verb means. Likewise, POST already means to create an employee, so there's no need to add createEmployee in the path. Similarly a path /api/v1/employee/id/ can allow GET and PUT without needing the extra words in the path describing the action.

Upvotes: 1

Related Questions