How to Test a Release
These steps needs to be followed by the release crew as part of the release process, to ensure that new versions published have a good level of stability.
An important element of testing source in the release branch is that this process needs to be preferably be done twice, on two separate machines - there are multiple scenarios in which something might fail on a machine but not on another. By running tests on two computers, we want to reach a step of double confirmation that everything works fine.
Pre-requisitesβ
Currently, this flow can only be done on macOS machines.
Have a clone of
react-native
repo and be on the release branch (0.XX-stable
).# Checkout relevant branch
git checkout 0.66-stable
# Optional: you might need a .watchmanconfig because `npm start` would fail without it.
echo '{}' > .watchmanconfigHave Android and iOS development environment set-up. Follow instructions for
React Native CLI quickstart
for macOS/iOS and macOS/Android from the Environment Setup guide.Additional steps for Androidβ
- Gradle should now install the appropriate NDK. Verify that you have in your path the
ANDROID_NDK
variable, pointing to it. - In case you are on macOS Catalina (or higher), you might also need to run
sudo xattr -r -d com.apple.quarantine /path/to/ndk
to avoid the e2e script to fail. (That said, this should not happen anymore since from NDK 21 and higher the Android team started signing the NDK.)
- Gradle should now install the appropriate NDK. Verify that you have in your path the
Stepsβ
Clean up the local stateβ
When testing locally, we want to ensure that we start from a clean slate to avoid caches polluting our testing.
Delete
RNTester
andRNTestProject
from your Android emulator and iOS simulator if leftover from previous test.Remove any temporary files from the
react-native
repo:git clean -fdx
For
main
branch, and versions of RN >=0.71, you can instead useyarn test-e2e-local-clean
.Install dependencies:
yarn install
Generating the projectsβ
The local testing for a release consist of running the test project of the react-native repository, RNTester
, which contains an in-depth list of components implementations, and generating a fresh new project based on the local code, RNTestProject
, that will simulate accurately how a react-native init
project will behave.
To generate the the right project with the specific configuration desired, you can use the command
yarn test-e2e-local [options]
Followed by the wanted options:
--help Show help [boolean]
--version Show version number [boolean]
-t, --target [choices: "RNTester", "RNTestProject"] [default: "RNTester"]
-p, --platform [choices: "iOS", "Android"] [default: "iOS"]
-h, --hermes [boolean] [default: true]
Versions older than 71β
You need to use the interactive script run you through the different variants in Test Dimensions:
./scripts/test-manual-e2e.sh
This script will ask you to select which platform and which project you want to test, and then to execute a series of extra steps during the process. Bear in mind, when testing RNTester on Android, you need to start the Android emulator ahead of time or it will fail.
What to test?β
Aside from verifying that the building process is successful, once the app spawn by the script is up and running, we want to run a series of manual tests to ensure that some core functionalities work, like Fast Refresh and the Flipper debugger.
In the RNTester
you want to also play around with the app and try different components: some important onces are Flatlist
, Image
and the "New Architecture Component" (should be the very last one in the list).
Test Dimensionsβ
To ensure that we cover the most use cases, we need to ensure we test all these different combination of configurations:
- RNTester + iOS + Hermes
- RNTester + iOS + JSC
- RNTester + Android + Hermes
- RNTester + Android + JSC
- RNTestProject + iOS + Hermes
- RNTestProject + iOS + JSC
- RNTestProject + Android + Hermes
- RNTestProject + Android + JSC
Bear in mind that RNTester project is already onboarded in the new architecture. RNTestProject
is not - new architecture mode needs to be enabled and tested separately.
Testing pre-releases (RC) on production appsβ
During the Release Candidate (RC) phase of a release cycle, we ask for the community to set as dependency in their apps the latest RC available and report in the related "Road to 0.XX" how it performs (example).
To help provide the relevant information, we have prepared this template they can use as blueprint for what is important to test - they can copy/pasted it in a comment and fill it accordingly.
| Link to branch: | |
| ---------------------------- | :---------------------- |
| **Project info** | |
| Name | |
| Starting RN version | <add me, ex. RN 0.65.1> |
| Hermes on iOS | yes/no |
| Hermes on Android | yes/no |
| **Tested - iOS** | |
| Fast Refresh | β
/π¨/π
ββοΈ |
| Debug/dev build on Simulator | β
/π¨/π
ββοΈ |
| Debug/dev build on Device | β
/π¨/π
ββοΈ |
| Production build | β
/π¨/π
ββοΈ |
| Chrome remote debugger | β
/π¨/π
ββοΈ |
| Hermes debugger | β
/π¨/π
ββοΈ |
| Flipper debugger | β
/π¨/π
ββοΈ |
| Deploy to TestFlight | β
/π¨/π
ββοΈ |
| **Tested - Android** | |
| Fast Refresh | β
/π¨/π
ββοΈ |
| Debug/dev build on Emulator | β
/π¨/π
ββοΈ |
| Debug/dev build on Device | β
/π¨/π
ββοΈ |
| Production build | β
/π¨/π
ββοΈ |
| Chrome remote debugger | β
/π¨/π
ββοΈ |
| Hermes debugger | β
/π¨/π
ββοΈ |
| Flipper debugger | β
/π¨/π
ββοΈ |