Tests for SBOM Vulnerabilities Summary Panel

[mrrajan]

Added test for SBOM Explorer Vulnerabilities tab to verify the vulnerabilities count

• Validation for individual severity count
• Comparison for PieChart total value to individual severity counts

test-results.zip

[vobratil]

I've run this a couple of times against the non-AWS instance we're using right now and the tests act a little bit flaky. They fail inconsistently, typically with:

Call log:
      - waiting for getByLabel('Contents') to be detached


       at ../tests/ui/helpers/DetailsPage.ts:47

      45 |   async waitForData() {
      46 |     const spinner = this.page.getByLabel("Contents");
    > 47 |     await spinner.waitFor({ state: "detached" });
         |                   ^
      48 |   }
      49 |
      50 |   //Verifies the Page loads with data
        at DetailsPage.waitForData (/home/vobratil/Development/trustify-tests/tests/ui/helpers/DetailsPage.ts:47:19)
        at SearchPage.dedicatedSearch (/home/vobratil/Development/trustify-tests/tests/ui/helpers/SearchPage.ts:20:23)

Perhaps we should somehow increase the wait time, as it's likely to be longer on a "real" instance than a local one.

[mrrajan]

@vobratil The failure is unfortunate - I have tested this on a regular OCP environment before raising this PR and attached the traces with the description. you could check them with the comment npx playwright show-trace <path/to/traces.zip>.

However, The error appears to have been caused by the async call. I have addressed it now, so it should be working. . Please check and let me know.

[vobratil]

I re-ran the tests against one of our currently running instances and one of the tests was failing for me. I'm not sure if it has something to do with the bug mentioned on triage yesterday, but I've added some logging suggestions which could / should be applied generally across the PR.

[vobratil]

I've given it one more look and it looks good to me at this stage. In my opinion ready to merge.

[carlosthe19916]

@mrrajan I arrived late to the review. Yet I wanted to share my thoughts on this PR.
We can address my comments in future PRs. We are going to evolve iterating the code anyway :)

[carlosthe19916]

The <sbomType> is not used neither declared in the Examples section of the Scenario definition. I wonder if we should remove it.

[carlosthe19916]

Same as above, <sbomType> is not used nor needed.

[carlosthe19916]

the dedicatedSearch method receives a "string" that represents the page we want to see. I think the first parameter does not belong there. What about:

// Here we define that when we instantiate a Search Object we want to move the page to the SBOMs page.
const searchPage = new SearchPage(page, "SBOMs");
await searchPage.search("sbom_name");

[mrrajan]

Functionality wise, this wont make much difference. But, it makes sense for code maintenance and readability. I will try including this change as part of next PR.

[carlosthe19916]

I see many xpath selectors which by default is ok. But:

• We can decide to keep working with xpath OR
• We can also change certain parts of the UI's source code to make selection easier. E.g. in the past I faced a similar problem and I ended up adding aria selectors like in this PR https://github.com/trustification/trustify-ui/pull/313/files . Then use those aria selectors to avoid complex xpath selectors. As a bonus, the aria selectors are going to enrich the assistive technologies, such as screen readers in the UI.

[mrrajan]

In most of the conditions - I agree, we should consider aria-label or clean object selectors. But dynamic xpath's would be super helpful with reusable functions. For example, the pagination or per page selector validation dynamic xpath will be more useful. Let's consider where we can have dynamic xpath and static locators.