feat: IATR-M1.0 Debug Spec component update

[amehta265]

• Closes [IATR](M1.0) Failed Test Component Enhancements #24849

User facing changelog

This PR aims at updating the Debug Spec component and the Debug Failed component. It accomplishes the following:
It refurbishes the header section of the component to include a text icon and adds a specsMetadata section which provides more information about the spec duration, number of groups, browsers, operating systems, and testing types for the tests within the given spec.
In addition, the failed component section is now created to support multiple groupings for a given test and hover states for each test instance.

Additional details

The most important thing to understand is the data schema passed into debugSpec (the "parent" UI component for this PR). The debugSpec component receives the schema below from debugMapping.ts:

type CloudDebugSpec = {
  spec: DebugSpecListSpecFragment
  tests: { [thumbprint: string]: DebugSpecListTestsFragment[] }
  groups: { [groupId: string]: DebugSpecListGroupsFragment }
  testingType: TestingTypeEnum
  matchesCurrentTestingType: boolean
  foundLocally: boolean
}

• The spec is the current current spec that will be rendered by the debug Spec component.

• The tests are a mapping of thumbprints to the test represented by the thumbprint: A thumbprint is a unique hash associated with each test. If the same test is run for two different groups (e.g. Staging and Production) both tests will share the same thumbprint but will each have unique groupId pointing to the specific group each test is associated with e.g. {'unique1': [{...Test, grpId: '123'}, {...Test, grpId: '456'}] }. This is an example of two tests sharing the same thumbprint but each have unique instances as the test was run for different groups. On the other hand a test with a single group would look this: {'Unique1': [{Test}]}

• The groups are a mapping of groupID to their corresponding group e.g. ('123': {Staging}, '456': {Production}).

• Each test will have at least 1 group associated with it. In this case we render the single group UI. On the other hand if there is more than 1 group then we show the multiple groups UI.

• StatsMetadata.vue is a reusable component that helps render a list of items separated by "." It is used in the spec component header section as well as the grouped failed test section.

• LayeredBrowserIcons.vue is a component used to render multiple browsers in the header section of the component.

• GroupedDebugFailedTest.vue is a reusable component that is rendered every time there are multiple groups associated with the same test.

• DebugArtifacts.vue is a the component in charge of showing the hovered state icons

• For a better understanding refer to the images below:

Steps to test

This issue has 7 component tests: DebugArtifacts, DebugContainer, DebugFailedTest, DebugSpec, GroupedDebugFailedTest, LayeredBrowserIcons, StatsMetadata. Checkout to this branch to run the tests from the packages/app/ folder. To run these tests:

1. Change directory to packages/app
2. Run yarn dev
   Navigate to Component Testing and run the above tests

How has the user experience changed?

I have labeled different sections of the picture with file names to provide better understanding of which component is responsible for what UI.

Single Groups UI:

Multiple Groups UI:

PR Tasks

• Have tests been added/updated?
• Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• [na] Has a PR for user-facing changes been opened in cypress-documentation?
• [na] Have API changes been updated in the type definitions?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

26488 • 0 • 1180 • 0 • 27

---

Run details

Project	cypress
Status	Passed
Commit	c68fbcb
Started	Dec 30, 2022 9:31 PM
Ended	Dec 30, 2022 9:48 PM
Duration	17:43 💡
OS	Linux Debian -
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	create-from-component.cy.ts		1
1	... > runs generated spec
	commands/net_stubbing.cy.ts		4
1	network stubbing > intercepting request > can delay and throttle a StaticResponse
2	network stubbing > intercepting request > can delay and throttle a StaticResponse
3	network stubbing > intercepting request > can delay and throttle a StaticResponse
4	network stubbing > intercepting request > can delay and throttle a StaticResponse
This comment includes only the first 5 flaky tests. See all 27 flaky tests in the Cypress Dashboard.

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[lmiller1990]

Various comments, mainly

1. we can be more type safe, we can pair if you want to go over any of my comments
2. I think we should avoid ! - better to have a null check and be defensive. More verbose, but unless we are 100000% sure the property cannot be null/undefined, it's not worth the risk in production.

[warrensplayer]

Still working through other parts of the code, but wanted to share these comments.

The DebugSpecList component is missing some items needed to be passed down to the child components. The DebugSpecListSpec fragment is missing the specDuration field. In the specs computed value, all the information needed to be mapped in the return value for the spec portion are not there. I think you may be able to just spread the entire specItem.spec now and then override or add any other fields needed. Still looking at what might work.

[marktnoonan]

Noticed an opportunity here, we could grab the very similar looking code here and here to make a DebugArtifactLinkList component or something. We seem to have the idea of this component 3 places if you include this test, and the presence in the test tells me we want to see the artifact links grouped on their own like this.

[warrensplayer]

A few small things

[marktnoonan]

Is this TODO a style preference or is does it functionally make a difference to something? If you don't plan to make this change, we can remove the TODO and maybe leave a comment explaining. If it's an important change, we should make an issue and put the issue number in the TODO.

[warrensplayer]

@amehta265 I just realized that this is rendering all three buttons every time, but it should only render if the corresponding boolean value in the result is true and the url is present. I filed a separate issue to resolve this: #25319

[marktnoonan]

Going to approve as there are only small comments & we are going into a feature branch, I'll leave it up to you about which you implement.

In a general sense I think we can do more to label different content clearly for accessibility purposes and also to make the tests a bit easier to read . But I want to maybe come at that in a separate pass looking at this page as a whole a little further down the line.

[warrensplayer]

Looks super!