Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

One or more tests can be defined at the request level, or even at the whole collection level.

Image RemovedImage Added

Pre-request scripts may be useful as a means to initialize some data before the test or to implement some test setup code.

...

We start by cloning an existing Postman collection from a template and importing it to Postman.

Image RemovedImage Added 


The collection contains a request per each endpoint, where each request has one or more tests.

Image RemovedImage Added   Image RemovedImage Added

In the previous example, we can see two tests: one for validating a successful HTTP request based on the status code and another that checks the response's JSON content. 

...

The collection (or a subset of its tests) can be run using the Collection Runner.

Image RemovedImage Added  Image RemovedImage Added  Image RemovedImage Added

The runner shows the overall count for the number of passed and failed tests. We can also see the assertion error on failed tests; in this case, saving the response (setting the proper flag above) can help us better understand what is happening.

...

In this case, we'll obtain a public link to it.

Image RemovedImage Added   Image RemovedImage Added 


Then we need to decide which Newman reporter to use. Newman provides a built-in JUnit reporter; however, better alternatives exist such as junitxray or junitfull.

...

If using Jenkins, we need to configure a build step to execute "newman" command.

Image RemovedImage Added


Importing results is as easy as submitting them to the REST API with a POST request (e.g. curl), or by using one of the CI plugins available for free (e.g. Xray Jenkins plugin).

...

We could eventually fill/identify the Test Environment to associate to the Test Execution based on the Postman's Environment being used if it would make sense for us to analyze the results on a per-environment basis.

Image RemovedImage Added


A Test Execution will be created containing results for all tests executed. Actually, in our specific case and only for demonstration purposes, two Test Executions would be created due to the fact that we're generating two JUnit XML files from the different Newman reporters. 

...

In this example, we're looking at the Test Execution (and related Tests) created as a consequence of importing the JUnit XML report produced by the Newman reporter newman-reporter-junitxray.

Image RemovedImage Added


Within the execution screen details, you can look at the Test Run details which include the duration, overall result, and also any eventual error message.

Image RemovedImage Added


Info
titleWhat would be the results if I used "newman-reporter-junitfull"?

If you would use "newman-reporter-junitfull", you would obtain many more Test issues as seen ahead.

Some of these Tests would have the same Summary as it would be populated from Postman test's description.

Image RemovedImage Added

Image RemovedImage Added

Tips

  • After importing results, you can link Test issues to existing requirements or user stories, so that you can track coverage on real-time directly on them
  • You can map Postman's environment to Xray's Test Environment concept on Test Executions if you want to have visibility of the results on a per-environment basis
  • Multiple iterations/executions can be linked to an existing Test Plan, whenever importing the results
  • If you run the tests multiple times with "newman -n <number_of_iterations>" parameter, multiple entries will appear within the Results section of the Test Run execution screen details
    • Image RemovedImage Added

References