Link test case, bug, documentation to the test

[QuasiQA]

Problem:

1. Usually autotests are based on manual test cases. So it will be great to have possibility see related test case and also have possibility to go directly to the test case in test management system (TMS) from the report.
2. Also sometimes tests may fail due to existing issue. So it will be great to have possibility see related bug and have possibility to go directly to the issue in bug tracking system (BTS) from the report.
3. Sometimes it's useful to have related documentation (DOC) to check something related to the API endpoint. E.g. swagger documentation will be useful, or confluence page with some description etc. So it will be great to have direct link from the test in report to the documentation So what I'm suggesting is to add links to corresponding items into the report:

Suggested solution details:

1. Add link html blocks to the report templates (screenshot above)
   • link block should be displayed only if the endpoint contains linked item (testcase, bug or doc)
   • if link pattern missed, display only item name (see suggested patterns below)

2.1. Item templates should be added at the beginning of the request name Template may have next structure: [:,,]

• TMS type used for test cases, e.g.: [TMS:C123][TMS:ISSUE-1513,C123]
• BTS type used for issues/bugs, e.g.: [BTS:edu-12,edu-37]
• DOC used for documentation, e.g.: [DOC:How%20create%20user]

2.2. Link patterns (Parameters):

• --reporter-htmlextra-tms [tms-pattern] | example of parameter "http//:jira.site.com/testcases/{}"
• --reporter-htmlextra-bts [bts-pattern] | example of parameter "http//:jira.site.com/issues/{}"
• --reporter-htmlextra-doc [doc-pattern] | example of parameter "http://confluence.site.com/workspace/{}/index.html" If specified, links will be added to the items. {} in pattern will be replaced with item from previous 2.1. paragraph

So the final result in the report will look like http://jira.site.com/testcases/C123

3. After parsing specified items may be deleted from the request name, so in report we will not see it:

[DannyDainton]

Is the image a mocked version of what you would like to see in the report or a template that you have created? I'd be happy to look at any PRs that you want to create.

Adding extra things in via the cli flags is the easy way to get non-Newman data into the report but it would need some processing in the reporter to know where that belongs or what request to add that too.

At the moment, I can only really add data points that you see in your Postman UI, to the reporter, if those data points are passed through Newman during the Collection run.

[QuasiQA]

The images are just mocked directly in browser, so no templates for them

Agree, this is the easiest way to add non-Newman functionality. This is exactly what I wanted to have - new functionality, related to the report, but not to the Postman/Newman. And to have it, I only can manage request names somehow (by adding templates like described), because there is no related postman UI functionality.

It makes sense to add whole related functionality together - with CLI parameters, templates and request name parser. But it makes no sense to add any of things separately.

So if it's impossible to add this, ticket may be closed. But if you just have no time to implement it, I may try to create the PR. It's just depends on if you gonna approve this or not

[DannyDainton]

If what you're adding helps more people rather than just solving your current use case then I would consider it.

This would involve changing the index.js file and all the templates in order to add something that might or might not be useful. Like I mentioned before, add a flag that will render something is easy but you're talking about quite contextual things and those need to be added to a certain part of the report. That part is not so easy.

This isn't something that I'm going to be spending time doing as it's making the report less generic as not everyone uses JIRA or a Test Case management too so it would be a series of hacky changes to cater for lots of different contexts.

[QuasiQA]

Yes you are right Danny I'll try to implement this changes with rendering that HTML part of report ONLY if the parameters are defined and naming template used in the request

[DannyDainton]

That's easy to do, I have places all over the template that do that in the request view based on certain things being there/not being there.

The trouble I see is that it's difficult to insert that data into say a single request in the collection, I haven't tried it yet but I can see it being tricky.

[DannyDainton]

I'm going to close this for now as it's not something I'm going to be working on.

Can reopen if I either get time to look at it or receive a PR 😁

[github-actions[bot]]

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.