Hi there! Are you looking for the official Deno documentation? Try docs.deno.com for all your Deno learning needs.

ScheduleRunTest

import type { ScheduleRunTest } from "https://aws-api.deno.dev/v0.4/services/devicefarm.ts?docs=full";

Represents test settings. This data structure is passed in as the test parameter to ScheduleRun. For an example of the JSON request syntax, see "ScheduleRun".

interface ScheduleRunTest {
filter?: string | null;
parameters?: {
[key: string]: string | null | undefined;
}
| null;
testPackageArn?: string | null;
testSpecArn?: string | null;
type: TestType;
}

§Properties

§
filter?: string | null
[src]

The test's filter.

§
parameters?: {
[key: string]: string | null | undefined;
}
| null
[src]

The test's parameters, such as test framework parameters and fixture settings. Parameters are represented by name-value pairs of strings.

For all tests:

  • app_performance_monitoring: Performance monitoring is enabled by default. Set this parameter to false to disable it.

For Calabash tests:

  • profile: A cucumber profile (for example, my_profile_name).
  • tags: You can limit execution to features or scenarios that have (or don't have) certain tags (for example, @smoke or @smoke,~@wip).

For Appium tests (all types):

  • appium_version: The Appium version. Currently supported values are 1.6.5 (and later), latest, and default.
    • latest runs the latest Appium version supported by Device Farm (1.9.1).
    • For default, Device Farm selects a compatible version of Appium for the device. The current behavior is to run 1.7.2 on Android devices and iOS 9 and earlier and 1.7.2 for iOS 10 and later.
    • This behavior is subject to change.

For fuzz tests (Android only):

  • event_count: The number of events, between 1 and 10000, that the UI fuzz test should perform.
  • throttle: The time, in ms, between 0 and 1000, that the UI fuzz test should wait between events.
  • seed: A seed to use for randomizing the UI fuzz test. Using the same seed value between tests ensures identical event sequences.

For Explorer tests:

  • username: A user name to use if the Explorer encounters a login form. If not supplied, no user name is inserted.
  • password: A password to use if the Explorer encounters a login form. If not supplied, no password is inserted.

For Instrumentation:

  • filter: A test filter string. Examples:
    • Running a single test case: com.android.abc.Test1
    • Running a single test: com.android.abc.Test1#smoke
    • Running multiple tests: com.android.abc.Test1,com.android.abc.Test2

For XCTest and XCTestUI:

  • filter: A test filter string. Examples:
    • Running a single test class: LoginTests
    • Running a multiple test classes: LoginTests,SmokeTests
    • Running a single test: LoginTests/testValid
    • Running multiple tests: LoginTests/testValid,LoginTests/testInvalid

For UIAutomator:

  • filter: A test filter string. Examples:
    • Running a single test case: com.android.abc.Test1
    • Running a single test: com.android.abc.Test1#smoke
    • Running multiple tests: com.android.abc.Test1,com.android.abc.Test2
§
testPackageArn?: string | null
[src]

The ARN of the uploaded test to be run.

§
testSpecArn?: string | null
[src]

The ARN of the YAML-formatted test specification.

§

The test's type.

Must be one of the following values:

  • BUILTIN_FUZZ
  • BUILTIN_EXPLORER. For Android, an app explorer that traverses an Android app, interacting with it and capturing screenshots at the same time.
  • APPIUM_JAVA_JUNIT
  • APPIUM_JAVA_TESTNG
  • APPIUM_PYTHON
  • APPIUM_NODE
  • APPIUM_RUBY
  • APPIUM_WEB_JAVA_JUNIT
  • APPIUM_WEB_JAVA_TESTNG
  • APPIUM_WEB_PYTHON
  • APPIUM_WEB_NODE
  • APPIUM_WEB_RUBY
  • CALABASH
  • INSTRUMENTATION
  • UIAUTOMATION
  • UIAUTOMATOR
  • XCTEST
  • XCTEST_UI