Uncategorized
1 Comment

webdriverIO tips: using browser.debug() to help debug your tests

Ever want to stop your Selenium tests halfway and try to see what your tests are seeing? Using .debug() helps but be aware of your test timeouts & context around your code.

EDIT 10/2019 - I've published a new video to my Youtube Channel where I debug a test and show you how browser.debug() alongside the VS Code Debugger. Check it out!

timeouts

Lets go over a simple use case. Going to a website and dropping you into the webdriverIO REPL:

describe('a test', function() {
  it('runs', function() {
    browser.url('https://msn.com');
    browser.debug();
    expect(true).toBeTruthy();
  });
});

Running this test does exactly what I want. It drops me into the webdriverIO REPL so that I can start interacting with the page. I'm still in the middle of the test and the expectation hasn't run yet:

[16:58:20]  DEBUG   Queue has stopped!
[16:58:20]  DEBUG   You can now go into the browser or use the command line as REPL
[16:58:20]  DEBUG   (To exit, press ^C again or type .exit)

>

The first time you run this, you'll be disappointed to see feedback about a failing test due to a timeout. Something like

> F

0 passing (15.80s)
1 failing

1) a testsuite1 runs:
Error: Timeout - Async callback was not invoked within 10000ms (set by jasmine.DEFAULT_TIMEOUT_INTERVAL)
running firefox
Error: Timeout - Async callback was not invoked within 10000ms (set by jasmine.DEFAULT_TIMEOUT_INTERVAL)
    at <Jasmine>
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)

What just happened? Your test has a default timeout of 10 seconds as defined by Jasmine. Because we're in the middle of the test, Jasmine is still keeping track of the test execution time and will kill your test because it looks like its hanging. Normally, this is what you want because if you're waiting for a selector to appear on the page, and you're on the wrong page, you want the test to fail when it can't find it in time. In this situation where I want to debug my test, its annoying because I need to change this whenever I want to use browser.debug().

You can change this in your wdio.conf.js file by changing the jasmineNodeOpts

// Options to be passed to Jasmine.
jasmineNodeOpts: {
    //
    // Change this to something really large...
    // but not too large
    defaultTimeoutInterval: 10000,

losing context

When you drop into the REPL, you lose a little bit of context. For example, with a test like this:

describe('a test', function() {
  it('runs', function() {
    browser.url('https://msn.com');
    var foo = "Bar";
    browser.debug();

    expect(true).toBeTruthy();
  });
});

Once you're in the REPL, you won't be able to see the value of foo.

[17:38:54]  DEBUG   Queue has stopped!
[17:38:54]  DEBUG   You can now go into the browser or use the command line as REPL
[17:38:54]  DEBUG   (To exit, press ^C again or type .exit)

> foo
evalmachine.<anonymous>:1
foo
^

ReferenceError: foo is not defined
    at evalmachine.<anonymous>:1:1
    at ContextifyScript.Script.runInThisContext (vm.js:50:33)

So the REPL is useful for being able to interact with the browser object while in the middle of your test, but not useful for inspecting your current context and the values of your variables. For that, we'd probably need to lean on the native node debugger, or as always..., some console.logs. You can however use it as a typical node REPL and set variables and print things to the console.

Recap

When using browser.debug() to use the webdriverIO REPL, there are 2 things you need to keep in mind

  • your test framework (in this case Jasmine) has a global default timeout which will prevent you from using the REPL productively so remember to change it to a big number when you're trying to debug
  • you'll lose context so you won't be able to see the values of existing variables.

Last week, I started working on integrating a test suite previously built using Nightwatch, and making it work with webdriverIO. While I love all of webdriverIO’s features like synchronous code when using their test runner and a REPL, there were a few things that I’d like to share which were a little hard to find in the docs or on a quick search.

In case you missed it... Each day this week, I've been posting one thing I've learned while setting up webdriverIO. Check out my previous posts here:

Beating your head against webdriverio?

Sign up to my email list and get helpful tips and lessons learned on webdriverio and automated testing.

You might also like

More Similar Posts

Menu