Try one of the Reporters. Available reporters are: cli, json, junit, progress and emojitrain. Since you are using AWS, check out their guide on this topic. It might not be exactly what you are trying to do but it does show the moving pieces. Automating your API testing with AWS CodeBuild, AWS CodePipeline, and Postman

I need to check if the “dna” contains at least 10 “Ngg” sites. That means if there are a minimum of 10 [acgt]gg sites (agg or cgg or tgg or ggg). How do I write a test for that? You need to first find all such occurences: resultArray = [...dna.matchAll(/[acgt]gg/g)] then you need to assert the length: pm.test('Number of occurences if equal or greater than 10', function() { pm.expect(resultArray.length).to.be.above(9); }); All put together, it could look like so: const jsonData = pm.response.json(); pm.test('Number of occurences is equal or greater than 10', function() { const dna = jsonData.dna; resultArray = [...dna.matchAll(/[acgt]gg/g)]; pm.expect(resultArray.length).to.be.above(9); }); Is the following test for validating schema correct? Most certainly not. If I copy & paste it and use it as a test for a completely different response, the test passes. You, for example, don't specify any required properties as shown for example here.

Update: Postman v8 is released just now with the fix : https://www.postman.com/downloads/ Now you can see the same web UI in postman desktop app also So you can do both question 1 and 2 through native app

I think there is an issue with postman native app : i tried saving to collection and the request is not showing up in collection but if i use postman web it shows correctly https://identity.getpostman.com/login Goto this dash board and check the collection , i will raise a bug Update Raised a bug: https://github.com/postmanlabs/postman-app-support/issues/9452

The answer depends on many other factors including the infrastructure. Even POST requests can create unwanted changes in production DB so GET is mostly the only safe method, investigate if this is the case for your product. Do you have a staging server where you do rest of the use cases (if you plan to use only POST and GET in production) What is your team decision and what are their expectation What is the product structure, is there test sandbox that you can access from the production environment so that you won't affect real users What kind of product are you testing So as in any test activity, the answer is: The approach is context depended You should have proper risk analysis on what happens if you don't test other http methods and stick to only http GET and POST Is there a backup or restore option if something goes wrong. Sometimes you won't be able to get answers for all those questions due to immature project stakeholders and process. In that case, I would stick to the below procedures: Ensure to test all GET actions and validate the response schema Check authentication and authorization test for test users. Make sure your test accounts have limited authorization and the test accounts have access only to test data. Don't test admin account use cases as it can cause unwanted changes Don't use admin test accounts as account breaches can compromise the entire production environment Check production environment response time Run postman monitor to ensure health of the production API Stay away from CRUD operations other than R (Read, means GET) Discuss with the team on other use cases and be clear on the risk involved

https://explore.postman.com/templates/1692/working-with-graphql This is a postman example , just click try with postman and it opens up postman with collection and everything set up You add test scripts as same like you do for rest api, there is no difference:

We have a good experience with json-server. We found it really flexible. Get a full fake REST API with zero coding in less than 30 seconds (seriously) Created with https://github.com/typicode/json-server It can server from static json files, where each ID returns a different value. Or you can use JavaScript to generate them. You could change the data based on the id, give random data, rotate datasets, etc... They also have a version hosted for you if you want to test over the internet. Small datasets are free: https://my-json-server.typicode.com/

In overall it looks more a question regarding the code-based vs tool-based testing. And for the low-level, technology facing tests, such as integration tests, the code-based approach would give you: A little bit more overhead while writing the tests. You'll have to write the code itself (obviously), and potentially manually write mocks for the components that are out of testing scope. It depends what integration you want to test and what are the components of your system. But on the other side, you'll get the ability to debug your tests with the codebase, and as a result better maintainability and development experience. In case there would be a need to find the root cause of a failure, debugging via IDE and going through the codebase would be faster and more convenient. You'll write integration tests in the same language as your main SUT. It's easier to stick to the same technology stack for system support. Easier integration with CI/CD Free of vendor locking. Postman is a commercial tool, and as any of the commercial tools it has it's own hidden costs. As for Postman: It's easier and faster to test an API from scratch, especially when you lack programming skills. So when you have a limited amount of time and need to quickly test the basic scenarios for endpoints - it's absolutely ok to use the tool. I use it for local development and debugging, for example. It might be easier to mock some endpoints if it's needed. You won't be able to debug your own code (API controllers), so the defect localization speed would increase. More time, more effort. Relatively more overhead with CI/CD integration comparing to regular unit testing frameworks. You may need to buy a license, depending on your needs. The more tests you'll have - the harder and less convenient it would be to maintain, outside the IDE. So it's up to you what to choose. My personal choice is using free Postman for basic testing while development, and later covering controllers with integration tests written in code.

you cannot read files from local system in postman other than for iteration or sending it as request. The two options you have is : Copy paste all the csv content and paste it in an environment variable , then: In your pre-requiste or test script: console.log(pm.environment.get("data")) const parse = require('csv-parse/lib/sync') //Environmental variable where we copy-pasted the csv content const input =pm.environment.get("data"); const records = parse(input, { columns: true, skip_empty_lines: true }) console.log(records) Pass environment variable through command line using powershell : $a= Get-Content -raw .\1.csv newman run .\test.postman_collection.json -e .\test.postman_environment.json -k -r "cli,htmlextra" --env-var data=$a Now use the same above pre-requisite script.

Just to add to the above answer , in JSON {} is a JSON object and [] is an Json array. So the JSON.parse just parses the response string into proper JSON. As the response starts with a {} you can access elements inside it as key-value. hence , jsonData.data will give content inside 'data' field. But now to access content inside data you have to use index as data is json array []. And as there is only one json object {} in the array, use jsonData.data[0] means, the first JSON object in the jsonArray. Now again we have a jsonObject , so to get the field "firstname" we use: jsonData.data[0].firstname When ever you are in doubt in postman just print the content using console.log. so just print : let jsonData = JSON.parse(responseBody); console.log(jsonData); The console output could be viewed in postman console which is under view> show postman console (or by pressing alt+ctrl+c) : When you print it , you can JSON.parse prints the same response body : so here we can see the structure like data>[0]>firstname:

Created a project Called below command in windows batch step: echo %user% Output So the variable is being stored as environmental variable , hence for shell script you can use echo $UserCode Your final shell command would be: //paths to global & env vars up here... run_collection() { collection=$1 newman run ${collection} -e ${PM_ENV_VAR_PATH} --export-globals ${PM_GLOBAL_VAR_PATH} -g ${PM_GLOBAL_VAR_PATH} --global-var "userCode=${userCode}" if [ "$?" == 1 ]; then echo "should fail the build" exit 1 fi sleep 1 } Note: both $variable and ${variable} are same in shell script. ${variable} is used for parameterisation, you can read more at: https://superuser.com/a/935427 so you can use both ${UserCode} and $UserCode Also: Why is --export-globals ${PM_GLOBAL_VAR_PATH} used, this won't use the global variable but stores the variable to the file specified. You have to use --globals ${PM_GLOBAL_VAR_PATH} if you want to use the global variable file

Welcome. You need to read the documentation in detail, it shows an example of a request body for PUT method: { "name":"test1", "salary":"1123", "age":"23" } There is no employee_ in the names of the attributes. So an example flow could look like this: 1) create an employee with POST method: URL: /api/v1/create req body: { "name": "DorisWan", "salary": "50000", "age": "25" } res body: { "status":"success", "data":{ "name":"DorisWan", "salary":"50000", "age":"25", "id":47 } } 2) update the employee with PUT method: URL: /api/v1/update/47 See how I took the id from the previous response body and put it into the URL. req body: { "name": "Doris", "salary": "60000", "age": "26" } res body: { "status":"success", "data":{ "employee_name":"Doris", "employee_salary":"60000", "employee_age":"26", "id":47 } }

https://github.com/postmanlabs/newman#newman-options This gives the entire command-line options for Newman so you can use --global-var "=" to override global variable values. As we know the precedence of variables is as follows: (Precedence increase top to button , meaning local> has more precedence than global) so passing an environmental variable as : --env-var "=" will also override the value

Mohamed's step will allow you to do what you wanted, but if you are trying to debug something then postman already have the postman console for this purpose. so just use console.log() in the prerequisite or test script session and open view>show postman console in the postman menu bar. Now run the request and you can see that the value is printed in the console. Opening: Viewing: Note: if you click on the request it will show all details like the request header, body, response etc in newman htmlextra report you can get these details in the report using the --reporter-htmlextra-logs flag

405 shows that the specific HTTP Method is not supported for the specified endpoint. It have nothing to do with a certificate. You are using POST method on a .html file which most probably ain't supported. Change it to request.get()