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.
-
One CircleCI personal API token - see here how to set one.
-
Have a clone of
react-native
repo and be on the release branch (0.XX-stable
).# Checkout relevant branch
git checkout 0.72-stable
# Optional: you might need a .watchmanconfig because `npm start` would fail without it.
echo '{}' > .watchmanconfig -
Have 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:yarn 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]
-c, --circleciToken [string]
Using the -c <your-token>
option is recommended, as the script will download the required artifacts from CircleCI, instead of having to build from source reducing the testing time.
There are a couple of extra requirements to make this flow work:
- the CI must have run at least once in the current branch. We need to download artifacts generated by CircleCI, so we need to have at least one run of the CI.
- The relevant jobs must have been finished. The required jobs depends on the task you are about to test:
- if you are testing RNTester on iOS, it has to download Hermes for iOS. So the job that produces it must have finished successfully
- if you are testing RNTester on Android, it has to download the right APK (JSC or Hermes). So the job that produces the APKs must have finished successfully.
- if you are testing RNTestProject, it has to download the maven prebuilts and the Hermes engine for iOS. So the jobs that produce those artifacts must have finished successfully.
Anyway, if any of those prerequisites is not met, the script should output a proper error message.
If you need to build React Native from source, you can skip the -c
parameter. By not passing the CircleCI token, the script falls back to the previous flow, building everything locally.
After completing testing, clean up your local repository state using the following commands.
yarn test-e2e-local-clean
git reset HEAD --hard
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.
Test Notesβ
Debugging
Basic checksβ
- Debugger launch flow
- Use Dev Menu > Open Debugger.
- 0.73 and later: Use
npx react-native-start --experimental-debugger
. Should connect to Hermes debugger in experimental new debugger frontend. - Pre-0.73: Should connect to Hermes debugger in Flipper.
- Console tab
- All versions: Should display all logs.
- Sources tab
- All versions:
- Should allow viewing of source files (Cmd β + P search in Chrome DevTools).
- Should support setting a breakpoint that is hit during app lifetime. Note: Will have broken behaviour across app reloads, excluding via
debugger;
statement.
- All versions:
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 | β
/π¨/π
ββοΈ |
| Debugger (Hermes) | β
/π¨/π
ββοΈ |
| Deploy to TestFlight | β
/π¨/π
ββοΈ |
| **Tested - Android** | |
| Fast Refresh | β
/π¨/π
ββοΈ |
| Debug/dev build on Emulator | β
/π¨/π
ββοΈ |
| Debug/dev build on Device | β
/π¨/π
ββοΈ |
| Production build | β
/π¨/π
ββοΈ |
| Debugger (Hermes) | β
/π¨/π
ββοΈ |
| **Optional - Deprecated in 0.73** | |
| Chrome remote debugger (Android/iOS) | β
/π¨/π
ββοΈ |
| Flipper debugger (Android/iOS) | β
/π¨/π
ββοΈ |