Hey Michael - thanks so much for responding to the post :) I love your library - it must have taken ages to work out all of the edge cases for running hooks within a dummy environment. How long did it take you to come out with a stable release?
Also, what do you think of my opinions about how hooks should be tested? Do you have any alternative suggestions/thoughts?
If you ever find yourself in London, hit me up - I definitely owe you a beer 🍺
How long did it take you to come out with a stable release?
Good question. The API was more or less stable after about 3 months, but I made a lot of internal changes for another 3 or so months after that. I felt like we were out of alpha versions and ready for a v1 release about 8 months after the first release.
To be clear though, a lot of the complexity came from trying to support more use cases such as async state updates and suspense. If you have a basic hook, the component could simplified a lot.
Also, what do you think of my opinions about how hooks should be tested?
Obviously I'm a little baised in thinking that it can be very useful to test hooks in isolation. Kent C. Dodds (author of react-testing-library and react testing advocate) will tell you that testing the components is the best way, and in many ways I agree with him, especially his points about testing implementation details, but I do think that some complex hooks, especially those that rely on useEffect can get complicated to test through a component (I bet there are lots of people that aren't unmounting their components to test that their effects get cleaned up correctly).
One of the great features of custom hooks is that they can hide away a tonne of complexity behind a simple API for the component to consume. When you test through the component, it's easy to miss those edge cases, especially when the component is consuming multiple complex custom hooks and passing values between them.
At the end of the day, testing is all about confidence. You do as much or as little as you need to to be confident your code works. If testing the hook separately gives you that, then my opinion is that you should do it.
Do you have any alternative suggestions/thoughts?
Personally, I find mocking out things like a Redux store to be a bit futile sometimes. You can just as easily create a real store (or just import your apps own store) and assert the resulting state from the dispatched actions. You can add a Provider using the wrapper option of renderHook (example).
Admittedly, this crosses the line from unit test to integration test, but it will often result in tests that break less often when refactoring the code.
If you ever find yourself in London, hit me up - I definitely owe you a beer 🍺
Cheers mate! If you find yourself in Melbourne, I'll let you buy me a beer here too 😉
Thanks so much for the in-depth response. It's very cool getting to discuss this stuff with you.
(I bet there are lots of people that aren't unmounting their components to test that their effects get cleaned up correctly).
One of the great features of custom hooks is that they can hide away a tonne of complexity behind a simple API for the component to consume. When you test through the component, it's easy to miss those edge cases, especially when the component is consuming multiple complex custom hooks and passing values between them.
Couldn't agree more about this!
Personally, I find mocking out things like a Redux store to be a bit futile sometimes.
Me too - I'm trying to find something that exists to make life a bit easier when it comes to either mocking the Redux store for tests or just a nice pattern that allows people to use a provider in their tests (not just when it comes to testing hooks)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey, author or react-hooks-testing-library here...
I'm so sorry!
Seriously though, I'm really glad you liked it 😃
Hey Michael - thanks so much for responding to the post :) I love your library - it must have taken ages to work out all of the edge cases for running hooks within a dummy environment. How long did it take you to come out with a stable release?
Also, what do you think of my opinions about how hooks should be tested? Do you have any alternative suggestions/thoughts?
If you ever find yourself in London, hit me up - I definitely owe you a beer 🍺
Good question. The API was more or less stable after about 3 months, but I made a lot of internal changes for another 3 or so months after that. I felt like we were out of alpha versions and ready for a v1 release about 8 months after the first release.
To be clear though, a lot of the complexity came from trying to support more use cases such as async state updates and suspense. If you have a basic hook, the component could simplified a lot.
Obviously I'm a little baised in thinking that it can be very useful to test hooks in isolation. Kent C. Dodds (author of react-testing-library and react testing advocate) will tell you that testing the components is the best way, and in many ways I agree with him, especially his points about testing implementation details, but I do think that some complex hooks, especially those that rely on
useEffectcan get complicated to test through a component (I bet there are lots of people that aren't unmounting their components to test that their effects get cleaned up correctly).One of the great features of custom hooks is that they can hide away a tonne of complexity behind a simple API for the component to consume. When you test through the component, it's easy to miss those edge cases, especially when the component is consuming multiple complex custom hooks and passing values between them.
At the end of the day, testing is all about confidence. You do as much or as little as you need to to be confident your code works. If testing the hook separately gives you that, then my opinion is that you should do it.
Personally, I find mocking out things like a Redux store to be a bit futile sometimes. You can just as easily create a real store (or just import your apps own store) and assert the resulting state from the dispatched actions. You can add a
Providerusing thewrapperoption ofrenderHook(example).Admittedly, this crosses the line from unit test to integration test, but it will often result in tests that break less often when refactoring the code.
Cheers mate! If you find yourself in Melbourne, I'll let you buy me a beer here too 😉
Thanks so much for the in-depth response. It's very cool getting to discuss this stuff with you.
Couldn't agree more about this!
Me too - I'm trying to find something that exists to make life a bit easier when it comes to either mocking the Redux store for tests or just a nice pattern that allows people to use a provider in their tests (not just when it comes to testing hooks)