In this series of posts, I will be going over how to test the API that I created in the previous post. I won’t go over how to use the tools too much since each tool has its own documentation. I will focus on testing the API.
Postman
I will start with using Postman for testing APIs. Postman is a popular tool for API development and testing, offering features like request sending, test automation, and collaboration. Sending requests and receiving responses via Postman is quite intuitive. It’s like any other tool in that regard. Using Postman for test automation can work, but there are some limitations with validating data programmatically against a data source. I will go over some solutions that I know of to overcome this in a future post.
Functional Testing an API with Postman
In Postman, the user can write code for “Tests” that are executed after a response has been returned from the API. These ‘Tests’ serve to validate the API response and are Assertions, Response Validations, Checkpoints, or Verification Steps. I just don’t want to confuse these “Tests” with what I consider a test or a test case.
In the image, you can see the tree/folder structure of my tests. I like to organize my tests by endpoint. For the Budget API, there are five endpoints, so I have five folders. Each folder has a set of API calls. Usually, each API request is a test. This is what I consider a “test”.
Image 1 shows the tests for the Budget endpoints. For testing the whole Budget API, a folder and tests for Category, BudgetItem, and Transaction would need to be added. Other areas of testing would include security and performance, which I would group in their own folders. Again, depending on the requirements, other areas of testing are highly likely.
Single Request Tests
In the Get All Budgets directory, I have two tests: A valid and an invalid test. (The requirements will determine the number of tests, but my requirements are simple.) The Valid request’s endpoint is “https://localhost:1234/api/Budget/”. Appending a ‘1’ at the end of the endpoint URL renders the request invalid.
The Get Budget by Id tests are the same way. One request for each of those four tests. Get operations are like that most of the time.
Image 1
Multiple Requests Test
For the Update Budget tests, I really only have one test. All four requests work together to test the Update endpoint: You create a budget, get the budget to get the new budget id for the Update to use, Update the budget, and then get the budget again to verify the data was updated. I set it up this way because I will demonstrate Postman’s automation in a future post.
You can execute these four requests either individually or in sequence using Postman’s ‘Run Folder’ option. However, when using variables, which you will need to use to pass data between tests, the tests won’t complete without errors because the variable (like the newly created budget id) won’t be populated unless a previous request that sets that variable is run. I’ll discuss how to overcome this later.
Multiple requests for a single test is the same style for Create Budget, Update Budget, and Delete Budget. This is usually how creates, updates, and deletes will be tested when testing an API. This assumes some type of automation is being set up.
Sending Requests
As I mentioned above, I am not going to completely go over how Postman works. You can read Postman’s documentation for that. However, I will touch on a few things that you will likely have to do before sending a request to an endpoint.
First, if your API is expecting JSON, you will have to change the Content-Type header to “application/json” in the Header tab.
Second, your requests might require data in the Body. For the Create Budget requests above, I have the following JSON in the request body:
{
"userId": 75,
"name": "January",
"month": 1,
"year": 2024
}Third, the API you’re testing may require you to configure additional settings in other tabs.
Fourth, click the Send button or Run Folder option.
Validating the Response
Once the request is sent and a response is received, Postman displays the response. You can see the response from my Get All Budgets — Valid test below. It returns a list of the budgets in the database, excluding the categories.
Validating this method is straightforward; the only requirement is that it returns all budgets, limited to five specific fields. Validate this response against the data source to verify the happy path test works.
Conclusion
As we’ve seen, API testing with Postman is not only effective but also quite straightforward. I will discuss more on using Postman to automate some of these responses in the future.