[Bug] Search field and sort filters are only available for the first iteration on the Test Information

[yyahav]

Is There An Existing Issue

• I have searched the issue tracker for similar problems.

What Are You Seeing

The TESTS INFORMATION data table showing the tests is a DataTable, which supports search and sort by default.
Only the first itreration shows the Search field and includes the sort, the other iterations show a regular table without these features.

Steps To Reproduce The Issue

1. Run newman with htmlextra reporter, using default template.
2. Open the report in the browser.
3. Select iteration 1 - see search field and sort options
4. Select iteration 2 - no search field or sort

See attached images for iterations 1 and 2 tables diff

Full Newman Command Or Node Script

newman run collection.json -d data.csv -r htmlextra --reporter-htmlextra-export newman\report.html

HTMLEXTRA Version

1.22.7

Newman Version

5.3.2

Additional Context

No response

[github-actions]

Hey! 👋🏻

Thank you so much for raising the issue, I will review this as soon as I can get to it. ❤️

Danny

[DannyDainton]

Hey @yyahav,

I've run a collection through Newman and created a report, I'm not seeing the same issue. I can see the search and filters on the other tables for each iteration. 🤔

Do you see any console errors in the browser when looking at those other tables?

[yyahav]

Hi @DannyDainton ,
I tried running again, and looked for console errors in developers tab, but none were displayed. I do see a hidden issue but unable to unhide it.
Weird that you saw the search and sort on other iterations... 😳
How can I help you reproduce this? Do you require anything? I can send you a censored newman json but I'm not sure if that would help...
Maybe you have a different default template than the one I have installed?

[DannyDainton]

Nope, using the same default template 🤔

There is actually some work I wanted to do around those tables, let me try and get something in place tomorrow ish and see if that helps you out.

[DannyDainton]

Haven't been able to spend much time on this yet and add the changes I want to, been busy with my day job. 😄

I still haven't been able to recreate this issue you're seeing either :(

20220401151850526.mp4

One thing I haven't looked closer at is the data file you're using and how you're using the data from that in the tests.

[yyahav]

Hi @DannyDainton all good, it's not urgent :)
Regarding the data file, unfortunately it is classified. I can create a similar data file, but it's pretty much standard csv, with only 2 iterations.
The request itself is mapped to the csv according to Postman's instructions. I just used ${column_header} in the json values.
Maybe you can use the attached newman object report (-r json). I've stripped all confidential info such as request and response, the test and csv variables. Maybe it has something to do with the assertions?

Could you send me your default template so I can try to test with it? Maybe I have an outdated version?

newman-run-report-2022-04-03-11-31-39-993-0.txt

[DannyDainton]

It's the default template of the reporter - if you're not using a custom template, then you're using the same one 😂

Could you show a short recording of the file and you switching between iterations?

I'm honestly not interested in any of the data of the report file, they mean absolutely nothing to me. 😂 Trying to see this in action, it's hard to know what's going on with a cropped screenshot 😞

[yyahav]

Sure, here's a recording... I hope it helps

2022-04-03.16-18-12.mp4

[DannyDainton]

Interesting 🤔 The request and response sections also look weird too. Unless you're hiding the details in a flag.

Umm...hate to offer this as a resolution step but have you tried and global uninstall/install yet?

npm -g uninstall newman-reporter-htmlextra 

Then...

npm -g install newman-reporter-htmlextra

Sometimes it's actually the thing that gets it all back aligned again. 😬

[yyahav]

Tried now global uninstall/install, won't do the trick.
This is so weird... I can't wrap my head around it...

For you it works without any issues, but for some mysterious reason I can't get it to work the same on my end.
Could the assertions in Newman's json object change the DataTables rendering from the template?

Regarding the request/response I hid them... it's not an issue.

[DannyDainton]

Nah, those are based on the requests and handled in the template file. If the request is there, the table should be rendered correctly.

Going to be difficult to solve these types of issues as it looks specific to your context. No one has ever mentioned that issue before and it's been downloaded a few times.

Without seeing the report file locally, there is literally nothing that I can do here. I can't really fix something I can't replicate/reproduce.

[DannyDainton]

How many tests are there in the second iteration? Are they exactly the same as the first and in the same order?

Is there some kind of logic that you have in the test script? Can you share the test script for that request?

[yyahav]

That's a great question! And I have a feeling that this is the problem. 😅

The tests amount is the same on both iterations, and the order should be the same as well (the same test script runs for both iterations and the first table is sorted, that's why there's a difference in the order between tables), but their names change according to the response.

I had to do it this way, because I'm trying to output some of the field values from the response within the test assertion, so I can see them on the report. You can see those on the clip I sent, each test name holds numeric info relevant for the iteration.

I'm not familiar with any other way to retrieve field values and output them later on in the report, as I understand it's possible to only show test names without any additional info.
Unless, of course, I fail the assertion with a message containing the data, but then all tests will show as failed and that's a lot of RED 😁

So, basically the script is built this way:

data = pm.response.json();
applicationId = data.applicationId;
idNumber = pm.iterationData.get("idNumber");

pm.test(`app ${applicationId}`, () => {
    pm.expect(true);
});

pm.test(`id ${idNumber}`, () => {
    pm.expect(true);
});

Assertions are always TRUE, because I want them to be on the PASSED results in the report (I don't care much for failures in this case, only the data I get, and I rather it'd be under Passed results).
The test name is changed based on the received data.

Specifically the clip I sent shows that some tests have the same name, but some don't.
So, because some assertions have different names, the DataTable isn't built correctly?

[DannyDainton]

Not really sure what you're doing with the tests to be fair, I just don't see the point in not testing something but making it appear like everything is fine with it all "passing" 🤔

The expect line is quite redundant, you could just do this:

pm.test(`app ${applicationId}`);

Also, just to save confusion with using data files (it was previously accessed that way) I'd recommend changing the variable name of data to something like response.

If we think is something to do with the tests name you could just add a unique number in the test name to test the theory?

[yyahav]

I see... Ok let me explain a bit, so you can understand why I did it this way.

I have an App-Server structure, in which the server sends results based on info received from the app.
As team members sometimes need a "manual" calculation mechanism, to be able to achieve results by themselves, I set up a Postman collection that runs the same request as the app, and the parameters are manually entered in the csv by a team member, and I use your (simple to use yet beautiful 😍) html-extra-reporter to output the data from the server, which is the base to be later used by the team member when performing these manual calculations.

So basically it's not that I actually run automation iterations for Pass/Fail results, rather it's more of a "designed" way to output data to team members, excluding their need to actually parse through a response in Postman to find the data they need.

It's the fastest and most convenient solution I could think of, without having to develop a specific UI and tools for this matter.
And that's why I need to output the data in the test name.

Thanks for the redundancy tip, I removed them completely, and the data variable was entered just as an example of the test script... it's actually jsonData in the script itself 😁

I just ran another 2 tests now:

• Random numbers in the test names
• Test names without any numeric data, keeping the names equal through iterations

Both tests yielded the same results - second iteration show no Search nor Sort.
Tried opening the html in MS Edge and in Chrome, but it's the same.

My baking noodle is closing in on well-done... 😒

[DannyDainton]

Can you just send me the HTML file that gets created with the table like that, these static images are fine but it's not the report :D

[yyahav]

Yeah sorry :) here it is... had to rename to txt for uploading.
Test-2022-04-04-09-15-26-298-0.html.txt

[DannyDainton]

At least I can see it now :D

Leave it with me and I'll dig into it later table to see what's happening.

[DannyDainton]

@yyahav I've pushed that change into a new package and it should be available to grab now from npm.

[yyahav]

Great! thank you so much for your support and quick fix! 🙏 You're the 🤴
I installed the new package and tested - PASSED.
... and closed 😊

[DannyDainton]

I appreciate the patience and responses, we got there in the end. 😁

[yyahav]

Cheers mate!
What patience? that fix was lightning fast ⚡

[DannyDainton]

I'm usually quicker ;)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.