The documentation explains how to create tests for an API but says absolutely nothing about running those tests. E.g. once I’ve added a “contract test” to the API, how do I get it to run and validate the defined schema?
Welcome to the community!
Whenever you send a request within Postman, any tests attached to that request will run. This is how you can execute tests on a request by request basis.
If you use the Runner, then you can execute all the tests within a collection in one hit.
Hi guys, you seem to be talking about creating tests for a request/collection. But I asked about the new “API” functionality that has just been added. Through the UI I can add “contract tests” and “integration tests” to the API, but how do I run them?
Hi @jon.r,
This is to clarify that the test suite along with contract tests and the integration tests that are added to a specific API are always associated with a specific collection as you can see in the attached image
As mentioned in an earlier message, you can run the “contract tests” and “integration tests” to the API by navigating to the Collections tab and executing the Runner on the collection you specified for the test suites in the API tab.
@amir.ahmed If I got to the collections runner there is no mention whatsoever of “contract tests”, “integration tests” or any test “suites” at all.
-
Please explain EXACTLY what is a test suite is, how I can add a test to a particular suite, and how I can run a particular suite in isolation, or, better yet, point me to some Postman documentation explaining this.
-
Please explain EXACTLY what the point of defining a “test suite” on the APIs page is, if I cannot open them from there, cannot edit from there, cannot run them from there, and they do absolutely nothing else, or, better yet, point me to some Postman documentation explaining this.
Because as far as I can tell, right now the entire “APIs” tab is placeholder UI that has been included in the app for no reason, and serves no useful purpose at all.
Hi @jon.r,
Ideally speaking, you are naming and organising the collections into a Contract Test collection, Integration Test collection, Test suite collection etc, then you add those collections to the appropriate sections of the Test subtab on the API tab.
By doing this, you have created an association between a specific API schema and the different collections linked to it, each collection having different functions and responsibilities.
For further information on the API workflow, I would take a look at the following link:
https://learning.getpostman.com/docs/postman/design_and_develop_apis/the_api_workflow
As far as I can tell, the three “types” of tests work exactly the same, are run exactly the same, etc. What’s the point of the three separate sections when you could accomplish the exact same by just naming your test collections accordingly?
Also, “linking” your tests to an API doesn’t do anything in the way of being able to use endpoints from that API in the test. You still need to create separate endpoints in your test suite for each API call. On top of that, if you then validate the collection using the button next to the test collection in the API section, it will tell you your test collection is not in sync with the API because it has different endpoints. Well, duh?!
Here’s the thing: one endpoint will normally need several tests to test different combinations of parameters, edge cases, etc. Postman creators seems to think that every endpoint just needs one test.
And the documentation doesn’t help either. For example, the link @aamir.ahmed shared just says that you can add a test collection to an API, but not what that means, how you can use requests from the API in your tests, how you can ensure both the API and the tests get synced to GitHub if you’ve linked your API to GitHub, etc.
Has everyone ever done real life API testing with Postman? Because the more articles I read and videos I watch, the more it feels like the answer is “no”.
Please enlighten me 