New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make wrapper to render configuration available at the global level #1222
Comments
While I'd normally recommend custom hooks, I see your point about difficulty refactoring. We're already considering a |
The solution here is a custom entrypoint instead of a configuration. The current ones are more subject to being really global but a wrapper really isn't. It's highly subjective to the kind of test and app you test and I don't believe this should automatically leak into all tests. Instead, stop importing from We keep this open for tracking but there is a high bar to implement this. "It's convenient" is not sufficient here. |
Yes, those are two sides of the same coin: On one hand:
On the other:
But, I reckon, as long as the global config is optional, you would be welcome to choose your own poison. However, I understand the complexity argument. |
Describe the feature you'd like:
When rendering components for test, I often find myself repeating
render(ui, { wrapper: TestApp() })
over and over again.It would be nice to have a possibility to define the wrapper using a global
configure(...)
call.By having this in global config, you could ensure that, by default, all the rendered components are tested in the context resembling the onion structure of various wrappers and context providers that they are going to be embedded in in production code anyway. This would help capture bugs when this context layer has an adverse effect on the behaviour of the component under test.
Describe alternatives you've considered:
You could of course define a custom function that does the same for you by wrapping the call to
render
. However, without the hindsight of defining one upfront, if you've already used the barebonesrender
in hundreds of tests before the need for a wrapper, you need to now refactor all of those tests :(Teachability, Documentation, Adoption, Migration Strategy:
No migration needed as this would be backwards-compatible in terms of the
configure
API.The text was updated successfully, but these errors were encountered: