Update testing section #1374
Update testing section #1374
Conversation
✅ Deploy Preview for react-navigation-docs ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| screens = Object.create( | ||
| Object.getPrototypeOf(screens), | ||
| Object.getOwnPropertyDescriptors(screens) | ||
| ); | ||
|
|
||
| return screens; |
There was a problem hiding this comment.
We are missing here example of actual mock of some component from react-native-screens. Try to mock Screen as a View for example.
There was a problem hiding this comment.
Thanks for the PR!
I think the current examples showcasing different navigation methods aren't the best examples to use here. The important thing to note that this documentation is for users of the library. These tests showing how different navigation methods work isn't what the user will need. Our docs should be more focused on what users need.
Similarly, the fake timers examples are generic fake timer example code. The idea is to demonstrate why it maybe necessary in some cases when writing tests for navigation code (e.g. it's necessary in case of JS stack navigator because navigating triggers an animation, so with fake timers, we can instantly skip the animation for testing).
Here are some examples:
- Navigating to a screen and asserting that the new screen content is rendered.
- By pressing a button
- By pressing tabs on a tab bar
- By pressing drawer item
- Testing app's functionality when using various hooks from React Navigation
- Check if correct content is rendered when screen is focused and unfocused (using
useIsFocusedhook) - Check if data is fetched/a side effect is performed when screen comes to focus (using
useFocusEffecthook)
- Check if correct content is rendered when screen is focused and unfocused (using
- Testing app's functionality with code in various events (e.g.
tabPress)
You can also think of more cases like this - specifically, what kind of tests you may write when building an app that involves navigation.
We should structure the docs in this way:
- Problem statement - example of a real-world case that the user may want to test
- Example code
- Explanation for the example code
- Explanation for any special code we may have done, e.g. we use fake timers to skip animations in JS stack navigators
| Reanimated.default.call = () => {}; | ||
|
|
||
| return Reanimated; | ||
| require('react-native-reanimated/mock'); |
There was a problem hiding this comment.
Seems we're missing a return statement
| const StackNavigation = createStaticNavigation(StackNavigator); | ||
| render(<StackNavigation />); | ||
|
|
||
| fireEvent.press(screen.queryByText('Go to Settings')); |
There was a problem hiding this comment.
Could you use getBy… instead of queryBy… when we expect that an element will be present on the screen, and use queryBy… only when we expect that an element won’t be available?
- This way, it will be clearer which elements we should expect to be visible or not.
- In case of an error,
getBy…will fail earlier thanqueryBy….
update testing with
jestsection:react-native-screens