🚧 Clipboard
-Deprecated. Use @react-native-community/clipboard instead.
+Deprecated. Use @react-native-community/clipboard instead.
Clipboard gives you an interface for setting and getting content from Clipboard on both Android and iOS
diff --git a/docs/next/clipboard/index.html b/docs/next/clipboard/index.html index 89047b942d6..a8398f579c0 100644 --- a/docs/next/clipboard/index.html +++ b/docs/next/clipboard/index.html @@ -1,4 +1,4 @@ -
🚧 Clipboard
-Deprecated. Use @react-native-community/clipboard instead.
+Deprecated. Use @react-native-community/clipboard instead.
Clipboard gives you an interface for setting and getting content from Clipboard on both Android and iOS
diff --git a/docs/next/intro-react.html b/docs/next/intro-react.html index 5c04eb0a4a0..16ebcabc0e4 100644 --- a/docs/next/intro-react.html +++ b/docs/next/intro-react.html @@ -120,7 +120,8 @@
Your component starts as a function:
function Cat() {}
Whatever a function component returns is rendered as a React element. Cat will render a <Text> element:
You can think of components as blueprints. Whatever a function component returns is rendered as a React element. React elements let you describe what you want to see on the screen.
+Here the Cat component will render a <Text> element:
function Cat() {
return <Text>Hello, I am your cat!</Text>;
}
diff --git a/docs/next/intro-react/index.html b/docs/next/intro-react/index.html
index 5c04eb0a4a0..16ebcabc0e4 100644
--- a/docs/next/intro-react/index.html
+++ b/docs/next/intro-react/index.html
@@ -120,7 +120,8 @@
Your component starts as a function:
function Cat() {}
-Whatever a function component returns is rendered as a React element. Cat will render a <Text> element:
+You can think of components as blueprints. Whatever a function component returns is rendered as a React element. React elements let you describe what you want to see on the screen.
+Here the Cat component will render a <Text> element:
function Cat() {
return <Text>Hello, I am your cat!</Text>;
}
diff --git a/docs/next/sectionlist.html b/docs/next/sectionlist.html
index 0905b516da7..316362257d5 100644
--- a/docs/next/sectionlist.html
+++ b/docs/next/sectionlist.html
@@ -83,81 +83,90 @@
If you don't need section support and want a simpler interface, use <FlatList>.
Example
-import React from 'react';
+
+
+ -
+ Function Component Example
+
+ -
+ Class Component Example
+
+
+
+
+import React from "react";
import {
StyleSheet,
Text,
View,
SafeAreaView,
- SectionList,
-} from 'react-native';
-import Constants from 'expo-constants';
+ SectionList
+} from "react-native";
+import Constants from "expo-constants";
const DATA = [
{
- title: 'Main dishes',
- data: ['Pizza', 'Burger', 'Risotto'],
+ title: "Main dishes",
+ data: ["Pizza", "Burger", "Risotto"]
},
{
- title: 'Sides',
- data: ['French Fries', 'Onion Rings', 'Fried Shrimps'],
+ title: "Sides",
+ data: ["French Fries", "Onion Rings", "Fried Shrimps"]
},
{
- title: 'Drinks',
- data: ['Water', 'Coke', 'Beer'],
+ title: "Drinks",
+ data: ["Water", "Coke", "Beer"]
},
{
- title: 'Desserts',
- data: ['Cheese Cake', 'Ice Cream'],
- },
+ title: "Desserts",
+ data: ["Cheese Cake", "Ice Cream"]
+ }
];
-function Item({ title }) {
- return (
- <View style={styles.item}>
- <Text style={styles.title}>{title}</Text>
- </View>
- );
-}
+const Item = ({ title }) => (
+ <View style={styles.item}>
+ <Text style={styles.title}>{title}</Text>
+ </View>
+);
-export default function App() {
- return (
- <SafeAreaView style={styles.container}>
- <SectionList
- sections={DATA}
- keyExtractor={(item, index) => item + index}
- renderItem={({ item }) => <Item title={item} />}
- renderSectionHeader={({ section: { title } }) => (
- <Text style={styles.header}>{title}</Text>
- )}
- />
- </SafeAreaView>
- );
-}
+const App = () => (
+ <SafeAreaView style={styles.container}>
+ <SectionList
+ sections={DATA}
+ keyExtractor={(item, index) => item + index}
+ renderItem={({ item }) => <Item title={item} />}
+ renderSectionHeader={({ section: { title } }) => (
+ <Text style={styles.header}>{title}</Text>
+ )}
+ />
+ </SafeAreaView>
+);
+
+export default App;
const styles = StyleSheet.create({
container: {
flex: 1,
marginTop: Constants.statusBarHeight,
- marginHorizontal: 16,
+ marginHorizontal: 16
},
item: {
- backgroundColor: '#f9c2ff',
+ backgroundColor: "#f9c2ff",
padding: 20,
- marginVertical: 8,
+ marginVertical: 8
},
header: {
fontSize: 32,
- backgroundColor: '#fff'
+ backgroundColor: "#fff"
},
title: {
- fontSize: 24,
- },
+ fontSize: 24
+ }
});
This is a convenience wrapper around <VirtualizedList>, and thus inherits its props (as well as those of <ScrollView> that aren't explicitly listed here, along with the following caveats:
+ >
import React, { Component } from "react";
+import {
+ StyleSheet,
+ Text,
+ View,
+ SafeAreaView,
+ SectionList
+} from "react-native";
+import Constants from "expo-constants";
+
+const DATA = [
+ {
+ title: "Main dishes",
+ data: ["Pizza", "Burger", "Risotto"]
+ },
+ {
+ title: "Sides",
+ data: ["French Fries", "Onion Rings", "Fried Shrimps"]
+ },
+ {
+ title: "Drinks",
+ data: ["Water", "Coke", "Beer"]
+ },
+ {
+ title: "Desserts",
+ data: ["Cheese Cake", "Ice Cream"]
+ }
+];
+
+Item = ({ title }) => (
+ <View style={styles.item}>
+ <Text style={styles.title}>{title}</Text>
+ </View>
+);
+
+class App extends Component {
+ render() {
+ return (
+ <SafeAreaView style={styles.container}>
+ <SectionList
+ sections={DATA}
+ keyExtractor={(item, index) => item + index}
+ renderItem={({ item }) => <Item title={item} />}
+ renderSectionHeader={({ section: { title } }) => (
+ <Text style={styles.header}>{title}</Text>
+ )}
+ />
+ </SafeAreaView>
+ );
+ }
+}
+
+export default App;
+
+const styles = StyleSheet.create({
+ container: {
+ flex: 1,
+ marginTop: Constants.statusBarHeight,
+ marginHorizontal: 16
+ },
+ item: {
+ backgroundColor: "#f9c2ff",
+ padding: 20,
+ marginVertical: 8
+ },
+ header: {
+ fontSize: 32,
+ backgroundColor: "#fff"
+ },
+ title: {
+ fontSize: 24
+ }
+});
+]
+This is a convenience wrapper around <VirtualizedList>, and thus inherits its props (as well as those of <ScrollView> that aren't explicitly listed here, along with the following caveats:
- Internal state is not preserved when content scrolls out of the render window. Make sure all your data is captured in the item data or external stores like Flux, Redux, or Relay.
- This is a
PureComponentwhich means that it will not re-render ifpropsremain shallow-equal. Make sure that everything yourrenderItemfunction depends on is passed as a prop (e.g.extraData) that is not===after updates, otherwise your UI may not update on changes. This includes thedataprop and parent component state.
diff --git a/docs/next/sectionlist/index.html b/docs/next/sectionlist/index.html
index 0905b516da7..316362257d5 100644
--- a/docs/next/sectionlist/index.html
+++ b/docs/next/sectionlist/index.html
@@ -83,81 +83,90 @@
If you don't need section support and want a simpler interface, use <FlatList>.
Example
-import React from 'react';
+
+
+ -
+ Function Component Example
+
+ -
+ Class Component Example
+
+
+
+
+import React from "react";
import {
StyleSheet,
Text,
View,
SafeAreaView,
- SectionList,
-} from 'react-native';
-import Constants from 'expo-constants';
+ SectionList
+} from "react-native";
+import Constants from "expo-constants";
const DATA = [
{
- title: 'Main dishes',
- data: ['Pizza', 'Burger', 'Risotto'],
+ title: "Main dishes",
+ data: ["Pizza", "Burger", "Risotto"]
},
{
- title: 'Sides',
- data: ['French Fries', 'Onion Rings', 'Fried Shrimps'],
+ title: "Sides",
+ data: ["French Fries", "Onion Rings", "Fried Shrimps"]
},
{
- title: 'Drinks',
- data: ['Water', 'Coke', 'Beer'],
+ title: "Drinks",
+ data: ["Water", "Coke", "Beer"]
},
{
- title: 'Desserts',
- data: ['Cheese Cake', 'Ice Cream'],
- },
+ title: "Desserts",
+ data: ["Cheese Cake", "Ice Cream"]
+ }
];
-function Item({ title }) {
- return (
- <View style={styles.item}>
- <Text style={styles.title}>{title}</Text>
- </View>
- );
-}
+const Item = ({ title }) => (
+ <View style={styles.item}>
+ <Text style={styles.title}>{title}</Text>
+ </View>
+);
-export default function App() {
- return (
- <SafeAreaView style={styles.container}>
- <SectionList
- sections={DATA}
- keyExtractor={(item, index) => item + index}
- renderItem={({ item }) => <Item title={item} />}
- renderSectionHeader={({ section: { title } }) => (
- <Text style={styles.header}>{title}</Text>
- )}
- />
- </SafeAreaView>
- );
-}
+const App = () => (
+ <SafeAreaView style={styles.container}>
+ <SectionList
+ sections={DATA}
+ keyExtractor={(item, index) => item + index}
+ renderItem={({ item }) => <Item title={item} />}
+ renderSectionHeader={({ section: { title } }) => (
+ <Text style={styles.header}>{title}</Text>
+ )}
+ />
+ </SafeAreaView>
+);
+
+export default App;
const styles = StyleSheet.create({
container: {
flex: 1,
marginTop: Constants.statusBarHeight,
- marginHorizontal: 16,
+ marginHorizontal: 16
},
item: {
- backgroundColor: '#f9c2ff',
+ backgroundColor: "#f9c2ff",
padding: 20,
- marginVertical: 8,
+ marginVertical: 8
},
header: {
fontSize: 32,
- backgroundColor: '#fff'
+ backgroundColor: "#fff"
},
title: {
- fontSize: 24,
- },
+ fontSize: 24
+ }
});
This is a convenience wrapper around <VirtualizedList>, and thus inherits its props (as well as those of <ScrollView> that aren't explicitly listed here, along with the following caveats:
+ >import React, { Component } from "react";
+import {
+ StyleSheet,
+ Text,
+ View,
+ SafeAreaView,
+ SectionList
+} from "react-native";
+import Constants from "expo-constants";
+
+const DATA = [
+ {
+ title: "Main dishes",
+ data: ["Pizza", "Burger", "Risotto"]
+ },
+ {
+ title: "Sides",
+ data: ["French Fries", "Onion Rings", "Fried Shrimps"]
+ },
+ {
+ title: "Drinks",
+ data: ["Water", "Coke", "Beer"]
+ },
+ {
+ title: "Desserts",
+ data: ["Cheese Cake", "Ice Cream"]
+ }
+];
+
+Item = ({ title }) => (
+ <View style={styles.item}>
+ <Text style={styles.title}>{title}</Text>
+ </View>
+);
+
+class App extends Component {
+ render() {
+ return (
+ <SafeAreaView style={styles.container}>
+ <SectionList
+ sections={DATA}
+ keyExtractor={(item, index) => item + index}
+ renderItem={({ item }) => <Item title={item} />}
+ renderSectionHeader={({ section: { title } }) => (
+ <Text style={styles.header}>{title}</Text>
+ )}
+ />
+ </SafeAreaView>
+ );
+ }
+}
+
+export default App;
+
+const styles = StyleSheet.create({
+ container: {
+ flex: 1,
+ marginTop: Constants.statusBarHeight,
+ marginHorizontal: 16
+ },
+ item: {
+ backgroundColor: "#f9c2ff",
+ padding: 20,
+ marginVertical: 8
+ },
+ header: {
+ fontSize: 32,
+ backgroundColor: "#fff"
+ },
+ title: {
+ fontSize: 24
+ }
+});
+]
+This is a convenience wrapper around <VirtualizedList>, and thus inherits its props (as well as those of <ScrollView> that aren't explicitly listed here, along with the following caveats:
- Internal state is not preserved when content scrolls out of the render window. Make sure all your data is captured in the item data or external stores like Flux, Redux, or Relay.
- This is a
PureComponentwhich means that it will not re-render ifpropsremain shallow-equal. Make sure that everything yourrenderItemfunction depends on is passed as a prop (e.g.extraData) that is not===after updates, otherwise your UI may not update on changes. This includes thedataprop and parent component state.
diff --git a/docs/next/style.html b/docs/next/style.html
index de3a280fb62..6d90f4dc783 100644
--- a/docs/next/style.html
+++ b/docs/next/style.html
@@ -71,10 +71,13 @@
Style
With React Native, you style your application using JavaScript. All of the core components accept a prop named style. The style names and values usually match how CSS works on the web, except names are written using camel casing, e.g. backgroundColor rather than background-color.
The style prop can be a plain old JavaScript object. That's what we usually use for example code. You can also pass an array of styles - the last style in the array has precedence, so you can use this to inherit styles.
As a component grows in complexity, it is often cleaner to use StyleSheet.create to define several styles in one place. Here's an example:
import React, { Component } from 'react';
+import React from 'react';
import { StyleSheet, Text, View } from 'react-native';
const styles = StyleSheet.create({
+ container: {
+ marginTop: 50,
+ },
bigBlue: {
color: 'blue',
fontWeight: 'bold',
@@ -85,22 +88,20 @@
},
});
-export default class LotsOfStyles extends Component {
- render() {
+export default LotsOfStyles = () => {
return (
- <View>
+ <View style={styles.container}>
<Text style={styles.red}>just red</Text>
<Text style={styles.bigBlue}>just bigBlue</Text>
<Text style={[styles.bigBlue, styles.red]}>bigBlue, then red</Text>
<Text style={[styles.red, styles.bigBlue]}>red, then bigBlue</Text>
</View>
);
- }
}
EditStyle
With React Native, you style your application using JavaScript. All of the core components accept a prop named style. The style names and values usually match how CSS works on the web, except names are written using camel casing, e.g. backgroundColor rather than background-color.
The style prop can be a plain old JavaScript object. That's what we usually use for example code. You can also pass an array of styles - the last style in the array has precedence, so you can use this to inherit styles.
As a component grows in complexity, it is often cleaner to use StyleSheet.create to define several styles in one place. Here's an example:
-import React, { Component } from 'react';
+import React from 'react';
import { StyleSheet, Text, View } from 'react-native';
const styles = StyleSheet.create({
+ container: {
+ marginTop: 50,
+ },
bigBlue: {
color: 'blue',
fontWeight: 'bold',
@@ -85,22 +88,20 @@
},
});
-export default class LotsOfStyles extends Component {
- render() {
+export default LotsOfStyles = () => {
return (
- <View>
+ <View style={styles.container}>
<Text style={styles.red}>just red</Text>
<Text style={styles.bigBlue}>just bigBlue</Text>
<Text style={[styles.bigBlue, styles.red]}>bigBlue, then red</Text>
<Text style={[styles.red, styles.bigBlue]}>red, then bigBlue</Text>
</View>
);
- }
}
Testing · React Native EditTesting
As your codebase expands, small errors and edge cases you don’t expect can cascade into larger failures. Bugs lead to bad user experience and ultimately, business losses. One way to prevent fragile programming is to test your code before releasing it into the wild.
-In this guide, we will cover different (automated) ways to ensure your app works as expected, ranging from static analysis to end-to-end tests.
+In this guide, we will cover different, automated ways to ensure your app works as expected, ranging from static analysis to end-to-end tests.
+
Why Test
-We're humans and we make mistakes. Testing is important because it proves that your code is working, and perhaps even more importantly, ensures that your code continues to work in the future as you add new features, refactor the existing ones, or after you upgrade major dependencies of your project.
-There is more value in testing, that perhaps isn't immediately visible: when there is a bug in your code, often the easiest way to fix it is to write a failing test that exposes the bug - then when you fix the bug in your code and re-run the test, it'll pass, meaning the bug is fixed and is never reintroduced into the code base.
-Tests can also serve as documentation for new people joining your team - when they have to use code they have never seen before, reading tests can greatly help them to understand how the existing code is intended to be used. Last but not least, more automated testing means less time spent with manual QA.
+We're humans, and humans make mistakes. Testing is important because it helps you uncover these mistakes or verifies that your code is working. Perhaps even more importantly, testing ensures that your code continues to work in the future as you add new features, refactor the existing ones, or upgrade major dependencies of your project.
+There is more value in testing than you might realize. One of the best ways to fix a bug in your code is to write a failing test that exposes it. Then when you fix the bug and re-run the test, if it passes it means the bug is fixed, never reintroduced into the code base.
+Tests can also serve as documentation for new people joining your team. For people who have never seen a codebase before, reading tests can help them understand how the existing code works.
+Last but not least, more automated testing means less time spent with manual QA, freeing up valuable development time.
Static Analysis
The first step to improve your code quality is to start using static analysis tools. Static analysis checks your code for errors as you write it, but without running any of that code.
-- Linters analyze code to catch common errors, such as unused code, help avoid pitfalls or flag style guide no-nos like using tabs instead of spaces (or vice versa, depending on your configuration). Linters are configured by a set of rules - and your code needs to follow them.
+- Linters analyze code to catch common errors such as unused code and to help avoid pitfalls, to flag style guide no-nos like using tabs instead of spaces (or vice versa, depending on your configuration).
- Type checking ensures that the construct you’re passing to a function matches what the function was designed to accept, preventing passing a string to a counting function that expects a number, for instance.
-React Native comes with two such tools configured out of the box: ESLint for linting and Flow for type checking. You can also use TypeScript, which is a typed language that compiles to plain JavaScript.
+React Native comes with two such tools configured out of the box: ESLint for linting and Flow for type checking. You can also use TypeScript, which is a typed language that compiles to plain JavaScript.
Writing Testable Code
-To start with tests, you first need to write code that is testable. Consider an aircraft manufacturing process - before any model first takes off to show that all of its complex systems work well together, individual parts are tested to guarantee they are safe and function correctly. For example, wings are tested by bending them under extreme load, engine parts are tested for their durability, windshield is tested against simulated bird impact, and much more.
-Similarly, with software, as opposed to writing your entire program in one huge file with many lines of code, writing your code in multiple small modules that you can test is more effective. In this way, writing testable code is intertwined with writing clean, modular code.
-To help make your app more testable, it’s a good idea to separate the view part of your app, React components, from business logic and app state (regardless of whether you use Redux, MobX or other solutions). This way, you can separate tests of your business logic — which shouldn’t rely on your React components — from the components themselves, whose job is primarily rendering your app’s UI!
-Theoretically, you could go so far as to move all logic and data fetching out of your components. This way your components would be solely dedicated to rendering, and your state would be independent on your components - your app’s logic would work without any React components at all!
-After writing testable code, it’s time to write some actual tests! (Or if you do test-driven development, you actually write tests first! That way, testability of your code is given.). We encourage you to explore the topic of testability in other learning resources.
-The default template of React Native ships with Jest testing framework. It includes a preset that's tailored to this environment so you can get productive without tweaking the configuration and mocks straight away. You can use Jest to write all types of tests featured in this guide. Let’s get started!
+To start with tests, you first need to write code that is testable. Consider an aircraft manufacturing process - before any model first takes off to show that all of its complex systems work well together, individual parts are tested to guarantee they are safe and function correctly. For example, wings are tested by bending them under extreme load; engine parts are tested for their durability; the windshield is tested against simulated bird impact.
+Software is similar. Instead of writing your entire program in one huge file with many lines of code, you write your code in multiple small modules that you can test more thoroughly than if you tested the assembled whole. In this way, writing testable code is intertwined with writing clean, modular code.
+To make your app more testable, start by separating the view part of your app—your React components—from your business logic and app state (regardless of whether you use Redux, MobX or other solutions). This way, you can keep your business logic testing—which shouldn’t rely on your React components—independent of the components themselves, whose job is primarily rendering your app’s UI!
+Theoretically, you could go so far as to move all logic and data fetching out of your components. This way your components would be solely dedicated to rendering. Your state would be entirely independent of your components. Your app’s logic would work without any React components at all!
+
+We encourage you to further explore the topic of testabile coding in other learning resources.
+
+Writing Tests
+After writing testable code, it’s time to write some actual tests! The default template of React Native ships with Jest testing framework. It includes a preset that's tailored to this environment so you can get productive without tweaking the configuration and mocks straight away—more on mocks shortly. You can use Jest to write all types of tests featured in this guide.
+
+If you do test-driven development, you actually write tests first! That way, testability of your code is given.
+
Structuring Tests
Your tests should be short and ideally test only one thing. Let's start with an example unit test written with Jest:
it('given a date in the past, colorForDueDate() returns red', () => {
- expect(colorForDueDate('2000-10-20'))).toBe('red');
+ expect(colorForDueDate('2000-10-20')).toBe('red');
});
-The test is described by the string passed to the it function - take good care writing the description so that it’s clear what is being tested. Do your best to cover the following:
+The test is described by the string passed to the it function. Take good care writing the description so that it’s clear what is being tested. Do your best to cover the following:
- Given - some precondition
- When - some action executed by the function that you’re testing
@@ -102,48 +110,61 @@
This is also known as AAA (Arrange, Act, Assert).
Jest offers describe function to help structure your tests. Use describe to group together all tests that belong to one functionality. Describes can be nested, if you need that. Other functions you'll commonly use are beforeEach or beforeAll that you can use for setting up the objects you're testing. Read more in the Jest api reference.
-If your test has many steps or many expectations, you probably want to split it into multiple smaller ones. Also, ensure that your tests are completely independent of one another. Each test in your suite must be executable on its own without eg. first running some other test. Conversely, if you run all your tests together, the first test must not influence the output of the second one.
-Lastly, as developers we like when our code works great and doesn't crash. With tests, this is often the opposite - think of a failing test as of a good thing! When a test is failing, it often means something is not right and it gives us an opportunity to fix the problem before it impacts the users.
+If your test has many steps or many expectations, you probably want to split it into multiple smaller ones. Also, ensure that your tests are completely independent of one another. Each test in your suite must be executable on its own without first running some other test. Conversely, if you run all your tests together, the first test must not influence the output of the second one.
+Lastly, as developers we like when our code works great and doesn't crash. With tests, this is often the opposite. Think of a failed test as of a good thing! When a test fails, it often means something is not right. This gives you an opportunity to fix the problem before it impacts the users.
Unit tests
Unit tests cover the smallest parts of code, like individual functions or classes.
-When the object under test has any dependencies, you’ll often mock them out, as described in the next paragraph.
+When the object being tested has any dependencies, you’ll often need to mock them out, as described in the next paragraph.
The great thing about unit tests is that they are quick to write and run. Therefore, as you work, you get fast feedback about whether your tests are passing. Jest even has an option to continuously run tests that are related to code you’re editing: Watch mode.
-Mocking
-Sometimes, when your tested objects have external dependencies, you’ll want to mock them out. “Mocking” is when you replace some dependency of your code by your own implementation. Note that generally, using real objects in your tests is better than using mocks but there are situations where this is not possible (for example when your JS unit test relies on a native module written in Java or Objective-C).
-Imagine you’re writing an app that shows the current weather in your city and you’re using some external service (dependency of your code) that provides you with the weather information. If the service tells you that it’s raining, you want to show an image with a rainy cloud. You don’t want to call that service in your tests, because it would make the tests slow and unstable (because of the network requests involved) and because the service may return different data every time you run the test. Therefore, you can provide a mock implementation of the service - effectively replacing thousands of lines of code and some internet-connected thermometers!
-Jest comes with support for mocking from function level all the way to module level mocking.
-Integration Tests
-When writing larger software systems, individual pieces of it need to interact with each other. As explained, in unit testing, when your unit depends on another one, you’ll sometimes end up mocking the dependency, replacing it with a fake one.
-In integration testing, real individual units are combined (same as in your app) and tested together to ensure that their cooperation works as expected. This is not to say that mocking does not happen here: you’ll still need mocks (for example to mock communication with the weather service covered in the mocking paragraph), but much less than in unit testing.
+
+Mocking
+Sometimes, when your tested objects have external dependencies, you’ll want to “mock them out.” “Mocking” is when you replace some dependency of your code with your own implementation.
-Please note that the terminology around what integration testing means is not always consistent. Also, the line between what is a unit test and what is an integration test may not always be clear. As a rule of thumb for this document, when your test
-
-- Uses an external system (such as the thermometer in the mocking paragraph)
-- Does a network call to other application
-- Does any kind of file or database I/O
-
-Then it falls into the “integration test” category.
+Generally, using real objects in your tests is better than using mocks but there are situations where this is not possible. For example: when your JS unit test relies on a native module written in Java or Objective-C.
+Imagine you’re writing an app that shows the current weather in your city and you’re using some external service or other dependency that provides you with the weather information. If the service tells you that it’s raining, you want to show an image with a rainy cloud. You don’t want to call that service in your tests, because:
+
+- It could make the tests slow and unstable (because of the network requests involved)
+- The service may return different data every time you run the test
+- Third party services can go offline when you really need to run tests!
+
+Therefore, you can provide a mock implementation of the service, effectively replacing thousands of lines of code and some internet-connected thermometers!
+
+Jest comes with support for mocking from function level all the way to module level mocking.
+
+Integration Tests
+When writing larger software systems, individual pieces of it need to interact with each other. In unit testing, if your unit depends on another one, you’ll sometimes end up mocking the dependency, replacing it with a fake one.
+In integration testing, real individual units are combined (same as in your app) and tested together to ensure that their cooperation works as expected. This is not to say that mocking does not happen here: you’ll still need mocks (for example, to mock communication with a weather service), but you'll need them much less than in unit testing.
+
+Please note that the terminology around what integration testing means is not always consistent. Also, the line between what is a unit test and what is an integration test may not always be clear. For this guide, your test falls into "integration testing" if it:
+
+- Uses an external system (such as weather service API)
+- Makes a network call to other application
+- Does any kind of file or database I/O
+
+
+
Component Tests
-React components are responsible for rendering your app, and users will directly interact with their output. Even if your app's business logic has high testing coverage and is correct, without component tests you may still deliver a broken UI to your users. Component tests could fall into both unit and integration testing, and since they are such a core part of React Native, we'll cover them in separate paragraphs.
+React components are responsible for rendering your app, and users will directly interact with their output. Even if your app's business logic has high testing coverage and is correct, without component tests you may still deliver a broken UI to your users. Component tests could fall into both unit and integration testing, but because they are such a core part of React Native, we'll cover them separately.
For testing React components, there are two things you may want to test:
- Interaction: to ensure the component behaves correctly when interacted with by a user (eg. when user presses a button)
-- Rendering: to ensure the component render output used by React is correct
+- Rendering: to ensure the component render output used by React is correct (eg. the button's appearance and placementin the UI)
For example, if you have a button that has an onPress listener, you want to test that the button both appears correctly and that tapping the button is correctly handled by the component.
There are several libraries that can help you testing these:
-- React’s Test Renderer developed alongside its core. It provides a React renderer that can be used to render React components to pure JavaScript objects, without depending on the DOM or a native mobile environment.
-react-native-testing-library builds on top of React’s test renderer and adds fireEvent and query apis described in the next paragraph.@testing-library/react-native is another alternative that also builds on top of React’s test renderer and adds fireEvent and query apis described in the next paragraph.- React’s Test Renderer, developed alongside its core, provides a React renderer that can be used to render React components to pure JavaScript objects, without depending on the DOM or a native mobile environment.
+react-native-testing-library builds on top of React’s test renderer and adds fireEvent and query APIs described in the next paragraph.@testing-library/react-native is another alternative that also builds on top of React’s test renderer and adds fireEvent and query APIs described in the next paragraph.
-Note that component tests are only JavaScript tests running in Node.js environment, they do not take into account any iOS or Android code which is backing the React Native components. It follows that they cannot give you a 100% confidence that everything works for the user - if there is a bug in the iOS or Android code, they will not find it.
+Component tests are only JavaScript tests running in Node.js environment. They do not take into account any iOS, Android, or other platform code which is backing the React Native components. It follows that they cannot give you a 100% confidence that everything works for the user. If there is a bug in the iOS or Android code, they will not find it.
+
Testing User Interactions
Aside from rendering some UI, your components handle events like onChangeText for TextInput or onPress for Button. They may also contain other functions and event callbacks. Consider the following example:
-function GroceryShoppingList() {
+function GroceryShoppingList() {
const [groceryItem, setGroceryItem] = useState('');
const [items, setItems] = useState([]);
@@ -167,9 +188,12 @@
);
}
-When testing user interactions, test the component from the user perspective and avoid testing implementation details. Especially React class components are prone to testing their implementation details such as internal state or event handlers. While such tests work, they are not oriented toward how users will interact with the component and tend to break by refactoring (for example when you'd like to rename some things or rewrite class component using hooks).
-To avoid testing implementation details, prefer using function components (with hooks), which make relying on component internals harder. Component testing libraries such as react-native-testing-library also facilitate this by careful choice of provided apis. The following example uses fireEvent apis that simulate a user interacting with the component and a query function that finds matching nodes in the rendered output.
-test('given empty GroceryShoppingList, user can add an item to it', () => {
+When testing user interactions, test the component from the user perspective—what's on the page? What changes when interacted with? Avoid testing implementation details like objects or state—while such tests work, they are not oriented toward how users will interact with the component and tend to break by refactoring (for example when you'd like to rename some things or rewrite class component using hooks).
+
+React class components are especially prone to testing their implementation details such as internal state or event handlers. To avoid testing implementation details, prefer using function components with Hooks, which make relying on component internals harder.
+
+Component testing libraries such as react-native-testing-library facilitate writing user-centric tests by careful choice of provided APIs. The following example uses fireEvent methods changeText and press that simulate a user interacting with the component and a query function getAllByText that finds matching nodes in the rendered output.
+test('given empty GroceryShoppingList, user can add an item to it', () => {
const {getByPlaceholder, getByText, getAllByText} = render(
<GroceryShoppingList />,
);
@@ -181,41 +205,45 @@
expect(bananaElements).toHaveLength(1); // expect 'banana' to be on the list
});
-In this example, we're not testing how some state changes when you call a function - we're testing what happens when a user changes text in the TextInput and presses the Button!
+This example is not testing how some state changes when you call a function. It tests what happens when a user changes text in the TextInput and presses the Button!
Testing Rendered Output
Snapshot testing is an advanced kind of testing enabled by Jest. It is a very powerful and low-level tool, so extra attention is advised when using it.
-
-In this guide we will speak about "component snapshot", which is a JSX-like string, created by a custom React serializer that lets Jest translate React component trees to string that's human-readable. It's built into Jest and used by default so you don't need to worry about it.
-
-A component snapshot is a textual representation of your component’s render output generated during a test run, and may look like this:
-<Text
- style={
- Object {
- "fontSize": 20,
- "textAlign": "center",
- }
- }>
- Welcome to React Native!
-</Text>
+A "component snapshot" is a JSX-like string created by a custom React serializer built into Jest. This serializer lets Jest translate React component trees to string that's human-readable. Put another way: a component snapshot is a textual representation of your component’s render output generated during a test run. It may look like this:
+<Text
+ style={
+ Object {
+ "fontSize": 20,
+ "textAlign": "center",
+ }
+ }>
+ Welcome to React Native!
+</Text>
-With snapshot testing, you typically first implement your component and then run the snapshot test, which creates a snapshot and saves it to a file in your repo as a reference snapshot. The file is then committed and checked during code review. Changes to the component render output will result in change of its snapshot, which fails the test. You then need to update the stored reference snapshot for the test to pass. That change again needs to be committed and reviewed.
+With snapshot testing, you typically first implement your component and then run the snapshot test. The snapshot test then creates a snapshot and saves it to a file in your repo as a reference snapshot. The file is then committed and checked during code review. Any future changes to the component render output will change its snapshot, which will cause the test to fail. You then need to update the stored reference snapshot for the test to pass. That change again needs to be committed and reviewed.
Snapshots have several weak points:
- For you as a developer or reviewer, it can be hard to tell whether a change in snapshot is intended or whether it's evidence of a bug. Especially large snapshots can quickly become hard to understand and their added value becomes low.
-- When snapshot is created, at that point it is considered to be correct - even in the case when the rendered output is actually wrong. (related to the first point)
+- When snapshot is created, at that point it is considered to be correct-even in the case when the rendered output is actually wrong.
- When a snapshot fails, it's tempting to update it using the
--updateSnapshot jest option without taking proper care to investigate whether the change is expected. Certain developer discipline is thus needed.
Snapshots themselves do not ensure that your component render logic is correct, they are merely good at guarding against unexpected changes and for checking that the components in the React tree under test receive the expected props (styles and etc.).
We recommend that you only use small snapshots (see no-large-snapshots rule). If you want to test a change between two React component states, use snapshot-diff. When in doubt, prefer explicit expectations as described in the previous paragraph.
+
End-to-End Tests
In end-to-end (E2E) tests, you verify your app is working as expected on a device (or a simulator / emulator) from the user perspective.
-This is done by building your app in the release configuration and running the tests against it. In E2E tests, you no longer think about React components, React Native apis, Redux stores or any business logic - that is not the purpose of E2E tests and those are not even accessible to you during E2E testing.
-Instead, E2E testing libraries allow you to find and control elements in the screen of your app: for example, you can actually tap buttons or insert text into textinputs the same way a real user would. Then you can make assertions about whether or not certain element exists in the app’s screen, whether or not it’s visible, what text it contains and so on.
-E2E tests give you the highest possible confidence that part of your app is working. The tradeoff here is that compared to the previously mentioned types of tests, writing them is more time consuming, they are quite slow to run and more prone to flakiness (Flaky test is a test which randomly passes and fails without any change to code.).
-A rule of thumb is to mostly cover vital parts of your app, like authentication flow, core functionalities, payments, etc with E2E tests and use faster JS tests for the rest. The more tests you add, the more confidence, but also more time spent maintaining and running them. Know the tradeoffs and decide what's best for you.
+This is done by building your app in the release configuration and running the tests against it. In E2E tests, you no longer think about React components, React Native APIs, Redux stores or any business logic. That is not the purpose of E2E tests and those are not even accessible to you during E2E testing.
+Instead, E2E testing libraries allow you to find and control elements in the screen of your app: for example, you can actually tap buttons or insert text into TextInputs the same way a real user would. Then you can make assertions about whether or not a certain element exists in the app’s screen, whether or not it’s visible, what text it contains, and so on.
+E2E tests give you the highest possible confidence that part of your app is working. The tradeoffs include:
+
+- writing them is more time consuming compared to the other types of tests
+- they can be slower to run
+- they are more prone to flakiness (a "flaky" test is a test which randomly passes and fails without any change to code)
+
+Try to cover the vital parts of your app with E2E tests: authentication flow, core functionalities, payments, etc. Use faster JS tests for the non-vital parts of your app. The more tests you add, the higher your confidence, but also, the more time you'll spend maintaining and running them. Consider the tradeoffs and decide what's best for you.
There are several E2E testing tools available: in the React Native community, Detox is a popular framework because it’s tailored for React Native apps. Another popular library in the space of iOS and Android apps is Appium.
+
Summary
-We hope you enjoyed and, what's more important, learned something from this guide. There are many ways we can test our apps, and it may be hard to decide what to use at first. However, we believe all of that will make more sense once you start adding tests to your awesome React Native app. So what are you waiting for? Get your coverage up!
+We hope you enjoyed reading and learned something from this guide. There are many ways you can test your apps. It may be hard to decide what to use at first. However, we believe it all will make sense once you start adding tests to your awesome React Native app. So what are you waiting for? Get your coverage up!
Links
- React testing overview
@@ -227,7 +255,7 @@
This guide originally authored and contributed in full by Vojtech Novak.
-
EditTesting
As your codebase expands, small errors and edge cases you don’t expect can cascade into larger failures. Bugs lead to bad user experience and ultimately, business losses. One way to prevent fragile programming is to test your code before releasing it into the wild.
-In this guide, we will cover different (automated) ways to ensure your app works as expected, ranging from static analysis to end-to-end tests.
+In this guide, we will cover different, automated ways to ensure your app works as expected, ranging from static analysis to end-to-end tests.
+
Why Test
-We're humans and we make mistakes. Testing is important because it proves that your code is working, and perhaps even more importantly, ensures that your code continues to work in the future as you add new features, refactor the existing ones, or after you upgrade major dependencies of your project.
-There is more value in testing, that perhaps isn't immediately visible: when there is a bug in your code, often the easiest way to fix it is to write a failing test that exposes the bug - then when you fix the bug in your code and re-run the test, it'll pass, meaning the bug is fixed and is never reintroduced into the code base.
-Tests can also serve as documentation for new people joining your team - when they have to use code they have never seen before, reading tests can greatly help them to understand how the existing code is intended to be used. Last but not least, more automated testing means less time spent with manual QA.
+We're humans, and humans make mistakes. Testing is important because it helps you uncover these mistakes or verifies that your code is working. Perhaps even more importantly, testing ensures that your code continues to work in the future as you add new features, refactor the existing ones, or upgrade major dependencies of your project.
+There is more value in testing than you might realize. One of the best ways to fix a bug in your code is to write a failing test that exposes it. Then when you fix the bug and re-run the test, if it passes it means the bug is fixed, never reintroduced into the code base.
+Tests can also serve as documentation for new people joining your team. For people who have never seen a codebase before, reading tests can help them understand how the existing code works.
+Last but not least, more automated testing means less time spent with manual QA, freeing up valuable development time.
Static Analysis
The first step to improve your code quality is to start using static analysis tools. Static analysis checks your code for errors as you write it, but without running any of that code.
-- Linters analyze code to catch common errors, such as unused code, help avoid pitfalls or flag style guide no-nos like using tabs instead of spaces (or vice versa, depending on your configuration). Linters are configured by a set of rules - and your code needs to follow them.
+- Linters analyze code to catch common errors such as unused code and to help avoid pitfalls, to flag style guide no-nos like using tabs instead of spaces (or vice versa, depending on your configuration).
- Type checking ensures that the construct you’re passing to a function matches what the function was designed to accept, preventing passing a string to a counting function that expects a number, for instance.
-React Native comes with two such tools configured out of the box: ESLint for linting and Flow for type checking. You can also use TypeScript, which is a typed language that compiles to plain JavaScript.
+React Native comes with two such tools configured out of the box: ESLint for linting and Flow for type checking. You can also use TypeScript, which is a typed language that compiles to plain JavaScript.
Writing Testable Code
-To start with tests, you first need to write code that is testable. Consider an aircraft manufacturing process - before any model first takes off to show that all of its complex systems work well together, individual parts are tested to guarantee they are safe and function correctly. For example, wings are tested by bending them under extreme load, engine parts are tested for their durability, windshield is tested against simulated bird impact, and much more.
-Similarly, with software, as opposed to writing your entire program in one huge file with many lines of code, writing your code in multiple small modules that you can test is more effective. In this way, writing testable code is intertwined with writing clean, modular code.
-To help make your app more testable, it’s a good idea to separate the view part of your app, React components, from business logic and app state (regardless of whether you use Redux, MobX or other solutions). This way, you can separate tests of your business logic — which shouldn’t rely on your React components — from the components themselves, whose job is primarily rendering your app’s UI!
-Theoretically, you could go so far as to move all logic and data fetching out of your components. This way your components would be solely dedicated to rendering, and your state would be independent on your components - your app’s logic would work without any React components at all!
-After writing testable code, it’s time to write some actual tests! (Or if you do test-driven development, you actually write tests first! That way, testability of your code is given.). We encourage you to explore the topic of testability in other learning resources.
-The default template of React Native ships with Jest testing framework. It includes a preset that's tailored to this environment so you can get productive without tweaking the configuration and mocks straight away. You can use Jest to write all types of tests featured in this guide. Let’s get started!
+To start with tests, you first need to write code that is testable. Consider an aircraft manufacturing process - before any model first takes off to show that all of its complex systems work well together, individual parts are tested to guarantee they are safe and function correctly. For example, wings are tested by bending them under extreme load; engine parts are tested for their durability; the windshield is tested against simulated bird impact.
+Software is similar. Instead of writing your entire program in one huge file with many lines of code, you write your code in multiple small modules that you can test more thoroughly than if you tested the assembled whole. In this way, writing testable code is intertwined with writing clean, modular code.
+To make your app more testable, start by separating the view part of your app—your React components—from your business logic and app state (regardless of whether you use Redux, MobX or other solutions). This way, you can keep your business logic testing—which shouldn’t rely on your React components—independent of the components themselves, whose job is primarily rendering your app’s UI!
+Theoretically, you could go so far as to move all logic and data fetching out of your components. This way your components would be solely dedicated to rendering. Your state would be entirely independent of your components. Your app’s logic would work without any React components at all!
+
+We encourage you to further explore the topic of testabile coding in other learning resources.
+
+Writing Tests
+After writing testable code, it’s time to write some actual tests! The default template of React Native ships with Jest testing framework. It includes a preset that's tailored to this environment so you can get productive without tweaking the configuration and mocks straight away—more on mocks shortly. You can use Jest to write all types of tests featured in this guide.
+
+If you do test-driven development, you actually write tests first! That way, testability of your code is given.
+
Structuring Tests
Your tests should be short and ideally test only one thing. Let's start with an example unit test written with Jest:
it('given a date in the past, colorForDueDate() returns red', () => {
- expect(colorForDueDate('2000-10-20'))).toBe('red');
+ expect(colorForDueDate('2000-10-20')).toBe('red');
});
-The test is described by the string passed to the it function - take good care writing the description so that it’s clear what is being tested. Do your best to cover the following:
+The test is described by the string passed to the it function. Take good care writing the description so that it’s clear what is being tested. Do your best to cover the following:
- Given - some precondition
- When - some action executed by the function that you’re testing
@@ -102,48 +110,61 @@
This is also known as AAA (Arrange, Act, Assert).
Jest offers describe function to help structure your tests. Use describe to group together all tests that belong to one functionality. Describes can be nested, if you need that. Other functions you'll commonly use are beforeEach or beforeAll that you can use for setting up the objects you're testing. Read more in the Jest api reference.
-If your test has many steps or many expectations, you probably want to split it into multiple smaller ones. Also, ensure that your tests are completely independent of one another. Each test in your suite must be executable on its own without eg. first running some other test. Conversely, if you run all your tests together, the first test must not influence the output of the second one.
-Lastly, as developers we like when our code works great and doesn't crash. With tests, this is often the opposite - think of a failing test as of a good thing! When a test is failing, it often means something is not right and it gives us an opportunity to fix the problem before it impacts the users.
+If your test has many steps or many expectations, you probably want to split it into multiple smaller ones. Also, ensure that your tests are completely independent of one another. Each test in your suite must be executable on its own without first running some other test. Conversely, if you run all your tests together, the first test must not influence the output of the second one.
+Lastly, as developers we like when our code works great and doesn't crash. With tests, this is often the opposite. Think of a failed test as of a good thing! When a test fails, it often means something is not right. This gives you an opportunity to fix the problem before it impacts the users.
Unit tests
Unit tests cover the smallest parts of code, like individual functions or classes.
-When the object under test has any dependencies, you’ll often mock them out, as described in the next paragraph.
+When the object being tested has any dependencies, you’ll often need to mock them out, as described in the next paragraph.
The great thing about unit tests is that they are quick to write and run. Therefore, as you work, you get fast feedback about whether your tests are passing. Jest even has an option to continuously run tests that are related to code you’re editing: Watch mode.
-Mocking
-Sometimes, when your tested objects have external dependencies, you’ll want to mock them out. “Mocking” is when you replace some dependency of your code by your own implementation. Note that generally, using real objects in your tests is better than using mocks but there are situations where this is not possible (for example when your JS unit test relies on a native module written in Java or Objective-C).
-Imagine you’re writing an app that shows the current weather in your city and you’re using some external service (dependency of your code) that provides you with the weather information. If the service tells you that it’s raining, you want to show an image with a rainy cloud. You don’t want to call that service in your tests, because it would make the tests slow and unstable (because of the network requests involved) and because the service may return different data every time you run the test. Therefore, you can provide a mock implementation of the service - effectively replacing thousands of lines of code and some internet-connected thermometers!
-Jest comes with support for mocking from function level all the way to module level mocking.
-Integration Tests
-When writing larger software systems, individual pieces of it need to interact with each other. As explained, in unit testing, when your unit depends on another one, you’ll sometimes end up mocking the dependency, replacing it with a fake one.
-In integration testing, real individual units are combined (same as in your app) and tested together to ensure that their cooperation works as expected. This is not to say that mocking does not happen here: you’ll still need mocks (for example to mock communication with the weather service covered in the mocking paragraph), but much less than in unit testing.
+
+Mocking
+Sometimes, when your tested objects have external dependencies, you’ll want to “mock them out.” “Mocking” is when you replace some dependency of your code with your own implementation.
-Please note that the terminology around what integration testing means is not always consistent. Also, the line between what is a unit test and what is an integration test may not always be clear. As a rule of thumb for this document, when your test
-
-- Uses an external system (such as the thermometer in the mocking paragraph)
-- Does a network call to other application
-- Does any kind of file or database I/O
-
-Then it falls into the “integration test” category.
+Generally, using real objects in your tests is better than using mocks but there are situations where this is not possible. For example: when your JS unit test relies on a native module written in Java or Objective-C.
+Imagine you’re writing an app that shows the current weather in your city and you’re using some external service or other dependency that provides you with the weather information. If the service tells you that it’s raining, you want to show an image with a rainy cloud. You don’t want to call that service in your tests, because:
+
+- It could make the tests slow and unstable (because of the network requests involved)
+- The service may return different data every time you run the test
+- Third party services can go offline when you really need to run tests!
+
+Therefore, you can provide a mock implementation of the service, effectively replacing thousands of lines of code and some internet-connected thermometers!
+
+Jest comes with support for mocking from function level all the way to module level mocking.
+
+Integration Tests
+When writing larger software systems, individual pieces of it need to interact with each other. In unit testing, if your unit depends on another one, you’ll sometimes end up mocking the dependency, replacing it with a fake one.
+In integration testing, real individual units are combined (same as in your app) and tested together to ensure that their cooperation works as expected. This is not to say that mocking does not happen here: you’ll still need mocks (for example, to mock communication with a weather service), but you'll need them much less than in unit testing.
+
+Please note that the terminology around what integration testing means is not always consistent. Also, the line between what is a unit test and what is an integration test may not always be clear. For this guide, your test falls into "integration testing" if it:
+
+- Uses an external system (such as weather service API)
+- Makes a network call to other application
+- Does any kind of file or database I/O
+
+
+
Component Tests
-React components are responsible for rendering your app, and users will directly interact with their output. Even if your app's business logic has high testing coverage and is correct, without component tests you may still deliver a broken UI to your users. Component tests could fall into both unit and integration testing, and since they are such a core part of React Native, we'll cover them in separate paragraphs.
+React components are responsible for rendering your app, and users will directly interact with their output. Even if your app's business logic has high testing coverage and is correct, without component tests you may still deliver a broken UI to your users. Component tests could fall into both unit and integration testing, but because they are such a core part of React Native, we'll cover them separately.
For testing React components, there are two things you may want to test:
- Interaction: to ensure the component behaves correctly when interacted with by a user (eg. when user presses a button)
-- Rendering: to ensure the component render output used by React is correct
+- Rendering: to ensure the component render output used by React is correct (eg. the button's appearance and placementin the UI)
For example, if you have a button that has an onPress listener, you want to test that the button both appears correctly and that tapping the button is correctly handled by the component.
There are several libraries that can help you testing these:
-- React’s Test Renderer developed alongside its core. It provides a React renderer that can be used to render React components to pure JavaScript objects, without depending on the DOM or a native mobile environment.
-react-native-testing-library builds on top of React’s test renderer and adds fireEvent and query apis described in the next paragraph.@testing-library/react-native is another alternative that also builds on top of React’s test renderer and adds fireEvent and query apis described in the next paragraph.- React’s Test Renderer, developed alongside its core, provides a React renderer that can be used to render React components to pure JavaScript objects, without depending on the DOM or a native mobile environment.
+react-native-testing-library builds on top of React’s test renderer and adds fireEvent and query APIs described in the next paragraph.@testing-library/react-native is another alternative that also builds on top of React’s test renderer and adds fireEvent and query APIs described in the next paragraph.
-Note that component tests are only JavaScript tests running in Node.js environment, they do not take into account any iOS or Android code which is backing the React Native components. It follows that they cannot give you a 100% confidence that everything works for the user - if there is a bug in the iOS or Android code, they will not find it.
+Component tests are only JavaScript tests running in Node.js environment. They do not take into account any iOS, Android, or other platform code which is backing the React Native components. It follows that they cannot give you a 100% confidence that everything works for the user. If there is a bug in the iOS or Android code, they will not find it.
+
Testing User Interactions
Aside from rendering some UI, your components handle events like onChangeText for TextInput or onPress for Button. They may also contain other functions and event callbacks. Consider the following example:
-function GroceryShoppingList() {
+function GroceryShoppingList() {
const [groceryItem, setGroceryItem] = useState('');
const [items, setItems] = useState([]);
@@ -167,9 +188,12 @@
);
}
-When testing user interactions, test the component from the user perspective and avoid testing implementation details. Especially React class components are prone to testing their implementation details such as internal state or event handlers. While such tests work, they are not oriented toward how users will interact with the component and tend to break by refactoring (for example when you'd like to rename some things or rewrite class component using hooks).
-To avoid testing implementation details, prefer using function components (with hooks), which make relying on component internals harder. Component testing libraries such as react-native-testing-library also facilitate this by careful choice of provided apis. The following example uses fireEvent apis that simulate a user interacting with the component and a query function that finds matching nodes in the rendered output.
-test('given empty GroceryShoppingList, user can add an item to it', () => {
+When testing user interactions, test the component from the user perspective—what's on the page? What changes when interacted with? Avoid testing implementation details like objects or state—while such tests work, they are not oriented toward how users will interact with the component and tend to break by refactoring (for example when you'd like to rename some things or rewrite class component using hooks).
+
+React class components are especially prone to testing their implementation details such as internal state or event handlers. To avoid testing implementation details, prefer using function components with Hooks, which make relying on component internals harder.
+
+Component testing libraries such as react-native-testing-library facilitate writing user-centric tests by careful choice of provided APIs. The following example uses fireEvent methods changeText and press that simulate a user interacting with the component and a query function getAllByText that finds matching nodes in the rendered output.
+test('given empty GroceryShoppingList, user can add an item to it', () => {
const {getByPlaceholder, getByText, getAllByText} = render(
<GroceryShoppingList />,
);
@@ -181,41 +205,45 @@
expect(bananaElements).toHaveLength(1); // expect 'banana' to be on the list
});
-In this example, we're not testing how some state changes when you call a function - we're testing what happens when a user changes text in the TextInput and presses the Button!
+This example is not testing how some state changes when you call a function. It tests what happens when a user changes text in the TextInput and presses the Button!
Testing Rendered Output
Snapshot testing is an advanced kind of testing enabled by Jest. It is a very powerful and low-level tool, so extra attention is advised when using it.
-
-In this guide we will speak about "component snapshot", which is a JSX-like string, created by a custom React serializer that lets Jest translate React component trees to string that's human-readable. It's built into Jest and used by default so you don't need to worry about it.
-
-A component snapshot is a textual representation of your component’s render output generated during a test run, and may look like this:
-<Text
- style={
- Object {
- "fontSize": 20,
- "textAlign": "center",
- }
- }>
- Welcome to React Native!
-</Text>
+A "component snapshot" is a JSX-like string created by a custom React serializer built into Jest. This serializer lets Jest translate React component trees to string that's human-readable. Put another way: a component snapshot is a textual representation of your component’s render output generated during a test run. It may look like this:
+<Text
+ style={
+ Object {
+ "fontSize": 20,
+ "textAlign": "center",
+ }
+ }>
+ Welcome to React Native!
+</Text>
-With snapshot testing, you typically first implement your component and then run the snapshot test, which creates a snapshot and saves it to a file in your repo as a reference snapshot. The file is then committed and checked during code review. Changes to the component render output will result in change of its snapshot, which fails the test. You then need to update the stored reference snapshot for the test to pass. That change again needs to be committed and reviewed.
+With snapshot testing, you typically first implement your component and then run the snapshot test. The snapshot test then creates a snapshot and saves it to a file in your repo as a reference snapshot. The file is then committed and checked during code review. Any future changes to the component render output will change its snapshot, which will cause the test to fail. You then need to update the stored reference snapshot for the test to pass. That change again needs to be committed and reviewed.
Snapshots have several weak points:
- For you as a developer or reviewer, it can be hard to tell whether a change in snapshot is intended or whether it's evidence of a bug. Especially large snapshots can quickly become hard to understand and their added value becomes low.
-- When snapshot is created, at that point it is considered to be correct - even in the case when the rendered output is actually wrong. (related to the first point)
+- When snapshot is created, at that point it is considered to be correct-even in the case when the rendered output is actually wrong.
- When a snapshot fails, it's tempting to update it using the
--updateSnapshot jest option without taking proper care to investigate whether the change is expected. Certain developer discipline is thus needed.
Snapshots themselves do not ensure that your component render logic is correct, they are merely good at guarding against unexpected changes and for checking that the components in the React tree under test receive the expected props (styles and etc.).
We recommend that you only use small snapshots (see no-large-snapshots rule). If you want to test a change between two React component states, use snapshot-diff. When in doubt, prefer explicit expectations as described in the previous paragraph.
+
End-to-End Tests
In end-to-end (E2E) tests, you verify your app is working as expected on a device (or a simulator / emulator) from the user perspective.
-This is done by building your app in the release configuration and running the tests against it. In E2E tests, you no longer think about React components, React Native apis, Redux stores or any business logic - that is not the purpose of E2E tests and those are not even accessible to you during E2E testing.
-Instead, E2E testing libraries allow you to find and control elements in the screen of your app: for example, you can actually tap buttons or insert text into textinputs the same way a real user would. Then you can make assertions about whether or not certain element exists in the app’s screen, whether or not it’s visible, what text it contains and so on.
-E2E tests give you the highest possible confidence that part of your app is working. The tradeoff here is that compared to the previously mentioned types of tests, writing them is more time consuming, they are quite slow to run and more prone to flakiness (Flaky test is a test which randomly passes and fails without any change to code.).
-A rule of thumb is to mostly cover vital parts of your app, like authentication flow, core functionalities, payments, etc with E2E tests and use faster JS tests for the rest. The more tests you add, the more confidence, but also more time spent maintaining and running them. Know the tradeoffs and decide what's best for you.
+This is done by building your app in the release configuration and running the tests against it. In E2E tests, you no longer think about React components, React Native APIs, Redux stores or any business logic. That is not the purpose of E2E tests and those are not even accessible to you during E2E testing.
+Instead, E2E testing libraries allow you to find and control elements in the screen of your app: for example, you can actually tap buttons or insert text into TextInputs the same way a real user would. Then you can make assertions about whether or not a certain element exists in the app’s screen, whether or not it’s visible, what text it contains, and so on.
+E2E tests give you the highest possible confidence that part of your app is working. The tradeoffs include:
+
+- writing them is more time consuming compared to the other types of tests
+- they can be slower to run
+- they are more prone to flakiness (a "flaky" test is a test which randomly passes and fails without any change to code)
+
+Try to cover the vital parts of your app with E2E tests: authentication flow, core functionalities, payments, etc. Use faster JS tests for the non-vital parts of your app. The more tests you add, the higher your confidence, but also, the more time you'll spend maintaining and running them. Consider the tradeoffs and decide what's best for you.
There are several E2E testing tools available: in the React Native community, Detox is a popular framework because it’s tailored for React Native apps. Another popular library in the space of iOS and Android apps is Appium.
+
Summary
-We hope you enjoyed and, what's more important, learned something from this guide. There are many ways we can test our apps, and it may be hard to decide what to use at first. However, we believe all of that will make more sense once you start adding tests to your awesome React Native app. So what are you waiting for? Get your coverage up!
+We hope you enjoyed reading and learned something from this guide. There are many ways you can test your apps. It may be hard to decide what to use at first. However, we believe it all will make sense once you start adding tests to your awesome React Native app. So what are you waiting for? Get your coverage up!
Links
- React testing overview
@@ -227,7 +255,7 @@
This guide originally authored and contributed in full by Vojtech Novak.
-