Configuration Manager

Hint:
• This is a list of the most commonly used Capabilities.
• You can add any property from the List of Appium Capabilities directly to this file after it's generated, just make sure to add [mobile_] as a prefix.

Hint:
• The kind of mobile device or emulator to use.
• On iOS, this should be one of the valid devices returned by instruments with instruments -s devices.
• On Android this capability is currently ignored, though it remains required.

Hint:
• Unique device identifier of the connected physical device (leave empty if not applicable).

Hint:
• The absolute local path or remote http URL to a .ipa file (IOS), .app folder (IOS Simulator), .apk file (Android) or .apks file (Android App Bundle), or a .zip file containing one of these.
• e.g., /abs/path/to/my.apk or http://myapp.com/app.ipa
• You can set this capability programmatically in your setup configuration method like so:
SHAFT.Properties.mobile.set().app("relativePath/to/myApp.apk");
• This capability is not required for Android if you specify the App Package and App Activity Name (see below).
• Leave empty if automating a Web app instead.

Hint:
• Java package of the Android app you want to run.
• e.g., com.example.android.myApp, com.android.settings
• This capability is not required for Android if you specify the App Path (see above).
• For iOS you must specify the App Path (see above).
• Leave empty if automating a Web app instead.

Hint:
• Activity name for the Android activity you want to launch from your package.
• This often needs to be preceded by a . (e.g., .MainActivity instead of MainActivity).
• This capability is not required for Android if you specify the App Path (see above).
• For iOS you must specify the App Path (see above).
• Leave empty if automating a Web app instead.

Hint:
• Name of the target web browser to automate. Should be "Native App" if automating an app instead.

Hint:
• The latest version of the WebDriver executable that is compatible with the target browser. You can get it from here.
• Leave empty if automating an app instead.

Hint:
• The above semicolon ";" separated list of element XPaths will be skipped in case of persistent elements/menus that show up multiple times in the full page screenshots.

Hint:
• A number between 1 and 5.00 where 1 == unscaled and 5.00 == 500% scaled.
• If Linux is scaled you can provide a random value between [1.05, 5.00].
• Windows and Linux browsers only.

Hint:
• Driver Session will attach one video whenever you end the driver session in the after method or after class.
• Test Method will attach one video for every test method.

Hint: Remember to use private static ThreadLocal<SHAFT.GUI.WebDriver> driver = new ThreadLocal<>(); to properly manage your driver in your test classes.

Hint:
• OFF → Tests classes and Test Methods will run in sequence.
• CLASSES → Test classes will run in parallel, and inside each class the methods will run in sequence.
• METHODS → Test methods will run in parallel, and your classes will run in sequence.

Hint:
• The number of threads controls how many items can run in parallel.
• A rule of thumb is that you can create 2 threads for every CPU core. But you can keep testing different numbers until you are satisfied with the performance.

Hint:
• Choose a number between 1 and 10, noting that 1 provides the most high-level, and 10 provides the most detailed log messages.

Hint:
• Enabling maximumPerformanceMode will disable all complementary features to ensure the fastest execution possible with a 400% calculated performance boost.

Hint: All timeouts are in seconds.

Hint:
• Enabling this setting will create an emailable extent report html file after every test execution.

Hint:
• Enabling this setting will serve and open the allure report automatically after every test run.

Hint:
• Enabling this setting will open a lightweight summary report html file after every test execution with the most important info.

Hint:
• .

Hint:
• Automatically capture element name and create a more descriptive report message.

Hint:
• Automatically capture all WebDriver logs from any Selenium/Appium test execution and attach them to the report.

Hint:
• All attachment contents are logged to standard out for debugging API/CLI/DB actions.

Hint:
• Any built-in steps are added as logs, and only explicitly called ReportManager.log actions are added as steps to the report.

Hint:
• Enabling this setting will create a stand-alone report archive that can be easily shared with others.

Hint:
• Enabling this setting will reset the allure report before every test run, while disabling it will allow execution data to accumulate.

Hint:
• Enabling this setting will reset the extent report before every test run, while disabling it will allow you to keep track of your old reports.

Hint:
• Enabling this setting will Attach extent report to allure report in the tear down "Attaching Reports" section.

Hint:
• In order to run the integration, it should be enabled. However, it's recommended to keep it disabled while creating/maintaining the automation scripts to avoid reporting misleading results.

Hint:
• In case you disabled that option you're still able to only report the issue by enabling report Bugs option, they're not linked.

Hint:
• For cucumber report path please make sure it matches cucumber properties path. After selecting your preferred report, please make sure to use allure annotations for TestNG methods or tags [i.e. @TESTID] for cucumber scenarios.

Hint:
• This used to link testcases @TmsLink to xray url in allure report. Click here for more info.