Skip to content

Commit b9a2c48

Browse files
authored
Clean up the documentation for the library testing (#59401)
1 parent a8ac67a commit b9a2c48

File tree

3 files changed

+155
-15
lines changed

3 files changed

+155
-15
lines changed

docs/workflow/testing/libraries/testing-android.md

Lines changed: 50 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -1,18 +1,23 @@
11
# Testing Libraries on Android
22

3+
## Prerequisites
4+
35
The following dependencies should be installed in order to be able to run tests:
46

7+
- OpenJDK
58
- Android NDK
69
- Android SDK
7-
- OpenJDK
8-
- OpenSSL
10+
11+
To manage the dependencies, you can install them via terminal or using Android Studio.
12+
13+
### Using a terminal
914

1015
OpenJDK can be installed on Linux (Ubuntu) using `apt-get`:
1116
```bash
1217
sudo apt-get install openjdk-8 zip unzip
1318
```
1419

15-
Android SDK, NDK and OpenSSL can be automatically installed via the following script:
20+
Android SDK and NDK can be automatically installed via the following script:
1621
```bash
1722
#!/usr/bin/env bash
1823
set -e
@@ -21,7 +26,6 @@ NDK_VER=r21b
2126
SDK_VER=6200805_latest
2227
SDK_API_LEVEL=29
2328
SDK_BUILD_TOOLS=29.0.3
24-
OPENSSL_VER=1.1.1g-alpha-1
2529

2630
if [[ "$OSTYPE" == "darwin"* ]]; then
2731
HOST_OS=darwin
@@ -47,8 +51,21 @@ yes | ${ANDROID_SDK_ROOT}/cmdline-tools/tools/bin/sdkmanager --sdk_root=${ANDROI
4751
${ANDROID_SDK_ROOT}/cmdline-tools/tools/bin/sdkmanager --sdk_root=${ANDROID_SDK_ROOT} "platform-tools" "platforms;android-${SDK_API_LEVEL}" "build-tools;${SDK_BUILD_TOOLS}"
4852
```
4953

54+
### Using Android Studio
55+
56+
Android Studio offers a convenient UI:
57+
- to install all the dependencies;
58+
- to manage android virtual devices;
59+
- to make easy use of adb logs.
60+
5061
## Building Libs and Tests for Android
5162

63+
Before running a build you might want to set the Android SDK and NDK environment variables:
64+
```
65+
export ANDROID_SDK_ROOT=<PATH-TO-ANDROID-SDK>
66+
export ANDROID_NDK_ROOT=<PATH-TO-ANDROID-NDK>
67+
```
68+
5269
Now we're ready to build everything for Android:
5370
```
5471
./build.sh mono+libs -os Android -arch x64
@@ -66,16 +83,43 @@ The following shows how to run tests for a specific library
6683
./dotnet.sh build /t:Test src/libraries/System.Numerics.Vectors/tests /p:TargetOS=Android /p:TargetArchitecture=x64
6784
```
6885

86+
### Running the functional tests
87+
88+
There are [functional tests](https://github.com/dotnet/runtime/tree/main/src/tests/FunctionalTests/) which aim to test some specific features/configurations/modes on a target mobile platform.
89+
90+
A functional test can be run the same way as any library test suite, e.g.:
91+
```
92+
./dotnet.sh build /t:Test -c Release /p:TargetOS=Android /p:TargetArchitecture=x64 src/tests/FunctionalTests/Android/Device_Emulator/PInvoke/Android.Device_Emulator.PInvoke.Test.csproj
93+
```
94+
95+
Currently functional tests are expected to return `42` as a success code so please be careful when adding a new one.
96+
97+
### Testing various configurations
98+
99+
It's possible to test various configurations by setting a combination of additional MSBuild properties such as `RunAOTCompilation`,`MonoForceInterpreter`, and some more.
100+
101+
1. AOT
102+
103+
To build for AOT only mode, add `/p:RunAOTCompilation=true /p:MonoForceInterpreter=false` to a build command.
104+
105+
2. AOT-LLVM
106+
107+
To build for AOT-LLVM mode, add `/p:RunAOTCompilation=true /p:MonoForceInterpreter=false /p:MonoEnableLLVM=true` to a build command.
108+
109+
3. Interpreter
110+
111+
To build for Interpreter mode, add `/p:RunAOTCompilation=false /p:MonoForceInterpreter=true` to a build command.
112+
69113
### Test App Design
70-
Android app is basically a [Java Instrumentation](https://github.com/dotnet/runtime/blob/main/src/mono/msbuild/AndroidAppBuilder/Templates/MonoRunner.java) and a simple Activity that inits the Mono Runtime via JNI. This Mono Runtime starts a simple xunit test
114+
Android app is basically a [Java Instrumentation](https://github.com/dotnet/runtime/blob/main/src/tasks/AndroidAppBuilder/Templates/MonoRunner.java) and a simple Activity that inits the Mono Runtime via JNI. This Mono Runtime starts a simple xunit test
71115
runner called XHarness.TestRunner (see https://github.com/dotnet/xharness) which runs tests for all `*.Tests.dll` libs in the bundle. There is also XHarness.CLI tool with ADB embedded to deploy `*.apk` to a target (device or emulator) and obtain logs once tests are completed.
72116

73117
### Obtaining the logs
74118
XHarness for Android doesn't talk much and only saves test results to a file. However, you can also subscribe to live logs via the following command:
75119
```
76120
adb logcat -s "DOTNET"
77121
```
78-
Or simply open `logcat` window in Android Studio or Visual Stuido.
122+
Or simply open `logcat` window in Android Studio or Visual Studio.
79123

80124
### AVD Manager
81125
If Android Studio is installed, [AVD Manager](https://developer.android.com/studio/run/managing-avds) can be used from the IDE to create and start Android virtual devices. Otherwise, the Android SDK provides the [`avdmanager` command line tool](https://developer.android.com/studio/command-line/avdmanager).
Lines changed: 91 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,34 +1,117 @@
1-
# Testing Libraries on iOS and tvOS
1+
# Testing Libraries on iOS, tvOS, and MacCatalyst
22

3-
In order to build libraries and tests for iOS or tvOS you need recent version of XCode installed (e.g. 11.3 or higher).
3+
## Prerequisites
44

5-
Build Libraries for iOS Simulator:
5+
- XCode 11.3 or higher
6+
- a certificate and provisioning profile if using a device
7+
- a simulator with a proper device type and OS version.
8+
Go `XCode > Window > Devices and Simulators` to revise the list of the available simulators and then `"+" button on bottom left > OS Version dropdown selection > Download more simulator runtimes` in case you need to download more simulators.
9+
10+
## Building Libs and Tests
11+
12+
You can build and run the library tests:
13+
- on a simulator;
14+
- on a device.
15+
16+
Run the following command in a terminal:
17+
```
18+
./build.sh mono+libs -os <TARGET_OS> -arch <TARGET_ARCHITECTURE>
19+
```
20+
where `<TARGET_OS>` is one of the following:
21+
- iOSSimulator
22+
- tvOSSimulator
23+
- MacCatalyst
24+
- iOS
25+
- tvOS
26+
27+
and `<TARGET_ARCHITECTURE>` is one of the following:
28+
- x64
29+
- arm64 (for device)
30+
31+
e.g., to build for an iOS simulator, run:
632
```
733
./build.sh mono+libs -os iOSSimulator -arch x64
834
```
35+
936
Run tests one by one for each test suite on a simulator:
1037
```
1138
./build.sh libs.tests -os iOSSimulator -arch x64 -test
1239
```
40+
41+
### Building for a device
42+
1343
In order to run the tests on a device:
14-
- Set the os to `iOS` instead of `iOSSimulator`
15-
- Specify `DevTeamProvisioning` (see [developer.apple.com/account/#/membership](https://developer.apple.com/account/#/membership), scroll down to `Team ID`):
44+
- Set the `-os` parameter to a device-related value (see above)
45+
- Specify `DevTeamProvisioning` (see [developer.apple.com/account/#/membership](https://developer.apple.com/account/#/membership), scroll down to `Team ID`).
46+
47+
For example:
1648
```
1749
./build.sh libs.tests -os iOS -arch x64 -test /p:DevTeamProvisioning=H1A2B3C4D5
1850
```
19-
[AppleAppBuilder](https://github.com/dotnet/runtime/blob/main/src/mono/msbuild/AppleAppBuilder/AppleAppBuilder.cs) generates temp Xcode projects you can manually open and resolve provisioning issues there using native UI and deploy to your devices.
51+
[AppleAppBuilder](https://github.com/dotnet/runtime/blob/main/src/tasks/AppleAppBuilder/AppleAppBuilder.cs) generates temp Xcode projects you can manually open and resolve provisioning issues there using native UI and deploy to your devices.
2052

2153
### Running individual test suites
54+
2255
- The following shows how to run tests for a specific library:
2356
```
2457
./dotnet.sh build src/libraries/System.Numerics.Vectors/tests /t:Test /p:TargetOS=iOS /p:TargetArchitecture=x64
2558
```
2659

60+
Also you can run the built test app through Xcode by opening the corresponding `.xcodeproj` and setting up the right scheme, app, and even signing if using a local device.
61+
62+
There's also an option to run a `.app` through `xcrun`, which is simulator specific. Consider the following shell script:
63+
64+
```
65+
xcrun simctl shutdown <IOSSIMULATOR_NAME>
66+
xcrun simctl boot <IOSSIMULATOR_NAME>
67+
open -a Simulator
68+
xcrun simctl install <IOSSIMULATOR_NAME> <APP_BUNDLE_PATH>
69+
xcrun simctl launch --console booted <IOS_APP_NAME>
70+
```
71+
72+
where
73+
`<IOSSIMULATOR_NAME>` is a name of the simulator to start, e.g. `"iPhone 11"`,
74+
`<APP_BUNDLE_PATH>` is a path to the iOS test app bundle,
75+
`<IOS_APP_NAME>` is a name of the iOS test app
76+
77+
### Running the functional tests
78+
79+
There are [functional tests](https://github.com/dotnet/runtime/tree/main/src/tests/FunctionalTests/) which aim to test some specific features/configurations/modes on a target mobile platform.
80+
81+
A functional test can be run the same way as any library test suite, e.g.:
82+
```
83+
./dotnet.sh build /t:Test -c Release /p:TargetOS=iOSSimulator /p:TargetArchitecture=x64 src/tests/FunctionalTests/iOS/Simulator/PInvoke/iOS.Simulator.PInvoke.Test.csproj
84+
```
85+
86+
Currently functional tests are expected to return `42` as a success code so please be careful when adding a new one.
87+
88+
### Viewing logs
89+
- see the logs generated by the XHarness tool
90+
- use the `Console` app on macOS:
91+
`Command + Space`, type in `Console`, search the appropriate process (System.Buffers.Tests for example).
92+
93+
### Testing various configurations
94+
95+
It's possible to test various configurations by setting a combination of additional MSBuild properties such as `RunAOTCompilation`,`MonoEnableInterpreter`, and some more.
96+
97+
1. Interpreter Only
98+
99+
This configuration is necessary for hot reload scenarios.
100+
101+
To enable the interpreter, add `/p:RunAOTCompilation=true /p:MonoEnableInterpreter=true` to a build command.
102+
103+
2. AOT only
104+
105+
To build for AOT only mode, add `/p:RunAOTCompilation=true /p:MonoEnableInterpreter=false` to a build command.
106+
107+
3. AOT-LLVM
108+
109+
To build for AOT-LLVM mode, add `/p:RunAOTCompilation=true /p:MonoEnableInterpreter=false /p:MonoEnableLLVM=true` to a build command.
110+
27111
### Test App Design
28-
iOS/tvOS `*.app` (or `*.ipa`) is basically a simple [ObjC app](https://github.com/dotnet/runtime/blob/main/src/mono/msbuild/AppleAppBuilder/Templates/main-console.m) that inits the Mono Runtime. This Mono Runtime starts a simple xunit test
112+
iOS/tvOS `*.app` (or `*.ipa`) is basically a simple [ObjC app](https://github.com/dotnet/runtime/blob/main/src/tasks/AppleAppBuilder/Templates/main-console.m) that inits the Mono Runtime. This Mono Runtime starts a simple xunit test
29113
runner called XHarness.TestRunner (see https://github.com/dotnet/xharness) which runs tests for all `*.Tests.dll` libs in the bundle. There is also XHarness.CLI tool to deploy `*.app` and `*.ipa` to a target (device or simulator) and listens for logs via network sockets.
30114

31115
### Existing Limitations
32-
- Most of the test suites crash on devices due to #35674
33116
- Simulator uses JIT mode only at the moment (to be extended with FullAOT and Interpreter)
34117
- Interpreter is not enabled yet.

docs/workflow/testing/mono/testing.md

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -93,7 +93,20 @@ For example, the following command is for running System.Runtime tests:
9393
make run-tests-corefx-System.Runtime
9494
```
9595
### Mobile targets and WebAssembly
96-
Build and run library tests against Webassembly, Android or iOS. See instructions located in [Library testing document folder](../libraries/)
96+
Build and run library tests against WebAssembly, Android or iOS. See instructions located in [Library testing document folder](../libraries/)
97+
98+
## Running the functional tests
99+
100+
There are the [functional tests](https://github.com/dotnet/runtime/tree/main/src/tests/FunctionalTests/) which aim to test some specific features/configurations/modes on Android, iOS-like platforms (iOS/tvOS + simulators, MacCatalyst), and WebAssembly.
101+
102+
A functional test can be run the same way as any library test suite, e.g.:
103+
```
104+
./dotnet.sh build /t:Test -c Release /p:TargetOS=Android /p:TargetArchitecture=x64 src/tests/FunctionalTests/Android/Device_Emulator/PInvoke/Android.Device_Emulator.PInvoke.Test.csproj
105+
```
106+
107+
Currently the functional tests are expected to return `42` as a success code so please be careful when adding a new one.
108+
109+
For more details, see instructions located in [Library testing document folder](../libraries/).
97110

98111
# Running the Mono samples
99112
There are a few convenient samples located in `$(REPO_ROOT)/src/mono/sample`, which could help you test your program easily with different flavors of Mono or do a sanity check on the build. The samples are set up to work with a specific configuration; please refer to the relevant Makefile for specifics. If you would like to work with a different configuration, you can edit the Makefile.

0 commit comments

Comments
 (0)