pm.test("some string" +res.value +\n+"some string "+res.value) function(){
iteration of response
});
I am not able to print pm.test() values in multiline is there any way?
Hey @Belgi_TST
Welcome to the community! 
The Test name will only be shown on a single line.
What is it that you’re trying to do, there might be an alternative way of achieving this 
ofcourse there is an alternative way… but i want to know is there is any way to get new line feature in test , as because \n is not working
Simple answer is no
I was trying to establish the reasoning behind wanting to do that - Your question didn’t explain why
Thank you for the quick reply
pm.test(“some string” +res.value1 +\n+"some string "+res.value2) function(){
iteration of response
});
in this i tried to print two response values in two line . but its showing in same line , both the values
That’s just repeating the question, rather than explaining why you want to do that in the test name
It will only ever be on a single line, there are no multiple line test names.
I also need to make multiple lines, as there is scroll bar in it and if it is too long, I have to scroll to select the values I want.
So I need to make it simple, and multiple line can help it.
If we can remove the scroll bar in Test result tab, that would resolve this.
I don’t think the reasoning matters here. I came across this thread while I was looking myself for a way to output the test result using multi lines.
In my case, I have a loop that gathers a list of names from a json response, and I simply want to see one name by line, instead of all names in a single line, all in the same pm.test().
So, I would like it to be:
John
Mary
Gabriel
Evan
Instead of:
John Mary Gabriel Evan
As the OP stated, using “\n” in the string doesn’t seem to work.
That’s not main use case of the pm.test() method, it can display an output from the response but it’s primarily used to identify the purpose of the assertions within the function.
The Postman Console would be a much more suitable place to log data.
I believe what myself and the OP were looking for is a way to visualize output NOT in the console.
After much searching, the solution may be in making use of the pm.visualizer function, as explained here: Response is not formatted if there are newlines · Issue #8362 · postmanlabs/postman-app-support · GitHub
In my example above, the names are displayed one per line, since the “\n” is respected in the Visualizer.
This approach allows control over the display output and it can be seen in the right pane, under Body > Visualize, instead of Test Results.
This may be an even better solution since you can visualize the way you want and still have the Test Results pane for actual tests.
The visualizer can be used for multiple use-cases.
My original statement about the pm.test() not being the correct place for this output still stands 
The denial is strong here 
I think the takeaway is that, as a beginner, as I was a few days ago, you look for ways to display results and you think that Tests may be that place because of the convenient placement of the Test Results view in the right pane.
At that point, you probably don’t yet know of the Visualizer, or at least you don’t consider it to be what you need, because the section about it in Learning Postman contains very fancy outputs (with bar charts, heat maps and other graphs) that may not apply when all you want is to see some text.
While the console is a good place to “log” data, it is not meant to separate and display final output, unless you adopt a two console approach, one filtered for logs and errors, the other for info only and you use the console.log and console.info commands accordingly.
But then again, that’s not something you’d know it’s possible as a beginner trying to wrap your mind about how Postman works.
It would be much simpler if Postman had an Output tab right next to the Test Results tab, so you can type something like:
output.print(loopResults);
I’m not sure what I’m supposed to be denying 
This tab for the visualizer was always there, every time you looked at a response, that contained a link to the documentation. Showing those examples on the documentation is put there to allow folks to know what might be possible
It’s a bigger feature than just using it for your basic use case of displaying data on a new line, start exploring its capabilities and you will very soon realise that covering every example in the documentation would be very difficult.
- Visualizer - Filter Response Body data using JSONPath
- Create and save JSON data files from the Visualizer
- Copy the request URL to the clipboard - #3 by dannydainton
The Postman Console is the output tab - It’s for logging a whole host of things in there, not just data from the response but using that as a means to debug your scripts etc.
Postman is huge and there are so many features that you wouldn’t be exposed to straight away unless you have a specific need to use them. We’re very fortunate to have an awesome community of people that create content about everything that you could possibly do on the platform. We also have the Learning Center, this Community Forum and a great selection of videos on our YouTube channel
There are also internal folks like myself who drop into the Community Forum to help unblock users or suggest different solutions to problems.
Yes, I noticed there is an amazing community actually, and the more I discover, the more I appreciate all the resources made available by the Postman team.
And yes, after you get familiar enough with the way things work in Postman, things begin to settle in and make sense.
But, before that happens, it “feels” like a dark hole and the little things that more experienced users understand and take for granted are not obvious.
Like the fact that the console is where everything happens is not obvious when you have a “Tests Results” tab right in front of your eyes, that you “think” will display output from the code you write in the Tests tab.
Personally, it took me a while to “get” the collection runner and until then I spent couple of days trying to cook ways to get return values from pm.sendRequest, which I didn’t realize at first were async operations. I thought collections were just folders to organize requests.
The newb brain works like this:
if ( i type code in tests tab to process query response ) {
i need to show the output somewhere with line breaks
if ( to see output in test results i need to use pm.test ){
i will type everything inside a pm.test()
....because otherwise nothing gets displayed in test results and i don't know how else to go about it
}
}
There are two main factors that I believe contribute to the confusion of the beginner:
- The Visualize tab is empty by default
The Visualize tab is nested under Body, alongside other formats (Pretty, Raw, Preview) that will always display something, whereas Visualize is always empty by default. So as you explore the interface to make sense of what see where, you quickly dismiss Visualize because it is always empty alongside the rest of the options which are always not empty.
Because the Visualizer is indeed such a powerful feature that requires intentional configuration through code (unlike Body > Pretty, Raw and Preview which do not), I think it would be better placed outside of Body and by itself after Test Results (since Test Results is also empty unless intentionally configured to display test results).
Actually, it would be even better if there was a Visualize tab in the main pane (alongside Pre-request Script, Tests), so you know where exactly where you place visualize code (the same way Test Results has its own Tests section).
It doesn’t help either that the visualizer doesn’t have a default template and that pm.visualizer.set requires a template parameter (which in turn requires you to have a grasp on Handlebars).
Thus, you can’t just “visualize” with a simple command like pm.visualize(loopResults).
- The expectation is that post-request logic is handled in the Tests section.
I think there may be a design flaw here, due to the expectation to enter code that handles query response in the Tests section. This is because there is nowhere else to enter that code.
Tests should hold only test code.
Any code that handles post-request anything should be entered in a Post-Request Script section, the same way that pre-request code is entered in the Pre-request Script section.
Thus, the main pane would have:
Params Authorization Headers Pre-request Post-request Visualize Tests Settings
and the right pane:
Body Cookies Headers Visualize Test Results
In the end, the console should be the console as it is for many other apps, for logging errors and testing variable values, and not a catch-all solution as it seems to be considered now.
I’d be happy to post this feedback anywhere else Postman accepts suggestions for improvement.
The visualizer tab should be showing this and not an empty state:
There are a few things you can get from that, 2 of them being the syntax and where to learn morning about the feature. That does go to the high-level explanation but the basic command structure of it is on the same page
A default template should be added to the snippets as well as some other helper scripts that are missing, as we have updated the functionality that has fallen behind a little bit.
I agree that Tests is a terrible name for that tab, have thought that way for a long time and it should really be called Post-request Scripts or something else that conveys what’s happening in that sandbox - And also you can write assertions against the response in there using pm.test()
The console isn’t a catch-all solution its usage is exactly how you described and a little more but that feature too has its limitations, as does the visualizer depending on the context and the goal you’re trying to achieve.
The Visualize tab for me has always been blank. I’ve never seen it as in your screenshot, which makes more sense.
Here’s screenshot of a simple request that passes a test and that makes no use of pm.visualizer.set anywhere.
I don’t know which version of the platform and on what OS you’re using?
I am using:
Postman v10.0.25
Windows 10 Pro
Version 21H2
OS build 19044.2006
Experience Windows Feature Experience Pack 120.2212.4180.0
Interesting - do you see the same on the Web version?
Yes, on the web, I see it like in your screenshot.