Suitest API without Suitest Test Launcher

This part of user documentation is describing an obsolete version 2.5.* (or older) of Suitest JavaScript API and is meant only for users who have not yet switched to the version 3. If you are new to Suitest JavaScript API, please use the version 3 instead.

If you want to use Suitest JavaScript API for purposes other the end-to-end testing or if your CI process has very specific requirements it may be optimal to use the JavaScript API directly and without the Suitest Test Launcher. E.g. you may need to program your own test launcher.

In this case you need to make additional calls to authenticate, pair the device and set application configuration. You'll find these functions over in the commands section


Authentication

Authenticating with Suitest means getting a session token. Based on the type of the session token you can either operate a single device (interactive mode) or launch many tests on many devices (automated mode):

Authenticating for interactive mode

To enter the interactive mode you need an interactive session token. To get the token call openSession and pass your e-mail, password and Suitest organization ID (displayed in your profile summary).

// Open a session in interactive mode
const sessionInfo = await suitest.openSession({
    username: 'mr@lollipop.com',
    password: 'mypassword',
    orgId: 'xxxxxx-xxxxxxx-xxxxxx-xxxxx'
});

The sessionInfo constant will contain:

{
    deviceAccessToken: 'your session token',
    tokenValidUntil: timestamp
}

The generated token will be automatically used for all remaining API calls in this process.

Authenticating for automated mode

Currently the automated mode in Suitest API is limited to running a Test Pack. To enter automated mode and start the test pack call startTestPack and pass your Personal/Service token ID and password and the ID of the test pack with which this test run has to be associated. startTestPack() returns an automated session token.

// Start Test Pack run
const testPack = await suitest.startTestPack({
    accessTokenId: 'token ID',
    accessTokenPassword: 'token password',
    testPackId: 'test pack ID',
});

The testPack constant will contain the following:

{
    deviceAccessToken: 'session token',
    tokenValidUntil: 'YYYY-MM-DDTHH:MM:SS.SSSz',
    testPackRunId: 'test pack run id',
    testPack: {
        name: 'Test pack name',
        devices: [
            {deviceId: 'id of the device to run test on'},
            {deviceId: 'other device id'}
        ]
    }
};

The generated token will be automatically used for all remaining API calls in this process.

Authenticating with a pre-generated token

Once you call the openSession or startTestPack the generated access token will be automatically used for all remaining API calls inside this Node process.

You can use the same token inside worker processes. To use the previously generated token run openSession and submit the token.

await suitest.openSession({sessionToken: 'pre-generated token'});

Closing session

Suitest session tokens obtained through the JavaScript API are temporary, however, it is required to close the session after all tests have been completed. To invalidate the token and close the session call closeSession.

// Close the current session and invalidate token
await suitest.closeSession();

Connecting to device

After authenticated (in any mode) you can connect to a device by calling
pairDevice and submitting a device id.

// Request control over a device
await suitest.pairDevice('device id');

You should take care to properly disconnect from the device in the end. To disconnect call releaseDevice.

// Release control over remote device
await suitest.releaseDevice();

Selecting application for this session

In interactive mode call set setAppConfig to select application and it's configuration that will be opened when openApp is called.

// Select application configuration to work with
await suitest.setAppConfig(configId);

For automated mode this step is not necessary since the app configuration is contained in the definition of the test pack, so you are good to go.

Configuration override

Often it is desirable to run the test or test pack with a slightly modified configuration. For instance when implementing a CI process you may want to specify a unique app URL (or package) for every test pack execution.

To override execution parameters use the config parameter of setAppConfig (in interactive mode) and startTestPack (in automated mode).

Example value of the config parameter overriding various settings of the test pack:

{
    url: 'http://suite.st/xx/xxx.html#/xxxxx/xxxxxxxx/xxxxxxx',
    suitestify: true,
    domainList: [
        'http://suite.st',
    ],
    // `freezeRules` is a legacy name for the URL mapping configuration
    // we are going to rename it in the next major release version
    freezeRules: [
        {
            methods: [
                "GET",
            ],
            url: "http://suite.st/xx/xxx.html#/xxxxx/xxxxxxxx/xxxxxxx?channel=xxx1",
            type: "map",
            toUrl: "http://suite.st/xx/xxx.html#/xxxxx/xxxxxxxx/xxxxxxx?channel=xxx2",
        },
    ],
    codeOverrides: {
        "dev": "prod",
    },
    configVariables: [{
        key: "someVar",
        value: "someVal",
    }],
    overrideOpenApp: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
}

Suitest Network API (section Models -> AppConfigOverride) contains additional info about the available fields of the config parameter.