From 2cf09969ab67f5893c3147afb77bfb3bae34c8ad Mon Sep 17 00:00:00 2001 From: R Nabors Date: Thu, 5 Mar 2020 16:10:35 +0000 Subject: [PATCH] Add testing guide - introduction / overview (#1469) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * first version of testing guide * fix some lint warnings * address some of the comments from @TheSavior * expand snapshot testing paragraph * minor improvements * remove confusing param * improve component examples * remove confusing always * add different example for testable code, minor improvements * allow using Detox * Apply suggestions from thymikee Co-Authored-By: Michał Pierzchała * Update docs/testing.md Co-Authored-By: Michał Pierzchała * minor stylistic changes * add motivation paragraph * update snapshot testing * fix lint * Apply suggestions from code review Co-Authored-By: Michał Pierzchała * remove redundant sentence * fix language lint * update component snapshot block * another pass at component tests * self-review * use hooks instead of class component * Adding authorship acknowledgment <3 We love when experts contribute an outsized effort to share their knowledge back to the community. Thank you, Vojtech! Co-authored-by: Michał Pierzchała Co-authored-by: R Nabors --- .alexrc.js | 5 +- docs/testing.md | 225 ++++++++++++++++++++++++++++++++++++++++++ website/i18n/en.json | 3 + website/sidebars.json | 1 + 4 files changed, 233 insertions(+), 1 deletion(-) create mode 100644 docs/testing.md diff --git a/.alexrc.js b/.alexrc.js index 8e57d66334e..dfa25f66f18 100644 --- a/.alexrc.js +++ b/.alexrc.js @@ -11,7 +11,10 @@ exports.allow = [ "invalid", // Unfortunately "watchman" is a library name that we depend on. - "watchman-watchwoman" + "watchman-watchwoman", + + // ignore rehab rule, Detox is an e2e testing library + "rehab" ]; // Use a "maybe" level of profanity instead of the default "unlikely". diff --git a/docs/testing.md b/docs/testing.md new file mode 100644 index 00000000000..49451fdc657 --- /dev/null +++ b/docs/testing.md @@ -0,0 +1,225 @@ +--- +id: testing +title: Testing +--- + +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. + +## 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. + +## 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. +- **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](https://eslint.org/) for linting and [Flow](https://flow.org/en/docs/) for type checking. You can also use [TypeScript](https://www.typescriptlang.org/), 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](https://jestjs.io) 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! + +### Structuring Tests + +Your tests should be short and ideally test only one thing. Let's start with an example unit test written with Jest: + +```js +it('given a date in the past, colorForDueDate() returns red', () => { + expect(colorForDueDate('2000-10-20'))).toBe('red'); +}); +``` + +The test is described by the string passed to the [`it`](https://jestjs.io/docs/en/api#testname-fn-timeout) function - take good care writing the description so that it’s clear what is being tested. Do your best to cover the following: + +1. **Given** - some precondition +2. **When** - some action executed by the function that you’re testing +3. **Then** - the expected outcome + +This is also known as AAA (Arrange, Act, Assert). + +Jest offers [`describe`](https://jestjs.io/docs/en/api#describename-fn) 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`](https://jestjs.io/docs/en/api#beforeeachfn-timeout) or [`beforeAll`](https://jestjs.io/docs/en/api#beforeallfn-timeout) that you can use for setting up the objects you're testing. Read more in the [Jest api reference](https://jestjs.io/docs/en/api). + +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. + +## 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. + +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](https://jestjs.io/docs/en/cli#watch). + +## 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](https://jestjs.io/docs/en/mock-functions#mocking-modules) 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. + +> 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. + +## 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. + +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 + +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](https://reactjs.org/docs/test-renderer.html) 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`](https://github.com/callstack/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`](https://www.native-testing-library.com/) 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. + +### 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: + +```js +function GroceryShoppingList() { + const [groceryItem, setGroceryItem] = useState(''); + const [items, setItems] = useState([]); + + const addNewItemToShoppingList = useCallback(() => { + setItems([groceryItem, ...items]); + setGroceryItem(''); + }, [groceryItem, items]); + + return ( + <> + setGroceryItem(text)} + /> +