fix: automock apex methods with valid wire adapters

[jodarove]

This PR modifies the resolver so it automatically mocks apex methods with a valid wire adapter.

[pmdartus]

How does this relate to https://github.com/salesforce/lwc-test/blob/master/packages/%40lwc/jest-transformer/src/transforms/apex-scoped-import.js#L16-L72 ?

We do already transform those apex imports.

[pmdartus]

On top of my previous comment, we are also transforming @salesforce/apex/* import in the jest preset.

Before moving forward on this PR, I would like to better understand how this PR changes the LWC testing story. By automatically mocking wire adapters, all the components can be created without mocking the wire adapter. I am wondering if it is something that should be promoted.

As a test author, I want to be in control of mocking test dependencies. The is that I have with auto-mocking is that it gives a false sense of security to the test author.

/cc @trevor-bliss @ravijayaramappa

[jodarove]

@pmdartus :

I would like to better understand how this PR changes the LWC testing story.

Other than providing a valid apex adapter mock, it does not change the LWC testing story. Today we are automatically mocking apex wire adapters: in jest preset, and by replacing it in the @lwc/jest-preset.

By automatically mocking wire adapters, all the components can be created without mocking the wire adapter. I am wondering if it is something that should be promoted.

It is debatable but definitely something that is currently being promoted.

IMO, as a test author, if ill end up writing the same mock for every apex mock adapter that I create, ill say, let the testing framework automock them for me, and if I need to override a specific one, allow me to do so (test authors have it, via moduleNameMapper, etc.).

[ekashida]

Both perspectives have good points. Making the automocks opt-in would have been ideal for me but that ship has sailed...

I'm ok with this change since it's consistent with the current testing story.

[ravijayaramappa]

What I like about this approach:

• Moves the testing experience towards a consistent approach to mocking salesforce owned modules(wether it is lightning components or salesforce scoped modules)
• The mocking logic is simpler compared to have jest-transformer doing it

What I think we can do better:

• Move off of magically mocking dependencies as this pattern is not scalable. We would have to provide a mock for every new scoped module we add in the future to be consistent with the past.
• Mocking lightning/** modules is fine because salesforce controls the shape of these modules so we are at a better position to decide the functionality in the mocks. But Apex classes are customer authored, IMO the customer should make a conscious decision about writing the mocks.
  -- This way we also force them to adopt better coding practices, for example moving their data components higher in the component tree.
• Sprinkles the mocking facility between jest-transformer and this repo. But i guess this PR is the first step towards consolidating that. So IMO its fine as long as we stick to this repo in the future.

For practicality, I understand if you want to move forward with the current approach. That is fine IMO. Let's follow up with a user story to get this sorted out.