You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: versioned_docs/version-7.x/testing.md
+46-47Lines changed: 46 additions & 47 deletions
Original file line number
Diff line number
Diff line change
@@ -215,14 +215,28 @@ test('navigates to settings by tab bar button press', async () => {
215
215
</TabItem>
216
216
</Tabs>
217
217
218
-
We get the settings tab bar button using a `testID` assigned to it, press it using `fireEvent` and check if rendered content is correct.
218
+
First, we need to create a User Event object instance from `react-native-testing-library` in order to be able to trigger user events.
219
219
220
-
Tab bar buttons `handlePress` function expects to receive `GestureResponderEvent`. To avoid error you should pass `event` object as the second argument of `fireEvent`.
220
+
```js
221
+
// Create User Event object instance
222
+
constuser=userEvent.setup();
223
+
```
224
+
225
+
After we create and render our tabs, we get the settings tab bar button using an accessibility label assigned to it and press it using `user.press(button)`.
226
+
227
+
```js
228
+
// Get the setting tab bar button
229
+
constbutton=screen.getByRole('button', { name:'Settings, tab, 2 of 2' });
230
+
231
+
// Simulate user pressing the button
232
+
awaituser.press(button);
233
+
```
234
+
235
+
We expect that after pressing the button, the screen will change and `'Settings screen'` will be visible.
@@ -382,9 +396,9 @@ test('surprise text appears after transition to surprise screen is complete', as
382
396
</TabItem>
383
397
</Tabs>
384
398
385
-
We press the "Click here!" button using `fireEvent` and check that the text does not appear right away but only after the transition between screens ends.
399
+
We press the "Click here!" button using `user.press()` and check that the text does not appear right away but only after the transition between screens ends.
386
400
387
-
While writing tests containing navigation with animations (in this example we have a `StackNavigator`, which uses an animation for the transition based on the platform and OS version) you need to wait until animations finish before proceeding further. To do so, you have to use `fake timers`. [`Fake Timers`](https://jestjs.io/docs/timer-mocks) replace real implementation of times function to use fake clock. They allow you to instantly skip animation time. To avoid getting state change error, wrap `runAllTimers` in `act`.
401
+
<!-- When writing tests containing navigation with animations (in this example we have a `StackNavigator`, which uses an animation for the transition based on the platform and OS version) you need to wait until animations finish before proceeding further. To do so, you have to use `fake timers`. [`Fake Timers`](https://jestjs.io/docs/timer-mocks) replace real implementation of times function to use fake clock. They allow you to instantly skip animation time. To avoid getting state change error, wrap `runAllTimers` in `act`.
If we hadn't used fake timers in this example, the test would have failed.
401
415
402
-
In the previous example we didn't use fake timers because `BottomTabNavigator` by default does not use any transition animations.
416
+
In the previous example we didn't use fake timers because `BottomTabNavigator` by default does not use any transition animations.-->
403
417
404
418
### Example 3 - Enforce navigator state in response to navigation event
405
419
@@ -632,13 +646,13 @@ test('displays settings screen after settings tab bar button press', async () =>
632
646
</TabItem>
633
647
</Tabs>
634
648
635
-
We get tab bar buttons, press buttons and check if rendered screens are correct.
649
+
We get tab bar buttons, press them and check if rendered screens are correct.
636
650
637
-
In this example, we don't need to use fake timers because text from the next screen is available using `getByText` even before the animation ends.
651
+
<!--In this example, we don't need to use fake timers because text from the next screen is available using `getByText` even before the animation ends.-->
638
652
639
653
### Example 4 - `useFocusEffect` hook and data fetching
640
654
641
-
On every profile screen focus, display loading state while waiting for data and then show fetched profile.
655
+
On profile screen focus, display loading state while waiting for data and then show fetched profile on every refocus.
642
656
643
657
<TabsgroupId="example"queryString="example">
644
658
<TabItemvalue="static"label="Static"default>
@@ -816,6 +830,25 @@ export function MyTabs() {
816
830
</TabItem>
817
831
</Tabs>
818
832
833
+
To make the test deterministic and isolate it from the real backend, you can mock the `fetch` function. For this purpose you can use [Mock Service Worker](https://mswjs.io/). Please refer to the documentation of the library to learn more about setting it up in your project ([Getting started](https://mswjs.io/docs/getting-started), [React Native integration](https://mswjs.io/docs/integrations/react-native)).
Before writing the test, we setup a handler that mocks responses from the API (for this example we're using [PokéAPI](https://pokeapi.co/)). Additionally, we `delay` the response by 1000 ms.
851
+
819
852
<TabsgroupId="example"queryString="example">
820
853
<TabItemvalue="static"label="Static"default>
821
854
@@ -908,41 +941,7 @@ test('on profile screen focus, displays loading state while waiting for data and
908
941
</TabItem>
909
942
</Tabs>
910
943
911
-
We query tab buttons and mock fetch function using `spyOn` and `mockImplementation`. We navigate to profile screen and check if loading state is rendered correctly. Then, to check if fetched data is displayed, we use `findByText` - we need to wait for the fetch to finish before checking its result. To ensure that operation will succeed not only on the first focus, we navigate back to home, then to settings and check loading state and fetched data again.
912
-
913
-
To make test deterministic and isolate it from the real backend you can mock fetch function. You can use `spyOn` to override real implementation of fetch with `mockedFetch`.
914
-
915
-
```js
916
-
// Mock implementation of fetch function
917
-
asyncfunctionmockedFetch() {
918
-
constmockResponse= {
919
-
profile: {
920
-
nick:'CookieDough',
921
-
},
922
-
};
923
-
return {
924
-
ok:true,
925
-
status:200,
926
-
json:async () => {
927
-
return mockResponse;
928
-
},
929
-
};
930
-
}
931
-
932
-
test('on every profile screen focus, displays loading state while waiting for data and then shows fetched profile', async () => {
We navigate to profile screen and check if loading state is rendered correctly. Then we use fake timers to skip the delay and check if fetched data is displayed on the screen. To ensure expected behavior not only on the first focus, we navigate back to home, then to settings and check that the data is present without unnecessary fetch.
0 commit comments