Mastering Postman: API Testing and Automation

This comprehensive guide introduces Postman as a vital tool for API testing, explaining its utility in interacting with web-based APIs and automating test processes. It details fundamental API concepts, including HTTP methods (GET, POST, PATCH, DELETE), request/response structures, and status codes. The resource demonstrates practical Postman features such as collections, variables (global, collection, environment), and scripting for automated tests using JavaScript, emphasizing assertions and dynamic data handling. Finally, it explores Postman’s Collection Runner for sequential test execution and Newman for command-line automation and report generation, showcasing how these tools integrate into continuous integration pipelines for robust API validation.

Postman API Testing: Concepts, Automation, and Limitations

API testing involves interacting with APIs to ensure they work as expected. Instead of verifying the API manually, the goal is to automate this process by writing API tests, allowing Postman to perform the checks and only requiring human intervention if something goes wrong. The source specifically focuses on using Postman for web-based API testing, where APIs work over the internet, exchanging data rather than electricity through a server interface.

Key Concepts in API Testing with Postman:

  • APIs as Interfaces/Contracts: An API is an interface to a server that provides data or performs actions. To use an API, you need to know and follow its specifications, much like a power outlet requires a specific plug.
  • Postman as a Tool: Postman simplifies connecting to APIs and making the process of sending and receiving data easier. It allows users to configure various aspects of an HTTP request and view the corresponding response.
  • HTTP Messages: Communication between a client (e.g., Postman) and a server (the API) uses HTTP messages.
  • Request: The message sent from Postman to the API. It contains:
  • URL/Address: The location where the request is sent, consisting of a base URL and specific endpoints.
  • Request Method (HTTP Verbs): Indicates the intended action. Common methods include:
  • GET: Used to retrieve data.
  • POST: Used to send data to create a new resource, like ordering a book or registering an API client.
  • PATCH: Used to update existing data, such as changing a customer name for an order.
  • DELETE: Used to remove a resource, like deleting an order.
  • Headers: Provide meta-information about the message, such as Content-Type (e.g., application/json) or User-Agent. They are often used for authentication.
  • Body: Contains the data being sent with the request, typically used with POST and PATCH methods, often in JSON format.
  • Response: The message coming back from the API. It contains:
  • Status Code: A numerical code indicating the outcome of the request.
  • 2xx (Success):200 OK: Request was understood, and everything was fine.
  • 201 Created: A resource was successfully created.
  • 204 No Content: The request was successful, but there is no content to return in the response body.
  • 4xx (Client Error): Indicates an issue with the request sent by the client.
  • 400 Bad Request: The API understood the request, but what was sent was incorrect or invalid (e.g., invalid query parameter value, missing body property).
  • 401 Unauthorized: Missing authorization header, indicating that authentication is required.
  • 404 Not Found: The requested resource (e.g., book ID, order ID, or endpoint) does not exist.
  • 409 Conflict: The request could not be processed because of a conflict (e.g., API client already registered).
  • 5xx (Server Error): Typically indicates a server issue.
  • Headers: Additional meta-information about the response.
  • Response Body: The most important part, containing the actual data or information requested from the server.
  • Endpoints: Specific addresses within an API that offer different responses or functionalities (e.g., /status, /books, /orders).
  • Parameters:Query Parameters: Optional or mandatory additional data sent with a request, appearing after a question mark (?) in the URL as key-value pairs separated by & (e.g., ?type=fiction&limit=2). Their behavior is defined in the API documentation.
  • Path Parameters (Path Variables): Values embedded directly in the URL path, representing a specific resource (e.g., /books/{bookId}). They change dynamically and do not use a question mark.
  • Authentication: Many API endpoints, especially those that create or modify data, require authentication. This often involves registering an API client to obtain an access token, which acts like a temporary password and is typically sent in an Authorization header with subsequent requests.
  • JSON (JavaScript Object Notation): A common data format for sending and receiving data with APIs due to its portability and ease of parsing in programming languages. It uses key-value pairs, where keys are strings in double quotes, and values can be strings, numbers, booleans, objects, or arrays.

Writing API Tests in Postman:

  1. Tests Tab: Postman allows users to write tests in the “Tests” tab of a request using JavaScript code.
  2. Assertions: Tests typically involve assertions, which check if the response meets specific expectations.
  • Status Code Test: The most common test is to verify the HTTP status code (e.g., pm.response.to.have.status(200)).
  • Response Body Tests:Parsing JSON: The raw JSON response needs to be parsed into a JavaScript object using pm.response.json() before its properties can be accessed and tested.
  • Checking Property Values: Assertions can verify specific values or properties within the parsed response body (e.g., pm.expect(response.status).to.equal(‘okay’)).
  • Checking Conditions: Tests can also check if numerical values are above a certain threshold (e.g., pm.expect(response[‘current-stock’]).to.be.above(0)).
  1. Debugging with Postman Console: The Postman Console is a crucial tool for debugging. It logs requests and responses and can be used to console.log() variable values or parsed responses during test execution to understand what data is being processed.

Automating API Tests:

To move beyond manual testing, Postman offers several automation features:

  • Variables: Using variables helps avoid hardcoding data and makes tests more dynamic and reusable.
  • Collection Variables: Saved within a specific collection and accessible to all requests within it (e.g., base_url).
  • Global Variables: Available across the entire Postman workspace for all collections.
  • Environment Variables: Useful for different environments (e.g., local, testing, production), allowing easy switching of configurations like base URLs.
  • Random Variables: Postman provides special variables (e.g., $randomFullName, $randomLastName) to generate random data for requests, useful for diverse test data.
  • Dynamic Variable Setting: Variables (like orderId or bookId) can be set programmatically within tests from the response body of one request, then used in subsequent requests, eliminating manual copy-pasting.
  • Collection Runner: A built-in Postman tool that allows you to execute an entire collection of requests with one click. You can define the run order of requests, save responses for review, and enable/disable specific requests.
  • Monitors: Postman monitors allow you to schedule collections to run automatically on Postman’s cloud infrastructure at defined frequencies (e.g., daily, hourly). They send notifications (e.g., by email) if tests fail, providing a way to continuously check API health without keeping Postman open locally. Debugging can be more challenging here compared to local runs.
  • Newman: A command-line interface (CLI) tool for Postman collections. Newman allows you to run Postman collections and their tests from the command line, making it ideal for integration into Continuous Integration/Continuous Deployment (CI/CD) pipelines (e.g., Jenkins, GitLab CI, TeamCity, CircleCI).
  • Exporting Collections: Collections can be exported as JSON files or accessed via public links/Postman API for use with Newman.
  • Reporting: Newman can generate various reports, including the highly useful HTML Extra report, which provides a detailed, visual overview of all requests, responses, headers, and test results, aiding significantly in debugging.

What Postman is NOT Designed For:

Postman is primarily for API interaction and testing, but it has limitations:

  • User Interaction Testing: It is not for testing user interfaces, forms, or button clicks on websites.
  • Performance Testing: It is not designed for sending a large volume of requests in a short time frame for performance testing.
  • Primary Security Testing: While it can be used, it’s not its primary focus, and other tools are better suited for comprehensive security testing.

Overall, API testing with Postman involves understanding API structure, crafting requests, analyzing responses, writing automated tests using JavaScript, and then automating these tests through features like the Collection Runner, Monitors, or Newman for continuous integration.

Postman: A Comprehensive Guide to API Interaction and Testing

Postman is a tool designed for interacting with web-based APIs, meaning APIs that operate over the internet. It acts as an interface to a server, allowing users to send data and receive responses easily. The primary purpose of Postman is to simplify the process of connecting to APIs and to facilitate the sending and receiving of data.

Key Functionalities and Features of Postman:

  • API Interaction: Postman enables you to configure various aspects of an HTTP request and view the corresponding response. This includes setting the URL, choosing the request method (like GET, POST, PATCH, DELETE), defining headers, and adding a request body.
  • Request and Response Handling:Requests: In Postman, you can build HTTP requests by specifying the URL (which combines a base URL and an endpoint), the HTTP method (also known as HTTP verb), headers for meta-information (e.g., Content-Type, User-Agent, Authorization), and a body for sending data (typically with POST or PATCH requests).
  • Responses: Postman displays the API’s response, which includes the status code (e.g., 200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 409 Conflict, 5xx Server Error), response headers, and the response body, which contains the actual data from the server. Data is often formatted in JSON.
  • Organizing Work with Collections: Postman allows you to organize multiple requests into collections, typically for the same API or related use cases. This helps in managing and reusing requests.
  • Variables: To avoid hardcoding values and make requests more dynamic and reusable, Postman supports various types of variables:
  • Collection Variables: Saved within a collection and accessible by all requests in that collection (e.g., base_url).
  • Global Variables: Available across the entire Postman workspace for all collections.
  • Environment Variables: Useful for different deployment environments (e.g., local, testing, production), allowing easy switching of configurations like base URLs.
  • Random Variables: Postman provides special variables (e.g., $randomFullName, $randomLastName) to generate random data for requests, useful for diverse test data.
  • Dynamic Variable Setting: Crucially for automation, Postman allows you to programmatically extract data from a response and set it as a variable for use in subsequent requests, eliminating manual copy-pasting (e.g., setting an orderId after an order is created).
  • API Authentication: Postman simplifies handling authentication by allowing users to register API clients to obtain access tokens (temporary passwords). These tokens are then typically included in an Authorization header for subsequent requests, often using an “Authorization helper” like “Bearer Token” to auto-generate the header.
  • API Testing Capabilities: Postman is central to API testing by enabling users to:
  • Write Tests: Users can write JavaScript code in the “Tests” tab of a request to define assertions.
  • Use Code Snippets: Postman provides built-in code snippets to quickly generate common tests, such as verifying the status code (pm.response.to.have.status(200)) or parsing JSON responses.
  • Assertions: Tests involve asserting expectations against the API’s response, like checking specific property values in the JSON body (pm.expect(response.status).to.equal(‘okay’)) or numerical conditions (pm.expect(response[‘current-stock’]).to.be.above(0)).
  • Debugging: The Postman Console is a vital debugging tool, logging requests and responses and allowing console.log() statements to inspect variable values or parsed responses during test execution.

Automation of API Testing with Postman:

Postman offers several ways to automate the API testing process, moving beyond manual execution:

  • Collection Runner: A built-in feature that allows you to execute an entire collection of requests with one click. You can define the run order, enable/disable requests, and save responses for review. It can also use postman.setNextRequest() to control the flow of execution within a collection.
  • Monitors: Postman Monitors enable scheduling collections to run automatically on Postman’s cloud infrastructure at specified frequencies (e.g., daily, hourly). They can send notifications (e.g., by email) if tests fail, providing continuous API health checks. Note that debugging can be more challenging here compared to local runs.
  • Newman: A command-line interface (CLI) tool for Postman collections. Newman allows you to run Postman collections and their tests from the command line, making it ideal for integration into Continuous Integration/Continuous Deployment (CI/CD) pipelines (e.g., Jenkins, GitLab CI, TeamCity, CircleCI). Collections can be exported as JSON files or accessed via public links for use with Newman. Newman also supports various reporting options, including the valuable HTML Extra report, which provides a detailed, visual overview of requests, responses, and test results for debugging.

What Postman is NOT Designed For:

While powerful for API testing, Postman has specific limitations:

  • User Interaction Testing: It is not for testing user interfaces, forms, or button clicks on websites.
  • Performance Testing: It is not designed for sending a large volume of requests in a short time frame for performance testing.
  • Primary Security Testing: While it can be used for some security checks, it is not its primary focus, and other specialized tools are better suited for comprehensive security testing.

Mastering HTTP Requests in Postman

HTTP requests are fundamental to how Postman interacts with web-based APIs. In a client-server communication model, an HTTP request is the message sent from the client (e.g., Postman) to the server or API. The server then sends back an HTTP response.

Postman allows you to configure many aspects of an HTTP request, enabling users to easily send data and receive responses.

Components of an HTTP Request:

  1. URL (Uniform Resource Locator): This is the address where the request is sent. It often consists of a base URL and an endpoint.
  • Base URL: The main address of the API (e.g., https://simple-books-api.com). Postman allows you to save this as a variable (e.g., base_url) to avoid hardcoding and make requests more reusable.
  • Endpoints: Specific paths that offer different kinds of responses or functionalities within an API (e.g., /status, /books, /orders).
  1. Request Method (HTTP Verb): This specifies the action you want to perform on the server. Postman provides a dropdown to select the method.
  • GET: Used to retrieve data from the server. It typically does not include a request body.
  • POST: Used to send data to the server to create a new resource (e.g., to order a book, register an API client). This method requires a request body.
  • PATCH: Used to update an existing resource on the server by sending only the changed data. This method also allows for a request body.
  • DELETE: Used to remove a resource from the server. It typically does not require a request body, only the identifier of the resource to be deleted.
  1. Headers: These are like meta-information or additional information that travels with the request. Postman automatically adds some headers, such as User-Agent.
  • Content-Type: A common header that tells the server the format of the request body (e.g., application/json).
  • Authorization: A crucial header for authentication, used to send access tokens or other credentials to private API endpoints. Postman provides an “Authorization helper” (e.g., “Bearer Token”) to auto-generate this header correctly.
  1. Request Body: This is where you send the actual data to the server, typically with POST or PATCH requests.
  • The body is often formatted as JSON (JavaScript Object Notation), which is a key-value way of sending data. Postman helps ensure JSON validity, warning you if it’s malformed.
  • Data types within JSON (e.g., strings in double quotes, numbers without quotes, booleans) are important for valid JSON.

Parameters in Requests:

HTTP requests can include parameters to filter, limit, or identify resources.

  • Query Parameters:Additional data submitted with the request, found in the URL after a question mark (?).
  • They are structured as key-value pairs (e.g., type=fiction, limit=2).
  • Multiple query parameters are separated by an ampersand (&).
  • Their availability and expected values are defined in the API documentation. If an incorrect value is sent, the API may return a 400 Bad Request status code with an informative error message in the response body.
  • Path Parameters (or Path Variables):Part of the URL path itself, used to specify a value for a variable within the path (e.g., /books/{bookId}).
  • Unlike query parameters, they do not involve a question mark and the key (e.g., bookId) is not sent, only its value.
  • Postman displays them nicely in the editor, making it easier to see and change the values (e.g., changing bookId from 1 to 2).

Request Outcomes (Status Codes in Response):

While status codes are part of the response, they directly indicate the outcome of the request:

  • 2xx (Success): Indicates the request was understood and processed successfully.
  • 200 OK: General success.
  • 201 Created: A new resource was successfully created as a result of the request.
  • 204 No Content: The request was successful, but there is no content to return in the response body (e.g., for successful PATCH or DELETE requests).
  • 4xx (Client Error): Indicates that something was wrong with the request sent by the client.
  • 400 Bad Request: The API understood the request, but the data sent was incorrect or invalid (e.g., invalid query parameter value, invalid request body).
  • 401 Unauthorized: The request requires authentication, but no valid authorization credentials were provided.
  • 404 Not Found: The requested resource does not exist (e.g., trying to get a book with a non-existent ID, trying to order an out-of-stock book).
  • 409 Conflict: The request could not be completed due to a conflict with the current state of the resource (e.g., trying to register an API client that’s already registered).
  • 5xx (Server Error): Indicates an issue on the server side.

Automating Requests with Postman:

Postman facilitates the automation of sending requests and managing their data:

  • Variables: Requests can use collection, global, or environment variables to store values like base_url or access_token, making requests reusable and adaptable across different scenarios or environments.
  • Dynamic Variable Setting: Postman tests can extract data from a response body and set it as a variable for subsequent requests. This avoids manual copy-pasting and enables chained requests (e.g., creating an order and then using the returned orderId to get or delete that specific order).
  • Random Variables: Special variables (e.g., $randomFullName) can be used in request bodies to generate random data, useful for testing with diverse inputs.
  • Postman Console: This debugging tool logs the full request and response, including headers and body, which is crucial for understanding what was sent and received, especially when issues arise.

Postman: Mastering API Test Automation

Test automation in Postman transforms the manual process of verifying API functionality into an efficient, repeatable, and less time-consuming operation. Instead of manually inspecting API responses, Postman can be configured to automatically check if the API behaves as expected.

Why Automate API Testing with Postman?

  • Reduced Manual Effort: Automating tests means you no longer have to retest everything manually when an API changes, which saves a significant amount of time.
  • Eliminate Manual Copy-Pasting: Automation avoids the need to manually copy data (like an orderId or access_token) from one request’s response to another request’s body or URL.
  • Proactive Issue Detection: Postman can be set up to perform continuous checks, notifying you if something goes wrong with the API.

Key Components Enabling Automation

  1. Writing API Tests:
  • JavaScript Code: Postman allows you to write JavaScript code in the “Tests” tab of a request. This code executes after the API receives a response.
  • Assertions: Tests involve assertions, which are statements that check if the API response meets certain expectations. For example, pm.response.to.have.status(200) checks if the status code is 200.
  • Code Snippets: Postman offers built-in code snippets to quickly generate common tests, making it easier for beginners.
  • Parsing JSON Responses: Since API response bodies are often in JSON format, tests commonly involve parsing the JSON response into a JavaScript object (e.g., pm.response.json()) to access specific data points for assertions.
  • Debugging with Postman Console: The Postman Console is a crucial tool for debugging. It logs requests and responses, and console.log() statements can be used within tests to inspect variable values or parsed JSON objects, helping in understanding what data is available for testing.
  1. Using Variables for Dynamic Data:
  • Variable Scopes: Postman supports different variable scopes:
  • Collection Variables: Saved within a collection and accessible by all requests in that collection (e.g., base_url).
  • Global Variables: Available across the entire Postman workspace, accessible by all collections.
  • Environment Variables: Useful for different deployment environments (e.g., local, testing, production).
  • Dynamic Variable Setting: A powerful automation feature is the ability to programmatically extract data from a response and set it as a variable for subsequent requests. For example, after creating an order, the orderId from the response can be stored in a global variable and then used in “Get an Order” or “Delete Order” requests, eliminating manual copy-pasting.
  • Random Variables: Postman provides special random variables (e.g., $randomFullName, $randomLastName) that can be used in request bodies to generate diverse test data without manual input.

Postman’s Automation Tools

  1. Collection Runner:
  • A built-in Postman tool that allows you to execute an entire collection of requests with a single click.
  • You can define the run order of requests, enable or disable specific requests, and choose to save responses for review and debugging.
  • It offers a visual report of test successes and failures.
  • The postman.setNextRequest() function can be used in tests to control the flow of execution within a collection, allowing you to skip requests or create conditional workflows.
  1. Monitors:
  • Postman Monitors enable you to schedule collections to run automatically on Postman’s cloud infrastructure at specified frequencies (e.g., daily, hourly).
  • They can send notifications (e.g., by email) if tests fail, providing continuous API health checks even when Postman is not open.
  • Debugging issues that occur in monitors can be more challenging compared to local runs, often due to missing or improperly set variables (especially if not defined in the “initial value” when sharing collections).
  1. Newman:
  • Newman is a command-line interface (CLI) tool for Postman collections.
  • It allows you to run Postman collections and their associated tests from the command line, making it ideal for integration into Continuous Integration/Continuous Deployment (CI/CD) pipelines like Jenkins, GitLab CI, TeamCity, or CircleCI.
  • Exporting Collections: Collections can be exported as JSON files or accessed via public links for use with Newman.
  • Reporting: Newman supports various reporting options, with the HTML Extra report being particularly valuable. This report provides a detailed, visual overview of requests, responses, and test results, crucial for debugging in an automated pipeline. It includes full request and response logs.

By leveraging these features, Postman enables comprehensive API test automation, ensuring the reliability and functionality of web-based APIs within development and deployment workflows.

Newman: Postman Collection Automation for CI/CD Pipelines

Newman is a command-line interface (CLI) tool for Postman collections. It allows you to run Postman collections and their associated tests directly from the command line, making it an essential tool for integrating API tests into Continuous Integration/Continuous Deployment (CI/CD) pipelines.

Key Aspects of Newman CLI:

  • Purpose and Benefits:
  • Automated Execution: Newman automates the execution of your Postman collections, eliminating the need to manually click through requests in the Postman application.
  • CI/CD Integration: It is designed for use in professional build and testing servers like Jenkins, GitLab CI, TeamCity, or CircleCI. This means you can automatically run your API tests as part of your software build and deployment process.
  • Proactive Issue Detection: Newman helps ensure the API is working properly after deployment, notifying you if tests fail within the pipeline.
  • Prerequisites:
  • To use Newman locally on your computer, you need to have Node.js installed.
  • Accessing Postman Collections for Newman: There are multiple ways to provide your Postman collection to Newman for execution:
  • Export as JSON File: You can export your collection as a JSON file from Postman.
  • Public Link: Postman allows you to generate a public link for your collection. However, remember to update the link manually in Postman every time you make changes to the collection for Newman to pick them up.
  • Postman API: It’s also possible to access collections via the Postman API using an API key.
  • Running Collections with Newman:
  • The basic command to run a collection is newman run [collection_path_or_link].
  • Newman can run collections supplied either as a local JSON file or via a public HTTP link.
  • Potential Failures: Runs might fail due to missing Postman variables or tokens that were not set as initial values or were only available as global variables and not properly exported (e.g., if environments are not exported along with the collection).
  • Reporting with Newman:
  • Importance of Reports: Generating reports is crucial for debugging and understanding what happened during the test run, especially in an automated pipeline where you don’t have direct access to the Postman GUI.
  • HTML Extra Report: The HTML Extra report is highly favored in the Postman community.
  • It provides a detailed, visual overview of what has happened, including requests and responses.
  • It contains full request and response logs, which are extremely helpful for debugging issues.
  • You can specify multiple reporters (e.g., cli and htmlextra) using the –reporters flag.
  • Integration into CI/CD Pipelines:
  • In a typical CI/CD pipeline, after an API’s code is compiled and deployed to a server, Newman is used to run API tests.
  • The results of these tests, including detailed reports from HTML Extra, can then be reviewed within the pipeline’s interface (e.g., in GitLab CI, Jenkins) to determine the success or failure of the deployment.
  • Newman allows you to specify environments and other configurations when running tests in a pipeline.
  • Debugging with Newman:
  • The rich data in Newman reports (like full request headers, request bodies, and response bodies) is invaluable for debugging when tests fail in an automated context. If a Postman variable wasn’t resolved, for example, the report will show it, indicating a potential configuration issue.
Postman Beginner’s Course – API Testing

By Amjad Izhar
Contact: amjad.izhar@gmail.com
https://amjadizhar.blog


Discover more from Amjad Izhar Blog

Subscribe to get the latest posts sent to your email.

Comments

Leave a comment