Using WebDriver to automatically check for JavaScript errors on every page (2016 edition)

Back in 2012 I wrote about how to use WebDriver to automatically check for JavaScript console errors on every page. The solution I proposed involved adding some common JavaScript to every page in your app and then checking that errors object when using WebDriver page object classes.

Fortunately since then the WebDriver project now supports checking for these errors without making any changes to your app, so if this has been stopping you doing this you can now do it quite easily.

I’ve found checking for these errors has been very useful when running end-to-end automated tests since it may pick up errors you didn’t even realize existed.

Imagine this is a page is in your app, when we visit it there doesn’t look like there’s anything wrong with the page itself, but when we open the browser console we see there’s actually an error:

console errors in browser

What we want to do is automatically check for this error; that is it doesn’t appear (we can also check it appears if we like to show how these logs work).

The first part is making sure you tell your WebDriver browser to capture errors. This is a straightforward preference:

let pref = new webdriver.logging.Preferences();
pref.setLevel( 'browser', webdriver.logging.Level.SEVERE );
driver = new webdriver.Builder().forBrowser( 'chrome' ).setLoggingPrefs( pref ).build();

We’re setting the logging level for just the browser (not the driver itself) The SEVERE level means to log console errors only, there’s also options for AL, and OFF (and a few others).

Once we’ve set that, all we need to do is ask the driver for it’s browser logs:

  driver.manage().logs().get( 'browser' )

Since I’m using page objects, I can add a function to the base page object class so that all pages expose their error logs:

import webdriver from 'selenium-webdriver';
import config from 'config';
import { map } from 'lodash';

const until = webdriver.until;

export default class BasePage {
	constructor( driver, expectedElementSelector, visit = false, url = null ) {
		this.explicitWaitMS = config.get( 'explicitWaitMS' );
		this.driver = driver;
		this.expectedElementSelector = expectedElementSelector;
		this.url = url;

		if ( visit ) this.driver.get( this.url );

		this.driver.wait( until.elementLocated( this.expectedElementSelector ), this.explicitWaitMS );

	consoleErrors() {
		return this.driver.manage().logs().get( 'browser' ).then( ( logs ) => {
			return map( logs, ( log ) => log.message );
		} );

This means it’s easy to access these consoleErrors from your tests like mocha: 'can check for errors when there should be none', function() {
		let page = new WebDriverJsDemoPage( driver, true );
		page.consoleErrors().then( ( errors ) => {
			assert.deepEqual( errors, [] );
		} );
	} ); 'can check for errors when there are present', function() {
		let page = new WebDriverJsErrorPage( driver, true );
		page.consoleErrors().then( ( errors ) => {
			assert.deepEqual( errors, [ ' 1:1 Uncaught Purple Monkey Dishwasher Error' ] );
		} );
	} );

So there you have it. Checking for console JavaScript errors without any modifications to your app.

All the source code for these examples is available on Github.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

16 thoughts on “Using WebDriver to automatically check for JavaScript errors on every page (2016 edition)”

  1. Hi Alster!

    First of all thanks for your posts, they are so enlightening!

    Do you know if this is also possible with the WebDriver C# bindings? I can´t find a working solution..

    Liked by 1 person

      1. Hi Alister, thanks for the super-quick answer!

        I’ve been playing around with it but it doesn’t work 100%. For example the JS error in your example page shows with a level of “All”, instead of “ERROR”.

        It might be related to that:

        Liked by 1 person

  2. Thanks for the post. I didn’t know the support is there now in WebDriver. Is this specifically documented somewhere with regard to the feature?

    And is this supported across browsers, or only works for some (FF, Chrome, vs IE, Safari)? I hope the functionality is available across (supported) language bindings, and ideally exposed as part of JSONWireProtocol so that 3rd party bindings can also make use of it.

    Liked by 1 person

  3. Hi Alister, Have you come up with / come across a way to highlight elements the test is interacting with “automatically”? This especially would be very valuable when we see screenshots after the tests executes in CI – to know where the interaction was really happening.

    Liked by 1 person

    1. No I haven’t but that sounds useful – I’ll think about how to do that. Possibly executing some JavaScript to do this would work, I don’t think WebDriver has a highlight method – I remember that Watir used to.


    2. “highlight elements with selenium webdriver” is covered by various posts already if you search it online, such as and

      As for the “automatic” part, I may be mistaken but I don’t recall any test framework that offers that built in. So one likely has to extend WebDriver or their test framework of choice to enable that feature automatically (per element action or on test failures, etc.)

      Liked by 1 person

      1. There definitely are ways to highlight elements – see this for ex:

        But I was wondering if there can be a way to automatically do this – maybe for specific set of actions – click, input, select, etc. One thing I am thinking of now – is have specific library functions for these actions – which will highlight and do that action – instead of the highlight code being spread all over the framework.

        Can you think of a better way?

        Liked by 1 person

        1. I think that sounds like a reasonable approach. Depends on your programming language – I know C# allows you to using extension methods on interfaces which would allow you to do this neatly which I don’t believe would work in JavaScript on Node.

          My one hesitation about doing something like this would be any increase in execution time, as some of those links use sleeping to highlight elements for a certain period of time before unhighlighting and continuing. If this meant much longer execution times I would probably not do it.


        2. I don’t think there’s much alternative for the automatic incorporation of highlighting than to do it at the WebDriver level (subclass/extend one of the driver classes), or at the test framework level (whatever framework is chosen).

          Although for those language bindings that provide it, EventFiringWebDriver might be one way to go. By mapping those click, input, select, type actions as events to trigger other actions automatically. I’m not aware whether this feature is available across language bindings or not. Some examples for reference:

          Liked by 1 person

Comments are closed.