Automated Cross-Browser Testing with Protractor and Selenium
Learn how Protractor used Selenium WebDriver for multi-browser tests, see the historical configuration, and plan a migration from this end-of-life stack.
Direct answer: Protractor ran end-to-end tests through WebDriverJS, the JavaScript implementation of Selenium WebDriver. Its archived configuration supported running separate browser capabilities with multiCapabilities. Protractor reached end-of-life in August 2023, so treat those examples as historical guidance for maintaining an existing suite, not as a dependable setup for a new project. For new work, choose a maintained test framework and define browser coverage from your application’s support commitments.
The Angular team’s deprecation rationale describes the end-of-life timeline, migration considerations, and alternatives. The Protractor repository is archived and read-only.
1. Protractor’s relationship to Selenium WebDriver
Protractor was a Node.js end-to-end test framework for Angular and AngularJS applications. It was built on WebDriverJS and drove a real browser through WebDriver. Its distinguishing Angular behavior was synchronization: Protractor could wait for Angular’s application state to become stable before continuing. This convenience also tied the runner to Angular-specific behavior.
Selenium WebDriver was the browser automation layer underneath Protractor. The Angular team called Selenium WebDriver the closest migration fit in API terms because Protractor used it underneath, while cautioning that the APIs were close rather than identical. Moving to Selenium is therefore not a mechanical package rename. Tests that rely on Protractor’s Angular-aware waits, locators, or control-flow behavior need deliberate changes.
The deprecation rationale names Selenium WebDriver, Cypress, Playwright, Puppeteer, TestCafe, and WebdriverIO as examples of alternatives; the list is not exhaustive or a ranking. Its survey figures are historical: close to 1,000 responses in January 2021, with fewer than 20% reporting Protractor use. They should not be read as current adoption statistics.
2. Historical Protractor multi-browser configuration
In the archived setup, capabilities selected a single browser. multiCapabilities described multiple browser sessions, and the runner executed the suite against each configuration. This example illustrates the old configuration shape; it does not establish compatibility with current browser or driver releases.
// protractor.conf.js — historical example only
exports.config = {
framework: 'jasmine',
specs: ['./e2e/**/*.spec.js'],
multiCapabilities: [
{ browserName: 'chrome' },
{ browserName: 'firefox' }
],
// Historical local WebDriver setup. Verify archived runner/driver
// compatibility before attempting to use it.
directConnect: true
};Historically, teams could also use remote provider settings. The archived configuration reference mentions BrowserStack and Sauce Labs, but that does not verify their current features or compatibility with a particular legacy Protractor installation.
For an existing suite, a safer maintenance sequence is:
- Record the Node.js, Protractor, Selenium/WebDriverJS, browser, driver, test-runner, and CI versions that currently pass.
- Preserve a known-working environment, such as a pinned CI image, while you assess migration. Avoid updating browser and driver versions independently without checking compatibility.
- Run one representative critical journey in each required browser and save logs and screenshots on failure.
- Separate Angular-specific waits and locators from ordinary element interactions. This identifies the work a migration must replace.
- Choose a maintained target based on browser needs, remote execution, framework coupling, CI operation, debugging, and migration effort.
- Move a small, high-value test first; compare its behavior and maintenance cost before migrating the full suite.
3. Decide which browsers to test
Start with the support promise your product makes, user and operational requirements, and any browser-specific risk in your application. Do not automatically test every browser or assume Angular’s framework browser support is your application’s test matrix. Angular’s current documentation defines support using a Baseline date near each major release and identifies Chrome, Edge, Firefox, and Safari as its core browser set. Your own supported versions and coverage still need to be chosen explicitly.
| Question | How it affects the matrix |
|---|---|
| Which browsers and versions does the product promise to support? | Include those targets in release confidence checks. |
| Do users depend on a particular platform or browser family? | Prioritize that environment even if it is not the default developer browser. |
| Do tests need remote browsers or operating systems unavailable in CI? | Evaluate a remote test provider and verify its current setup independently. |
| What is the suite’s runtime budget? | Run a focused critical-path matrix on every change and broader coverage on an appropriate schedule. |
Angular’s current testing overview describes WebdriverIO as a browser and mobile automation framework supporting Chrome, Firefox, Safari, and Edge. That is a documented capability, not a universal recommendation. Selenium WebDriver is a closer API transition for many Protractor suites; Playwright, Cypress, Puppeteer, TestCafe, and WebdriverIO are other candidates named in the Angular team’s rationale. Compare them against your requirements rather than treating any one as the automatic choice.
4. Migrating a test from Protractor to Selenium WebDriver
The following is a small Selenium WebDriverJS example for a Node.js project. It demonstrates a direct browser interaction without Protractor’s Angular synchronization. It assumes Selenium Server or a compatible local driver is available to Selenium’s WebDriver implementation. Browser and driver installation and version management depend on your environment; confirm them against the current Selenium documentation before adopting this in CI.
// package.json dependencies: selenium-webdriver
// Run with: node selenium-smoke.js
const { Builder, By, until } = require('selenium-webdriver');
async function main() {
const driver = await new Builder().forBrowser('chrome').build();
try {
await driver.get('https://example.com');
await driver.wait(until.titleContains('Example'), 10000);
const heading = await driver.findElement(By.css('h1')).getText();
if (!heading) throw new Error('Expected the page heading to be present');
console.log({ title: await driver.getTitle(), heading });
} finally {
await driver.quit();
}
}
main().catch((error) => {
console.error(error);
process.exitCode = 1;
});To run the same test against another browser, change forBrowser('chrome') to the target browser name supported by your installed Selenium setup and provide that browser and its compatible driver. For remote execution, configure a remote WebDriver endpoint and its provider-specific capabilities; do not copy old Protractor provider settings without checking current provider documentation.
Map old code by behavior, not just method name. Replace browser.get with driver.get; replace Protractor element lookups with Selenium’s driver.findElement(By...); use explicit waits for application conditions; and ensure driver.quit() runs in a finally block. An Angular page becoming network-idle is not necessarily equivalent to Angular becoming stable, so choose a condition that reflects the user-visible state your test needs.
5. Synchronization and migration edge cases
- Angular readiness: Selenium does not inherit Protractor’s
waitForAngularbehavior. Wait for a visible, enabled, or otherwise meaningful condition, such as a confirmation element, rather than adding arbitrary delays. - Asynchronous tests: Protractor’s historical control flow is incompatible with modern async/await patterns. Make asynchronous boundaries explicit and await each browser operation.
- AngularJS-only helpers: Protractor locators and mock-module features may be AngularJS-specific. Replace them with stable CSS or accessibility-oriented selectors and application-level test hooks where appropriate.
- Browser differences: A passing Chrome run does not establish Safari, Firefox, or Edge behavior. Keep assertions focused on user-visible outcomes and investigate genuine browser-specific failures separately from environment mismatches.
- Remote session setup: Remote providers may require capabilities, credentials, or endpoint formats that differ from archived Protractor examples. Keep secrets in CI secret storage and verify current provider requirements.
- Test isolation: Independent browser sessions need isolated data and cleanup. Parallel tests that share accounts, records, or mutable state can fail intermittently even when browser automation is healthy.
6. Reliability, performance, and cost
Cross-browser execution multiplies work: each additional browser configuration adds sessions and runtime, and remote sessions may add queueing or network variability. Keep a small, high-value browser set in fast feedback loops, then run the full committed matrix at a cadence that fits release risk and CI capacity.
Improve reliability by pinning the test environment where practical, waiting on explicit application conditions, isolating test data, collecting browser and driver logs, and capturing failure artifacts. Do not paper over instability with long fixed sleeps; they slow successful runs and can still fail under slower conditions.
Cost depends on your execution model: local or self-managed browsers consume CI capacity and maintenance time; remote browser services may charge according to their current plans and usage. The dossier does not establish current prices or capabilities for BrowserStack or Sauce Labs, so check each provider directly before budgeting. No comparative performance benchmark is available here.
7. Troubleshooting
| Symptom | Likely cause | What to do |
|---|---|---|
| Protractor install or command fails on a current runtime | The archived stack and dependencies may not support the current Node.js or browser environment. | Reproduce in the pinned historical environment to maintain the suite, then plan migration. Do not assume updating one dependency makes the stack supported. |
| Browser fails to start or session creation fails | Browser/driver mismatch, missing browser binary, or incorrect remote endpoint/capabilities. | Check exact versions, executable availability, and provider settings; verify against current driver/provider documentation. |
| Test proceeds before Angular UI is ready | The Selenium migration no longer has Protractor’s Angular-aware wait. | Wait for the specific rendered state or control needed by the test. |
| Element cannot be found | Wrong selector, element not rendered yet, iframe context, or stale page state. | Confirm the selector in the target browser, wait for visibility, and switch into the correct frame when applicable. |
| Test passes locally but fails in CI | Different browser/driver versions, timing, viewport, environment data, or shared test state. | Compare environment versions and configuration, capture logs and screenshots, isolate data, and reproduce using the CI image. |
| Suite is slow after adding browser targets | Every configured browser repeats test work; remote sessions can add waiting. | Prioritize the matrix, parallelize only with isolated state and sufficient capacity, and run broader coverage on a deliberate schedule. |
8. Or skip the browser setup
ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. It can capture a page for visual inspection; it does not replace interactive end-to-end assertions or cross-browser test coverage. The one-call API can be useful when you need a rendered page image without configuring a browser automation stack. See the ScreenshotNeo API documentation.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp- Cookie and consent banners, newsletter popups, and chat widgets are removed before the shot; each cleanup step can be turned off.
- Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing; response headers report the page verdict and billing status.
- An MCP server gives AI agents tools for screenshots, page information, and PDF capture.
- The Free plan includes 1,000 screenshots a month with no card. Paid plans start at $5 for 3,000 screenshots.
Sign up for 1,000 free screenshots a month, with no card required.
9. Frequently asked questions
Is Protractor still supported?
No. Protractor reached end-of-life in August 2023, and its GitHub repository is archived. Existing teams can preserve a pinned environment while migrating, but new projects should select a maintained option.
Can Selenium run Protractor tests directly?
No. Selenium WebDriver is the underlying automation layer, but Protractor-specific runner behavior, locators, and synchronization need to be migrated or replaced.
Does Angular’s browser support define my test matrix?
No. Use your product’s own support commitment and user requirements. Angular’s browser documentation is useful context, not a substitute for choosing application coverage.
Is Selenium the only migration choice?
No. The Angular team listed several alternatives and explicitly noted there is no one-size-fits-all choice. Select based on browser targets, remote execution, test patterns, and team needs.
