As APIs become more widely used in businesses and web applications, it's more common than ever that developers need to test, monitor, and interact with these services daily. So choosing which tools you and your team use is important, and can save you time and energy in creating tests, setting up automation, and reacting to failures.
Assertible and Postman are both great services that support a lot common functionality for testing and monitoring APIs and web services. In this post I'll illustrate a few key differences that make Assertible excel in areas important to your business or project.
Side note At Assertible, we firmly believe in dog-fooding our own product extensively. To do this, we consistently test as many other competing products as possible. Postman is one of these tools.
API oriented architecture
Assertible's architecture is based around the concept of a web service and closely reflects your real world API. A web service has tests, environments, integrations, etc. This structure makes it possible to create many independent tests, calculate more advanced metrics, and gain a better understanding about the health of your API.
The image above is the overview for the Assertible API. At a glance, you can quickly guage the performance of the service, the health of individual endpoints, and recent activity about tests. Learn more about what web services incapsulate in the docs.
In Postman, there is a less opinionated structure of requests. While this is a flexible way of quickly trying an HTTP request (and that's a valid use-case!), it becomes less helpful when wanting to see the status of multiple requests, or the quality of the web services as a whole.
Tests in Assertible are designed to be run against a specific web service URL, which is advantageous when you're reproducing bugs or setting up automated API tests. With Postman, requests are grouped in Collections which can contain arbitrary requests to any URL. This is not without merit, though; collections are useful for things like sharing tests with your team.
Assertible is designed in this way to provide a few core advantages:
- A web service closely models your real-world API and contains all of the settings for creating tests, monitoring, integrations, and more.
- The web service structure allows for gaining a quick understanding of the quality of API as a whole, as well as individual endpoints and tests.
- API specification formats, like Swagger, can be imported and tested with little effort.
- Tests, and their dependencies like setup steps, can be re-used across other tests on the same web service, making it quick and easy to create new tests for your API.
Codeless web service testing
In any testing tool you choose, it's important that developers, testers, and stakeholders alike are able to create new tests and understand the status of monitors. At Assertible, we enable this by building a truly codeless API testsing tool. While Assertible does support various CI integrations and deployment scripts, we aim to not require any code to create and validate API requests.
This prohibitive to a lot of users who would othewise benefit from being able to see and test their web service. Additionally, as API requirements change, updating, debugging, and maintaining code snippets becomes difficult.
In Assertible, advanced checks like JSON Schema validation, web page link checking, HTML validation, and more, are first-class operations that are fully supported in the user interface and require zero code.
This makes it easy for anyone one your team to get in on the testing action without needing any prior coding knowledge. Ease-of-use is a high priority for Assertible, and not at the cost of powerful and flexible tests. Any developer, tester, or stakeholder, can use Assertible to monitor the status of business critical APIs.
Code snippets are flexible and allow for just about anything. But the biggest downside, and what we've working towards fixing in Assertible, is the flakiness and subtle bugs that come from writing code -- after all, why would you be testing your API if it weren't for subtle bugs!
Built-in monitoring, automation, and alerts
A big goal at the forefront of development for Assertible is powerful automation, easy monitoring, and perfectly timed alerts. Providing an automation-first platform helps teams spend more time developing new features and finding new bugs, while continuously runnning API tests, monitoring regressions, and catching downtime.
Assertible has several ways of automating your API tests, including schedule monitoring, running tests from CI using test triggers, and validating web app deployments with the Deployments API. Automation works well with the architecture of Assertible's tests, web services, and environments (read more about our API testing best practices).
As an example, the Deployments API is a unique feature in Assertible that is built to run API tests immediately after a deployment in order to catch regressions in new deployments. You may have heard this referred to as API smoke testing or post-deploy validation testing.
Additionally, the deployments API supports propogating post deployment test results to GitHub status checks. This is a great feature for developers using GitHub pull requests and continuous deployments, and can't be found with any other API testing tool.
Psst! All of Assertible's automation and integrations can be used on the free plan. Sign up today
Postman also has features for automating tests. In Postman Pro, a paid version, Monitors can be used to continuously run all requests in a Collection on a schedule. These monitors come with some good visualizations about how the tests and requests are performing.
One of the more interesting parts of Postman's automation is in it's free command-line companion Newman:
Newman allows you to run and test a Postman Collection directly from the command line...so that you can easily integrate it with your continuous integration servers and build systems. - Postman docs
Newman has the added benefit of running HTTP requests from the same
system it's being run. If your API or web service is behind a
firewall, this is particularly useful
(Assertible recommends using
Postman Monitors, though, are run remotely and cannot access private services.
I've tried to outline a few points that make Assertible a good choice over Postman for API testing and monitoring while being fair to both services strong points. To complete the circle, there are a few more useful features of Postman not mentioned above:
- Shareable collections and requests are great for teams (Assertible has organizations)
- Postman makes it easy to quickly run and tests different requests (it's what it was built for!)
- Support for generating API documentation from Collections
- Requests are run from your local computer, so private services behind a firewall can easily be tested
We've heavily scrutinized these points before and during building Assertible. We know there are other tools that are great at solving various problems - but we also felt that none of the existing solutions were sufficient for easy, reliable, and automatable API testing. So when building Assertible, we focused on the parts that are most important for teams and individuals who need to test and monitor web services.
If there's anything you think I missed or should add, don't hesitate to reach out or message me on Twitter! I want this article is a fair comparison of the two tools so you can make the right decision for your use-case. Both Assertible and Postman have strong points that should be considered when choosing a testing tool.
Examples and resources:
- Assertible documentation
- Postman documentation
- Techniques to reduce api testing errors and improve your QA process.
:: Cody Reichert
The easiest way to test and
monitor your web services
Reduce bugs in web applications by using Assertible to create an automated QA pipeline that helps you catch failures & ship code faster.Get started with GitHubSign up for free
Assertible joins the OpenAPI initiative 05/09/2018
Automated API testing with TeamCity 03/12/2018
New feature: autocomplete for variables 11/03/2017