If you've worked in QA automation for awhile you have no doubt heard of the test pyramid. The test pyramid is a diagram used to visually depict test types, and to give some general guidelines on how many of each to create.
As you can see from the pyramid, a well-rounded automated test suite should have a large number of unit tests, fewer API or integration tests, and even fewer end-to-end UI tests. Unit testing is the handled by the developer, UI testing is handled by QA, and API testing is typically a somewhat shared responsibility.
At times a QA team will focus on UI testing and ignore API testing. It's easy to understand the infatuation with UI tests:
- UI tests are easy to map to user stories.
- The business user can easily relate to UI tests.
- Most folks working in QA automation have more experience with UI automation.
- UI tests are a lot more fun to demo compared to a command line API test.
So why do we want more API tests that UI tests? I can think of at a number of reasons:
- API tests allow for more code coverage, since it's easier to test different code paths and error situations.
- API tests run much faster, so we can get faster feedback to the developer.
- API tests can find bugs earlier, before the UI layer is created.
- API tests can be created before the API is developed by using mocking frameworks.
- API tests are less brittle, therefore less costly to maintain.
- API tests are necessary for APIs that don't have a UI, such as APIs that are consumed by IoT devices or other services.
There are a number of tools that can be used to test APIs, such as SoapUI and REST Assured. Another is Postman. I have used Postman for a number of years for quick manual testing of REST services, but only recently have I really started looking at everything it provides. So what is Postman?
Postman is an HTTP client marketed to both developers and testers to support development and testing of APIs. Postman is available as a standalone client, and also as a Chrome app. Google has announced plans to end support of Chrome apps in the near future, so the native standalone app is the way to go.
Collections
Everything with Postman starts with collections, which is how you store and categorize your individual API requests. Collections allow you to organize your API requests in folders and subfolders, and the requests can be run together in Postman via Collection Runner.
Pre and post scripts
Postman allows automation developers to use JavaScript in any API request to interact with the API request, API response, and global and environmental variables. These scripts are typically used to pass data between related API calls in a collection, and to verify the results from the API request match the expected results. For example:
Verify the response status code:
pm.test("Status code is 200", function () {
pm.expect.response.to.have.status(200);
});
Verify the response time of the request:
pm.test("Response time is less than 500ms", function () {
pm.expect(pm.response.responseTime).to.be.below(500);
});
Verify the data returned by the request:
pm.test("Customer Name Updated correctly", function () {
pm.expect(jsonData.lastName).to.eql("Smith");
});
Environmental variables
As you build and run tests, you'll typically need to run the tests in a number of environments, such as local, dev, test, UAT, etc. Postman provides an easy mechanism to define specifics about each of your environments and to quickly switch between them.
Test and develop in parallel
One of the drawbacks with UI testing is that you need the developer to develop the functionality before you can really start building the the guts of the test automation. With API testing, you can start testing when the API is complete, even if the front-end components have not been started.
Additionally, with mocking you don't even need the API to be complete. Postman provides a mocking service that allows you to define an API endpoint with the expected input and output. When the sprint starts you can build and run your automation tests against that mock service. Once the development team completes the API, you can just point to the API and run your test.
Proxy server to capture API calls
If you're looking to quickly identify and build a test process for an existing business transaction, Postman provides a mechanism to capture the API traffic for a particular transaction and store the API calls in a Postman collection. Just turn on Postman's transaction interceptor, manually step through the transaction via the UI, and the API calls will be captured in a Postman collection.
Automating API test with Newman CLI
Newman is a command line tool, written on Node.js and stored in the NPM repository. Once it's installed, you have the ability to run a Postman collection from the command line. With Newman you can incorporate API testing and custom reporting into the CI/CD pipeline.
Team Collaboration
One of the key features of Postman Pro is sharing and team collaboration. Postman collections can be shared and edited by authorized team members via a team API library in the cloud. The team activity feed allows you to see all modifications made to a collection and to rollback to a previous version when necessary.
Pricing
Postman comes in 3 pricing plans: Free, Pro, and Enterprise. The core features for testing are included in the Free version. The Pro version offers options for team collaboration in the cloud, while the Enterprise version includes extended support and higher cloud usage limits. If you're just getting started, the Free version will give you everything you need, and there are trial versions of Pro and Enterprise when you are ready.
Next Steps
In this post I have only scratched the surface regarding some of the cool features that Postman provides To learn more about Postman and API testing, the Postman website is a great place to get started. Also, Postman has a yearly tech conference and the sessions and talks from last year are available to view for free.
Finally, don't get so enthralled with UI testing that you lose sight of API testing. Be like the test pyramid; spend a lot more time with API testing than you do with UI testing!
Top comments (0)