[Enterprise Search] Add Kea test helper for directly accessing listeners

[cee-chen]

Summary

Jason is a Kea guru by now and has started using breakpoints in listeners to help debounce calls.

Unfortunately, this adds some amount of async shenanigans to Jest unit tests when calling the listener via SomeLogic.actions.someListener.

Accessing the listener fn directly (rather than the wrapped action) makes async testing about easier or possible to catch errors/await breakpoints in the first place. Thus: this getListeners helper 👂

The actual implementation isn't too difficult (I originally just console logged the logic file until I got what I wanted, which was the listener fns), but pulling it out to a helper makes it little more reusable & readable.

Example usage:

const { mount, getListeners } = new LogicMounter(SomeLogic);

it('some test', async () => {
  mount();

  // If your specific listener doesn't depend on any values or actions, just do `getListeners()` w/o args
  const { someListener } = getListeners({
    values: { someMockValue: false },
    actions: { someMockAction: jest.fn() },
  });

  const mockBreakpoint = jest.fn();
  await someListener({ someMockArgument: true }, mockBreakpoint);
}); 

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[cee-chen]

@scottybollinger Sorry for the accidental assignment/ping, I originally shoved some extra organizational mocking stuff in this PR that touched WS files, but then realized I didn't need to / could work around it.

Just FYI you don't have to import LogicMounter directly from __mocks__/kea.mock btw, you can grab it straight from __mocks__ itself :)

[byronhulcher]

This seems like a better approach than getting these listeners ad-hoc in each logic file. Is it worth creating an issue in the main kea repo about this? This doesn't seem intuitive, and testing side effects for listeners is a valid use case, I'm surprised this is "the way" to do it.

[JasonStoltz]

@elasticmachine merge upstream

[JasonStoltz]

Testing listeners has been the source of more than a few lost development hours. This simplifies them greatly by simply allowing us to test them as plain old functions. This should let us crank out tests much quicker.

It's a slightly less realistic test overall because we're not invoking the listener as it would actually be invoked using Kea.

However, I think it's a reasonable tradeoff.

Thanks for doing this Constance!

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 2ac2774

Metrics [docs]

✅ unchanged

History

• 💚 Build #100532 succeeded f18af00

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[cee-chen]

@scottybollinger going to merge this PR in as-is, I'm thinking I'll use a separate helper for the things we chatted about today (mock breakpoint, invoke action for test coverage)