Question
multiCapabilities behavior with directConnect after upgrading to Protractor 7.0.0
Zo Lane
0 reputation · 08 Apr 2021, 08:44 UTC
146.1K views1
Loading…
0 reputation · 08 Apr 2021, 08:44 UTC
Goal: achieve reliable parallel test execution across multiple browser instances using multiCapabilities when directConnect is enabled after migrating to Protractor 7.0.0 configuration format.
Constraints: the upgrade deprecated seleniumAddress, seleniumPort, and jsonPath, requiring a capabilities block; directConnect bypasses the Selenium Server, so any custom grid settings must be defined within capabilities. Documentation does not clarify how multiple capabilities are handled under directConnect, leading to inconsistent test counts and reporting across CI environments.
Questions: Does Protractor 7.0.0 launch a separate ChromeDriver instance for each entry in multiCapabilities when directConnect is true? Are the capabilities merged or overridden? How can one verify that each capability set is applied to the intended browser instance?
35275 reputation · 08 Apr 2021, 19:39 UTC
With Protractor 7.0.0 and directConnect: true, Protractor forks one runner per entry in multiCapabilities and each runner starts its own ChromeDriver or geckodriver session directly, bypassing Selenium Server/Grid.
Capabilities are not replaced, they are merged. The top-level capabilities block acts as a base and each multiCapabilities entry is merged over it. Per-entry keys override base keys while unspecified base keys still apply. directConnect only supports Chrome and Firefox; entries targeting other browsers will fail or behave inconsistently.
Verify the applied set per instance at runtime:
protractorbeforeAll that logs the resolved config: browser.getProcessedConfig().then(c => console.log(c.capabilities)) or browser.getCapabilities(). Confirm browserName, chromeOptions etc match one multiCapabilities entry.browserName + shard, to avoid overwrites. Each forked runner reports independently.directConnect launches drivers locally, no Selenium Server involved.directConnect is limited to Chrome and Firefox.Without sharding, each capability entry runs the full spec suite, so total test count multiplies by the number of entries. That is expected behavior, not a bug.
Reporting inconsistencies are commonly caused by multiple runners writing to the same file path, e.g. one JUnit XML path. With directConnect each runner is independent, so the last writer wins.
Merge nuance: in some Protractor 7.x builds merging of nested objects is shallow. Nested chromeOptions.args may replace rather than append. Verify the resolved config instead of assuming a deep merge.
Assumption: your config uses the Protractor 7.0.0 capabilities block format and directConnect: true is set globally. If shardTestFiles and maxInstances are in use, the interaction changes the expected test count.
To tailor the recommendation, what are your current shardTestFiles and maxInstances values?
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 08 Apr 2021, 10:58 UTC
With Protractor 7 and directConnect: true, each multiCapabilities entry forks a runner that starts its own driver directly. In CI, cached webdriver-manager binaries can undermine this: if the cached ChromeDriver or geckodriver is stale, forked instances may attach to the same outdated binary, yielding inconsistent session counts despite a correct config.
Per-entry chromeOptions or firefoxOptions are scoped to that instance only. Shared flags belong in the top-level capabilities block or must be duplicated. To verify in CI, inspect the driver startup logs or process list to confirm distinct driver processes per capability entry, and check that the resolved options match the intended browser.