Recommended way to debug failed tests and avoid mistakes beforehand when using hooks

[renefitzke]

Hello @rumax & community,

I'd like to have feedback or a discussion, which could possibly lead into a feature request.

We're about to refactor our app's screens from connect to hooks. With the connect approach, we had a clear interface for props the screen/component requires, including those from the redux store like selectors and actions to dispatch. That way we could easily identify props that were not provided to the screen while creating screenshot tests for it, because eslint warned us. But when using hooks like useSelector or useDispatch, these dependencies are no longer being handed to the component/screen as props, but called inside the component itself. So when creating screenshot tests for a component/screen, eslint will no longer tell us if something is missing. Mistakes are more likely to be made.

Unfortunately, pixels-catcher just skips tests that cannot be run, without providing a hint regarding the reason. So if a screen uses useSelector but no mock's been set up, the test is just being marked as "skipped", and you might have a hard time to find its reason.

Our question now is: Is there a recommended way or can you think of a good solution, that either prevents devs from forgetting to mock a dependency a screen has (like selectors and dispatchers) to minimize mistakes OR an (easy) way to get better feedback if a mistake has been made (especially when using the hooks API), so it's easier to debug?

Any ideas would be appreciated. Maybe other devs also faced this problem. Or is a feature that solves this problem possibly be planned?

Thanks a lot

[rumax]

Hi @renefitzke, when pixels-catcher skips the test it may be a crash which results in timeout. Solution can be:

• In case of CI, check logs to see which test fails. Additionaly you can do what I did in demo project https://github.com/rumax/react-native-PixelsCatcher/blob/master/azure-pipelines.yml#L46, which allows to see the entire log. But cannot say it is an easy way and I do not use it often.
• Check which test is skipped/fails and do only one run of this test. In our production apps we use special mechanism where we are able to debug each test separately, just like you debug the application. So run only one test. Lets say in demo project I define all tests https://github.com/rumax/react-native-PixelsCatcher/blob/master/demo/indexSnapshot.js, what I can do is comment all tests and keep active only one that I need to refactor.

[renefitzke]

Hi @renefitzke, when pixels-catcher skips the test it may be a crash which results in timeout. Solution can be:

* In case of CI, check logs to see which test fails. Additionaly you can do what I did in demo project https://github.com/rumax/react-native-PixelsCatcher/blob/master/azure-pipelines.yml#L46, which allows to see the entire log. But cannot say it is an easy way and I do not use it often.

* Check which test is skipped/fails and do only one run of this test. In our production apps we use special mechanism where we are able to debug each test separately, just like you debug the application. So run only one test. Lets say in demo project I define all tests https://github.com/rumax/react-native-PixelsCatcher/blob/master/demo/indexSnapshot.js, what I can do is comment all tests and keep active only one that I need to refactor.

The ios_logs.log you publish in your azure pipeline can actually help to identify issues like missing mocks for hooks a component uses. Thanks for pointing this out! In case of a missing mock for the navigation, which is called with useNavigation() from react-navigation in the component, it outputs

...
2022-09-15 14:05:42.170246+0200 0x26d1f    Error       0x0                  8084   0    AppName [com.facebook.react.log:javascript] Error: Couldn't find a navigation object. Is your component inside NavigationContainer?

This error is located at:
    in ScreenName
...

Which is very helpful.

But

1. I'm not sure if the log is this precise for every error that can lead to a "skip", I will need to test this a little more
2. These lines are buried deep in the log file, so it might be difficult to find them

We will try to make use of this log file, but it would be really handy if the console log would at least also output and point at this as the test fails, to make life easier

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.