Test Filtering

From the command line

Matching is case-sensitive substring matching. Multiple patterns are comma-separated with no spaces, and file patterns don’t need the .spec.js / .spec.ts suffix.

# One file, or several
./gradlew plugwrightTest -PtestFiles="basic"
./gradlew plugwrightTest -PtestFiles="basic,commands"

# By test name
./gradlew plugwrightTest -PtestNames="should connect"

# Both: "purchase" tests inside "shop" files
./gradlew plugwrightTest -PtestFiles="shop" -PtestNames="purchase"

# Narrow the matrix to specific environments
./gradlew plugwrightTest -Pplugwright.env=local,staging

Running ./gradlew plugwrightTest with no arguments runs everything, on every environment in the matrix.

From the build script

excludeTests skips tests whose name contains one of the substrings, for one environment only:

create("staging", ExternalMode) {
    excludeTests.set(listOf("balance", "kit", "arena"))
}

From the test itself

Two filters, meant for different problems. By capability — for a test that needs something the environment might not have. This travels with the test and doesn’t care what the environments are called:

test('give command hands over the item', { requires: { console: true, op: true } }, async ({ player }) => {
    await player.giveItem('diamond', 1);
});

Capability keys come from the environment’s own report, after it has connected:

Key	Values	Meaning
`console`	boolean	Commands can be run at all
`consoleOutput`	`full` / `responses` / `none`	Whole server log, only command answers, or nothing
`op`	boolean	The environment can grant operator status

A boolean true capability is satisfied by anything other than false, 'none' or an absent value. To demand one specific value, map it in the object:

test('console matters', { requires: { consoleOutput: 'full' } }, async ({ server }) => {
    await server.execute('say hello');
    await expect(server).toHaveReceivedMessage('hello');
});

That form exists because { requires: { console: true } } is satisfied by an RCON console that answers its own commands, while reading the server log needs a console that streams all of it. Without the distinction you get tests that neither skip nor work. By environment name — for when the difference isn’t a capability but what’s installed on that particular server:

test('the /debug dev command', { environments: ['local'] }, async ({ player }) => {
    player.chat('/debug');
});

Serial blocks filter as one

A describe.serial block is filtered whole. If any filter — a name pattern, excludeTests, requires, environments — rules out one test in the block, every test in it is skipped and reports the same reason:

  Serial block: kit lifecycle - SKIPPED ("kit lifecycle > is on cooldown right after" excluded by tests.exclude (matches "cooldown"), and a serial block runs whole or not at all)

Running half a chain is worse than running none of it: the steps left behind assert against state the skipped step was supposed to create. -PtestNames against a serial block is an all-or-nothing choice, so match the block’s name rather than one test inside it.

Skips are reported

Every skipped test lands in the report with its reason:

  Test: server logs command execution - SKIPPED (requires capability [consoleOutput:full], unavailable on "staging")

The reason is in the JSON report and in the <skipped message="…"/> element of the JUnit XML too. See Reports.

Get Started

Documentation

Environments

Maintaining

From the command line

From the build script

From the test itself

Serial blocks filter as one

Skips are reported

​From the command line

​From the build script

​From the test itself

​Serial blocks filter as one

​Skips are reported

From the command line

From the build script

From the test itself

Serial blocks filter as one

Skips are reported