Each endpoint folder is then split into separate Positive Tests and Negative Tests folders, the purpose of which is hopefully obvious from the names. The Postman collection is broken down into separate folders per endpoint (each folder is named after the endpoint), although only the Posts endpoint folder has been created at this stage to keep the project light as it is intended to be a template rather than a full implementation of the API testing. That way if the base URL or endpoint changes we don't need to go through all the requests changing the URI and can just change the value of the variable. These variables may be combined, e.g., the URI for a request can be set to rather than. There are also two 'permanent' variables defined in the environment file: In this case we have six variables defined at the collection level - one per endpoint: These are available to all requests and any code within the collection, but are not accessible outside the collection. Postman collections and environments support the declaration and storage of variables. the base API URL) or 'temporary' variables that are declared in pre-request scripts, with the tests then reading those variables for use in assertions. These may be variables that may vary between environments (e.g. They are also handy for storing variables (see below). Postman EnvironmentĪs stated above, environment files are a quick way of switching between different configurations such as test and production. We can exploit both of these to help with our tests. Both are points at which JavaScript code can be entered with pre-request scripts run before the request is sent (as the name suggests) and tests run afterwards. The collection itself is hierarchical with three main components:Įach level in this hierarchy supports pre-request scripts and tests. The Postman collection is a JSON structure containing all the API requests and the associated tests. I suggest only opening and editing the files via Postman itself to ensure the right formatting of the files. test and production environments.īoth files are in JSON format so can be edited in any text editor, but I wouldn't recommend it. The second file is the Postman environment - primarily used to enable fast switching between different configurations e.g. The first file is the Postman collection - this contains all the individual requests and tests and as such is the main file within the test suite. JSON Placeholder Env.postman_environment.json.JSON Placeholder.postman_collection.json.The Postman test suite here is made up of two separate files: The API has no authorisation/authentication applied so that aspect is not tested here. Some of these resources are related to one another e.g., posts have comments, albums have photos, users make posts etc. The API has six endpoints across a number of different types: The API tested here is the JSON Placeholder API, a free fake API for testing and prototyping. developers and QA), or significant mocking functionality is required then a paid plan will be necessary. As more collaboration between team members (e.g. That same plan will also support a significant expansion of the current test suite and creation of further test suites for other APIs (the number of APIs and requests that can be made is unlimited in the free tier), so it remains a cost-effective option for API testing. This tier is adequate for this test suite i.e. Postman has a free tier to their pricing plan which allows up to 3 users to access the basic functionality. I want to show how more detailed tests can be written - and easily maintained - within Postman. Often people use the code snippets to perform simple response code checks but may not go beyond this. There is no support for other languages, and the Postman syntax can be a little strange if you're not used to it, even if you're an experienced JavaScript coder but at the same time there are a number of code snippets provided within Postman to help you create your tests. Postman tests are written using JavaScript and the Chai assertion library. However, Postman is capable of much more and is often overlooked as an automated API testing tool. It is simple to build & send requests and examine the responses, making it popular for exploratory and manual testing of APIs. Postman is a popular and easy-to-use API testing tool. It is an example of how to structure a Postman test suite but only a subset of the requests (tests) have been added. NB This is not a complete implementation of a Postman test suite for the target API. It can be used to kickstart testing of other REST APIs with minimal changes to the project. This project provides an example for testing REST APIs with Postman.
0 Comments
Leave a Reply. |