[Feature] Alert unit tests

[narin]

Description of Change

Adds the following unit tests for Alert:

• Check for rendering of header, description, children, buttons
• Verify colors for each variant in light and dark mode
• Expandable variants
• Analytics passthroughs

This PR also renames the testId prop in Alert to testID to be consistent the other components and fixes one of the Button tests to use queryByText instead of the async findByText.

Note: Moved accessibility tests to #279 since we'll want to configure jest matchers

Testing Packages

N/A

Screenshots/Video

Testing

N/A, they're unit tests

PR Checklist

Code reviewer validation:

• General
  • PR is linked to ticket(s)
  • PR has changelog label applied if it's to be included in the changelog
  • Acceptance criteria:
    • All satisfied or
    • Documented reason for not being performed or
    • Split to separate ticket and ticket is linked by relevant AC(s)
  • Above PR sections adequately filled out
  • If any breaking changes, in accordance with the pre-1.0.0 versioning guidelines: a CU ticket has been created for the VA Mobile App detailing necessary adjustments with the package version that will be published by this ticket
• Code
  • Tests are included if appropriate (or split to separate ticket)
  • New functions have proper TSDoc annotations

Publish

If changes warrant a new version per the versioning guidelines and the PR is approved and ready to merge:

• Merge main into branch
• Merge branch to main
• Verify that Check Component Integrations workflow ran successfully
• Publish new version after merging

[TimRoe]

Is there any harm in having things async even when they don't need to be?

With Link opted to have most async because I was getting confusing errors without it for some tests.

[narin]

I don't think so but we should avoid adding it if there's no async functions within. I think the errors might stem from some of the queries being async functions (e.g. findBy*) and some are not (queryBy*). When we add the jest matchers eslint plugin I think it provides some guidance on which ones should be used.

[TimRoe]

Dropping request changes to denote end of first pass--mostly just a few minor things for direct comments.

Non-direct comment: doesn't test accessibility. Seems like at a minimum should check header/description-a11yLabel overrides. Maybe should also check the icon scaling for the main icon and the chevron with its' unique behavior if we can do that around prior knowledge it renders everything at like 200% or whatever.

[narin]

Moved accessibility tests to be a part of #279. Ready for another round of review.