Don’t Just Send Requests — Assert Like a Tester in Postman!
- kalyanikajjam
- Oct 10
- 5 min read
Postman isn’t just a request sender, it’s a full-fledged testing tool that helps you automate, validate, and verify your APIs using assertions.
In this blog, we’ll explore what assertions are, why they matter, and how to use them effectively in Postman to make your API testing smarter and faster.
Assertions help ensure that your API is not just working — it’s working correctly.
What are assertions in Postman?
Assertions are used to verify if the actual and expected values have matched after the execution of a test.
They determine whether a test passes or fails based on whether the actual response matches the predefined expectations.
Let's look into real time examples of Assertions
a. Imagine you order a burger with fries. When the waiter brings food, you check:
• Did I get a burger? (pm.expect(response.item).to.eql("burger"))
• Are the fries included? (pm.expect(response.sides).to.include("fries"))
• Did it come hot, under 10 minutes? (pm.expect(response.time).to.be.below(600))
b. You buy a phone on Amazon. Assertions could be:
• Status code: "Your order was placed successfully" (200 OK).
• Response body: Your order ID is generated (pm.expect(orderId).to.exist).
• Delivery estimate: Must be within 5 days (pm.expect(deliveryDate).to.be.below(expectedDate)).
• Package contents: Should include phone + charger (pm.expect(items).to.include.members(["phone","charger"]))
In Postman, we can take the help of JavaScript Chai Assertion Library to add assertions in our tests. It is available in the Postman application automatically.
The Assertions in Postman are written within the Scripts tab under the address bar.
How to write Assertions in Postman?
Writing assertions in Postman, there are two main steps involved:
1. Write test code:
Writing test code in JavaScript method or functional method. The default library for application is Chai Assertion Library.
Chai Assertion Library
Chai assertion Library is included by Postman by default in its application, Chai is an assertion library for JavaScript that provides a framework for writing tests to verify the correctness of code.
Ex: expect().to.be., expect().to.have., expect().to.eql()
•Chai’s Assertion Styles
a. Assert Style
The assert style is a TDD style. It is traditional and straightforward approach inspired by Node.js’ built-in assert module. Assertions are written as function calls.
b. Expect Style
The expect style provides a readable, natural-language-like syntax. It uses chainable methods to express assertions more clearly.
c. Should Style
The should style extends object prototypes, allowing assertions to be written directly on objects in a fluent, descriptive manner.
2. Parse the response body:
It is important to know what kind of response you are getting to perform a test on it. The most popular response is JSON, simply because it is very easy to read by humans and is machine readable also. There are many other formats of an HTTP response:
•XML
•HTML
•Text
Types of Assertions:
Common types of assertions include:
•Status Code Assertions : Checking if the HTTP status code (e.g., 200 OK, 404 Not Found) matches the expected value.
•Response Body Content Assertions : Verifying if the response body contains specific data, a particular string, or adheres to a defined JSON schema.
•Header Assertions : Asserting the presence or value of specific headers in the response.
•Response Time Assertions : Checking if the API response time falls within an acceptable limit.
•Request Body Assertions: To ensure the data sent in the request adheres to expected formats and values.
Status Code Assertions :
Status Code Assertions are fundamental validations that ensure the server responds with the expected HTTP status code. They help identify if the request was successful or encountered an error. Use pm.response.to.have.status(): or pm.expect(pm.response.code).to.eql() to assert the expected status code.
Categories of HTTP Status Codes:
a.1xx Informational:
The request was received and the process is continuing.
100 Continue: The client should continue with its request.
101 Switching Protocols: The server is switching protocols as requested by the client.
b.2xx Success:
The action was successfully received, understood, and accepted.
200 OK: The request was successful.
201 Created: The request was successful and a new resource was created.
204 No Content: The request was successful, but there is no content to return.
c.3xx Redirection:
Further action needs to be taken to complete the request.
301 Moved Permanently: The requested resource has been permanently moved to a new URL.
302 Found: The requested resource is temporarily located at a different URL.
d.4xx Client Error:
The request contains bad syntax or cannot be fulfilled due to a client-side issue.
400 Bad Request: The server cannot process the request due to a client error (e.g., malformed syntax).
401 Unauthorized: The request requires user authentication.
403 Forbidden: The server understood the request but refuses to authorize it.
404 Not Found: The requested resource could not be found on the server.
429 Too Many Requests: The client has sent too many requests in a given time frame (rate limiting).
e.5xx Server Error:
The server failed to fulfill an apparently valid request due to a server-side issue.
500 Internal Server Error: A generic error message indicating an unexpected condition on the server.
503 Service Unavailable: The server is currently unable to handle the request due to temporary overload or maintenance.
Response Body Assertions:
These assertions validate the content of the response body. You can check for specific values, patterns, or elements within the response.
Here are common methods for response body content validation:
1.Checking for specific values or properties:
2. Checking for the presence of a string:
3.Validating against a JSON Schema
4. Checking data types
Header Assertions:
Header Assertions validate the presence and values of headers in the API response.
Response time assertions :
Response time assertions are used to verify that an API's response time falls within an acceptable threshold.
pm.expect(pm.response.responseTime): This accesses the response time of the current request and sets up an expectation for it.
.to.be.below(200): This is the assertion itself, checking if the pm.response.responseTime value is strictly less than 200 milliseconds.
Pm.test(): This is used to write test cases. If an assertion inside fails that test shows fails, others still run.
Request Body Assertions
Request body validation usually means:
• Making sure you send the correct request body (before hitting the API).
• Validating the request body in the response (after the API processes it).
1.Validating Request Body Before Sending (Pre-request Scripts)
In Postman, You can add a Pre-request Script to check whether the body you’re sending is valid before it reaches the server. You can dynamically set environment, collection, or local variables using pm.environment.set(), pm.collectionVariables.set(), or pm.variables.set(). This is useful for things like authentication tokens, dynamic dates, or calculated values.
2. Validating Request Body in the Response(Test Scripts)
You can validate that the server processed your requests and a response has been received according to your API's expectations.
Frequently Used Assertion Methods in Postman:
Conclusion
Assertions help you:
•Verify test results
•Improve test clarity
•Identify failures
•Improve Debugging
By using assertions, you move from manual validation to automated, repeatable API testing — the key to faster development and reliable integrations. So next time you hit “Send” in Postman, don’t just look at the response — assert that it’s right.
Because real testers don’t just expect success — they verify it.
