Hi! 👋 Thanks for taking the time to put this together!

What I usually do is I create my "own" render method with the desired configuration, and then use it instead of the one coming from VTL. In the docs we have this example using React Testing Library, but the same idea still applies.

Would that suit your needs? I'd really like to stick to that pattern instead of increasing the API of the library, so that it stays simpler and more aligned with other libraries from the testing-library ecosystem.

We might want to document that Custom render method more prominently, though!

Hi @afontcu

thanks for your reaction :) I understand that you don't want to increase the API of the library, even though I will then need to copy/share the pattern with the composeConfigurationCallbacks manually between projects.

If you'd like I can change the MR to just adding examples. I'd then propose to add a shared-setup.js (naming ?) example in which:

• a "test-utils.js" provides a customRender function (with changed API / default options) as well as the composeConfigurationCallbacks function
• use cases can be shown for the customRender function
• use cases can be shown for composition with the original render function

What do you think?

Sure! For the time being I'd feel more comfortable with adding some examples on how to customise the render method. I'd start with a basic example (something simple such as adding i18n to all tests, or a common dependency)

Thanks for this! 🙌

completely forget about this MR 👀.

To me, wrapping the render method adds opacity, as it hides which dependencies the tested component actually has, but I'll finally close this MR ;)