Skip to content

fix: validate execution.parallel against TestNG's own modes (#35) - #37

Merged
shossain786 merged 1 commit into
masterfrom
fix/35-parallel-mode-validation
Jul 28, 2026
Merged

shossain786 merged 1 commit into
masterfrom
fix/35-parallel-mode-validation

Conversation

@shossain786

Copy link
Copy Markdown
Contributor

Closes the two defects #35 still had open after #36 fixed the docs half.

Bug 2 — misleading error message (code)

ExecutionValidator threw "Parallel execution configuration missing" for a value that was present but not on its hand-written allowlist — sending the user hunting for config that was not absent.

The allowlist duplicated XmlSuite.ParallelMode, an enum that already exists, and the two had already drifted. Per the implementation note on #35: the value is handed straight to XmlSuite.setParallel() downstream, and nothing in the framework branches on methods vs classes — only on whether the mode is none. So tests and instances were rejected despite being legitimate TestNG modes that would have worked.

Validation now delegates to the enum, so anything TestNG accepts, Selenium Boot accepts. The rejection message names both the offending value and the valid set, read off the enum rather than a list that can drift again:

Invalid execution.parallel value 'threads' — valid values are classes, instances, methods, none, tests

A null or blank value keeps the old "missing" message, which was always accurate for that case.

Also aligned SuiteExecutionListener's own valueOf() to Locale.ROOT. Without it the validator and the consumer normalise differently, and a value that passes validation can still blow up at suite start — the same class of drift this change exists to remove.

Bug 3 — maxActiveSessions (docs)

guides/parallel.md claimed the semaphore cap "cannot exceed threadCount". Nothing enforces that — DriverManager.getOrInitSemaphore() sizes the semaphore from maxActiveSessions alone. The same file contradicted the claim twelve lines later, correctly describing threadCount: 4 with maxActiveSessions: 2.

Version gating — deliberate

The docs site deploys from master, so listing tests as valid there while v3.2.0 on Central still rejects it would recreate the original bug with the sign flipped. Both mode tables carry a note scoping the two new values to the next release. Drop the note when that release ships.

CHANGELOG.md is untouched — this repo has no "Unreleased" section convention, and changelog entries are written at version-bump time per the release checklist. Whoever cuts the next release needs to add this, or a behaviour change ships unrecorded.

Verification

  • mvn clean test — 494 tests, 0 failures (was 480). New ExecutionValidatorTest covers all five modes, case-insensitivity, both message defects as regressions, and the threadCount bounds, which had no coverage at all.
  • npm run build in docs-site/ — green.

Fixes #35

🤖 Generated with Claude Code

Bug 2 — ExecutionValidator threw "Parallel execution configuration
missing" for a value that was present but not on its hand-written
allowlist, sending the user hunting for config that was not absent.

The allowlist duplicated an enum that already exists, and the two had
already drifted: the value is handed straight to XmlSuite.setParallel()
downstream, and nothing in the framework branches on methods vs classes
— only on whether the mode is "none". So `tests` and `instances` were
rejected despite being legitimate TestNG modes that would have worked.

Validation now delegates to XmlSuite.ParallelMode, so anything TestNG
accepts, Selenium Boot accepts. An unrecognised value names both the
rejected value and the valid set, read off the enum rather than a list
that can drift again. A null or blank value keeps the old "missing"
message, which was always accurate for that case.

Also aligned SuiteExecutionListener's own valueOf() to Locale.ROOT.
Without it the validator and the consumer normalise differently, and a
value that passes validation can still blow up at suite start — the same
class of drift this change exists to remove.

Bug 3 — parallel.md claimed maxActiveSessions "cannot exceed
threadCount". Nothing enforces that; getOrInitSemaphore() sizes the
semaphore from maxActiveSessions alone. The same file contradicted the
claim twelve lines later.

Docs list the two newly-accepted modes, gated with a version note: the
docs site deploys from master, and advertising `tests` as valid while
v3.2.0 on Central still rejects it would recreate the original bug with
the sign flipped. Drop the note when the next release ships.

New ExecutionValidatorTest covers all five modes, case-insensitivity,
both message defects as regressions, and the threadCount bounds that
had no coverage. 494 tests pass (was 480); Docusaurus build green.

Fixes #35

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@shossain786
shossain786 merged commit 2d31be4 into master Jul 28, 2026
2 checks passed
@shossain786
shossain786 deleted the fix/35-parallel-mode-validation branch July 28, 2026 02:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

docs: parallel.md advertises unsupported "tests" mode; ExecutionValidator rejects it with a misleading error

1 participant