Add recommendation for asserting literal values over imported variables

What does this MR do and why?

Based on slack discussion here (internal link)

Add recommendation to the frontend testing guidelines that we should prefer to assert literal values in our tests over matching against an imported constant or variable.

This is because subtle problems could get past our tests when asserting against variables/consts. These are already discussed in our i18n handbook page: https://docs.gitlab.com/ee/development/i18n/externalization.html#recommendations

Another practice to avoid when exporting copy strings is to import them in specs. While it might seem like a much more efficient test (if we change the copy, the test will still pass!) it creates additional problems:

• There is a risk that the value we import is undefined and we might get a false-positive in our tests (even more so if we import an i18n object, see export constants as primitives).
• It is harder to know what we are testing (which copy to expect).
• There is a higher risk of typos being missed because we are not re-writing the assertion, but assuming that the value of our constant is the correct one.
• The benefit of this approach is minor. Updating the copy in our component and not updating specs is not a big enough benefit to outweigh the potential issues.

References

Please include cross links to any resources that are relevant to this MR. This will give reviewers and future readers helpful context to give an efficient review of the changes introduced.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.