React Facade: Dependency injection for React hooks
1–5 of 5 posts
Re: React Facade: Dependency injection for React hooks
#2I'm not sure I see the benefits here. Given you're already testing your hooks, as is assumed in the guide, what benefit does this approach have over mocking the hook for component tests?
Re: React Facade: Dependency injection for React hooks
#3I'm not sure I see the benefits here. Given you're already testing your hooks, as is assumed in the guide, what benefit does this approach have over mocking the hook for component tests?
Yeah that’s fair. Not sure about you, but in the past I’ve struggled with keeping Jest module-level mocks in sync with their actual interface. Was playing around with how I could get around it and this is something I came up with.
Re: React Facade: Dependency injection for React hooks
#4I'm not sure I see the benefits here. Given you're already testing your hooks, as is assumed in the guide, what benefit does this approach have over mocking the hook for component tests?
Yeah that’s fair. Not sure about you, but in the past I’ve struggled with keeping Jest module-level mocks in sync with their actual interface. Was playing around with how I could get around it and this is something I came up with.
Keeping mocks and tests in general up to date with reality can be tricky for sure. One thing that works very well for me, since you're using Typescript, is to use the ReturnType [0] generic to make sure the mock matches up to the actual implementation.
[0] https://www.typescriptlang.org/docs/handbook/utility-types.h...
Re: React Facade: Dependency injection for React hooks
#5Earlier quoted context omitted.
Yeah that’s fair. Not sure about you, but in the past I’ve struggled with keeping Jest module-level mocks in sync with their actual interface. Was playing around with how I could get around it and this is something I came up with.
Keeping mocks and tests in general up to date with reality can be tricky for sure. One thing that works very well for me, since you're using Typescript, is to use the ReturnType [0] generic to make sure the mock matches up to the actual implementation. [0] https://www.typescriptlang.org/docs/handbook/utility-types.h...
I think this suggestion highlights why I'm not a fan of the module-level mocking approach. It puts the onus on the developer to ensure that type checks are present where they wouldn't otherwise be. On larger teams, I've found that stuff like that is too easy to forget about or choose not to do.