Projects
A Playwright project is a named configuration your tests run under. With Appetize each project carries its own session config, so one project can be an iPhone and another a Pixel, running the same tests, or different ones.
A project's config replaces the one in the top-level use; it does not merge with it. If you set buildId at the top level only, any project that defines its own config fails to start with Appetize buildId not set. Give every project a complete config; the examples below share one with a spread.
One app, two platforms
Tests in tests/ios run on an iPhone, tests in tests/android run on a Pixel.
import { defineConfig } from '@playwright/test';
import { AppetizeTestOptions } from '@appetize/playwright';
// shared by every project
const app = { buildId: '<your build id>' };
export default defineConfig<AppetizeTestOptions>({
testDir: './tests',
timeout: 120 * 1000,
workers: 1,
fullyParallel: false,
use: { baseURL: 'https://appetize.io' },
projects: [
{
name: 'ios',
testDir: './tests/ios',
use: { config: { ...app, device: 'iphone15pro' } },
},
{
name: 'android',
testDir: './tests/android',
use: { config: { ...app, device: 'pixel7' } },
},
],
});If your iOS and Android builds are separate apps, give each project its own buildId instead of sharing one:
One suite, several devices
Leave testDir off a project and it runs your whole suite.
The same shape covers OS versions. See Devices & OS Versions for the versions each device offers.
Running them
Projects run one after another until you raise workers. Each worker holds one Appetize session, so keep workers at or below the concurrency your plan allows.
Reading the project inside a test
The resolved config for the current project is available as a test argument, which is useful for branching or skipping:
Last updated
Was this helpful?