[htmlIdGenerator] testenv mock

[thompsongl]

Summary

Closes #1381 by providing a testenv mock for use in Jest environments (makeId was previously removed and not in use).
Added internal mocking to EUI and removed one-off component mocks from individual test files.

we could hash the stack trace - maybe removing the line numbers - to generate a consistent, yet unique, ID.

Explored this idea, but without line numbers the trace is not very helpful, and with numbers we run the risk of excessive snapshot churn. We can discuss here if something other than generated-id is better.

Checklist

- [ ] Check against all themes for compatibility in both light and dark modes
- [ ] Checked in mobile
- [ ] Checked in Chrome, Safari, Edge, and Firefox
- [ ] Props have proper autodocs
- [ ] Added documentation
- [ ] Checked Code Sandbox works for the any docs examples

• Added or updated jest tests'

- [ ] Checked for breaking changes and labeled appropriately
- [ ] Checked for accessibility including keyboard-only and screenreader modes

• A changelog entry exists and is marked appropriately

[myasonik]

Just to make sure, I noticed that in the a11y test where we need the unique IDs, you call requireActual to get it all to work. We'll be able to do the same in Kibana, right?

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4212/

[thompsongl]

you call requireActual to get it all to work. We'll be able to do the same in Kibana, right?

Thanks for bringing this up. Testing in Kibana highlights that moduleNameMapper (the method by which EUI is mocked) will also be used when jest.requireActual is called, meaning that we cannot get the original, unmocked function like we do in EUI test suite. We can, however, still overwrite the mock with a new mock.
Given that there does appear to be one non-shapshot Jest test in Kibana that relies on htmlIdGenerator returning unique values, we should address requireActual.

I have a solution in mind: add a second parameter on the testenv version that calls uuid rather than statically define generated-id. This this, we could re-mock the function, providing the second parameter, getting the standard output. This would not be common practice.

As in:

jest.mock('@elastic/eui/lib/services/accessibility/html_id_generator', () => {
  const { htmlIdGenerator } = jest.requireActual(
    '@elastic/eui/lib/services/accessibility/html_id_generator'
  );
  return { htmlIdGenerator: () => htmlIdGenerator('', true) };
});

[chandlerprall]

As that requires re-mocking the generator anyway, might be cleaner to let the mock do its own thing instead of building that extra support into the shipped mock?

[thompsongl]

might be cleaner to let the mock do its own thing instead

I'm good with this approach, also. What do you think, @myasonik?

[myasonik]

Seems good to me!

[thompsongl]

Because we're in agreement on not adding more to the mock, this is ready for review.

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4212/

[chandlerprall]

Changes LGTM!

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4212/