acostalima / react-native-test-runner Goto Github PK

Steps

• Check whether ANDROID_HOME is set
• Check whether ANDROID_SDK_ROOT is set
• Look up the tools in the appropriate directories:
  • platform-tools/adb
  • emulator/emulator
  • tools/bin/sdkmanager
  • tools/bin/avdmanager
• We may also check whether adb and emulator are available in the PATH

See:

• https://developer.android.com/studio/command-line/variables

This can be accomplished with, e.g., a --before-all option which accepts the path to the script to evaluate. It it useful, for instance, to install polyfills before running the test suite.

Native modules must be installed in the test app's directory so they can be linked natively. Additionally, we must run pod install for iOS.

While HMR has to be enabled to capture logs emitted by the app, a watch mode is not yet supported in the CLI. We want the CLI to exit immediately when JS fails to build or a runtime error occurs. For this purpose, we must reject the Promise returned by waitForTests.

When this option is not provided, find the currently booted emulator. If none, exit the process with a non-zero status code and an appropriate error message.

If there is already a booted emulator (AVD) or iOS simulador and either --simulator or --emulator option is passed, the runner does not honor the user's choice because it does not attempt to boot the specified AVD or iOS simulator. In this case, the runner launches the test app in the already booted device and we don't want this behavior.

The runner should always honor the user's choice. Booting a second device is also desirable because:

• We don't know if the device is set up with the runtime we need, e.g., Android API level and iOS version
• The already booted device might be in use for some other purpose. We shouldn't take it over or control it.

I propose introducing a new option, --ci, to override the behavior described above. With this option, the runner explicitly searches for the device that is already booted to launch the test app.
If more than one device is found, exit with an error.
If no devices are found, also exit with an error.
If both --ci and either --simulator or --emulator are passed, also exit with an error. These options are mutually exclusive.

The --ci option is useful in CI environments where an AVD or iOS simulator is already booted prior to the runner's execution.

iOS development toolchain is only available on Apple's OS.

• Check whether the return value of os.platform() is darwin to ensure we're running in macOS.
• Check the output of xcode-select -p which returns the path to developer directory. Alternatively, we might be able to check the exit code.
• Check whether xcodebuild is in the PATH.

Investigate why the iOS job is now failing with the following error:

Invalid runtime: com.apple.CoreSimulator.SimRuntime.iOS-14-2

The runtime in question was available before, so GitHub might have changed something in the latest macOS virtual environment.

See: https://github.com/actions/virtual-environments/blob/main/images/macos/macos-11.0-Readme.md

When this option is not provided, find the currently booted emulator. If none, exit the process with a non-zero status code and an appropriate error message.

The AVD should terminate after a SIGTERM is sent to the emulator process, but it's not even though the code is doing so.

Like so:

Might be related to #12. When the emulator does not terminate, the message is displayed twice. If the emulator does not termine in the previous run, the runner should not even attempt to boot the emulator anyway because it's already booted...

A babel config file is currently being shipped with the test runner. However, if the test runner is used in a project which has its own babel config, it's not possible to override it or add additional plugins. I'm not exactly sure how Metro behaves in this regard, so it's necessary to investigate whether Metro can load a config from the current working directory by default.

When requiring Mocha from the test app, the following warning message is being displayed:

Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.

The message is being filtered out for the time being as a workaround. Although the runner appears to be working as expected, we must find a way to resolve this. Note that we can't use require('mocha'), otherwise Metro picks up the implementation for Node.

The current default already accounts for several situations, but not all. For instance, a test file located at the root of the current working directory is not picked up.

Confer playwright-test's defaults for inspiration.

In the README, it is stated in the limitations section that there is "no support for Windows and macOS". This statement may sound confusing to some people. While the test runner is expected to work on macOS and Windows operating systems without issues, React Native macOS and React Native Windows are not supported as target platforms to run tests agaisnt.