For Demonstration Purposes Only
The code in these scripts is provided on an "AS-IS" basis without warranty of any kind, either express or implied, including without limitation any implied warranties of condition, uninterrupted use, merchantability, fitness for a particular purpose, or non-infringement. These scripts are provided for educational and demonstration purposes only, and should not be used in production. Issues regarding these scripts should be submitted through GitHub. These scripts are maintained by the Technical Services team at Sauce Labs.
This repository will hold multiple examples of how to run XCUITests tests on the Sauce Labs cloud. More information on how to use it can be found below.
- Please check our documentation for installing SauceCTL
- Make sure you've set up your credentials on your local machine and or CI pipeline, see this-doc
- Check the XCUITest-docs for all options
curl -L https://saucelabs.github.io/saucectl/install | bash
⚠️ Make sure saucectl version is newer than v0.44.0
Prebuilt native iOS applications and their XCUITests test cases are included in this repo. The source of this application can be found on GitHub in this folder. The test classes can be found here.
The application is bundled in MyDemoApp.ipa
and the test cases are bundled in MyDemoAppUITests-Runner.ipa
.
The application is bundled in MyDemoAppSimulator.zip
and the test cases are bundled in MyDemoAppUITestsSimulator-Runner.zip
.
All the below-mentioned examples can be found in the .sauce
-folder. You can run the configurations by running
the following command from the root of this folder
saucectl run --config ./.sauce/runner-ex{#}.yml
The #
stands for the number of the below-mentioned examples.
runner-ex1.yml
provides a minimum configuration needed to run the XCUITest tests.
In this example, all test cases are executed on a single, available device in sequential order.
runner-ex2.yml
provides a minimum configuration needed to run the XCUITest tests.
In this example, there are two test cases from one class executed on a single, available device in sequential order.
runner-ex3.yml
breaks apart the execution of the two test cases such that they can run in
parallel on separate devices that are available (ie., not in use) in the pool.
runner-ex4.yml
modifies the second example by specifying which hardcoded/fixed device in
the pool to execute each test on. This is called static allocation. Still uses parallel execution.
runner-ex5.yml
uses the dynamic
capability to look for available devices using wildcard
names. This example demonstrates the ability to run a specified test(s) on a pool of devices that are configured the same
but have different names for parallel processing.
runner-ex6.yml
uses only the platformVersion
field to select an available device.
Demonstrates the ability to pick a specific version of iOS from the pool of devices for executing tests in parallel.
runner-ex7.yml
uses shard
and testListFile
. This example demonstrates the ability to shard all classes over 3 devices.
runner-ex8.yml
uses shard
and testListFile
. This example demonstrates the ability to shard all 20 methods over 10 devices.
runner-ex9.yml
. This example demonstrates the ability to run only failed tests.
runner-ex10.yml
. This example demonstrates the ability to run a localization test.
runner-ex101.yml
. This example shows how to run all tests on a simulator.
runner-ex102.yml
. This example shows how to run all tests on two simulators.
runner-ex103.yml
uses shard
and testListFile
. This example demonstrates the ability to shard all classes over 6 simulators.
runner-ex104.yml
uses shard
and testListFile
. This example demonstrates the ability to shard all 20 methods over 10 simulators.