Intern
Intern is a great test stack for writing full-featured unit and functional tests, with remote WebDriver-based testing (e.g. BrowserStack) and continuous integration (e.g. Travis CI). Debugging failing tests can be a challenge if you don’t know the most efficient techniques for troubleshooting platform-specific issues or problems with your test cases.

Debugging Unit Tests

Like D.O.H, Intern has stand-alone browser support, so debugging unit tests is pretty simple and straightforward:

  • Open the test suite in the browser you want to debug the test in:
    http://localhost/my-project/node_modules/intern/client.html?config=tests/intern
  • Use your browser’s debugging tools to inspect and debug the test code

Debugging Functional Tests

Debugging is more involved when you are working with functional tests. A functional test is comprised of two parts:

  1. The test module, which defines the test actions (mouse/keyboard actions) and the test logic (assertions)
  2. The test page, which loads your application code and presents the UI that you want to test

The functional test module is run in the Node.js environment, not in the browser. The test page is run in the web browser. Communication between the two occurs through the WebDriver API:

  • Intern provides the WebDriver API using the Leadfoot library
  • Leadfoot creates HTTP requests that conform to the WebDriver API
  • A concrete WebDriver implementation, such as ChromeDriver, handles the WebDriver HTTP requests and launches and controls a web browser

As you can see, there are two potential environments to debug, Node.js and the browser. You will find it easiest to debug your test page in the browser by loading it directly, and performing as much debugging as possible detached from the test module.

Setting up a local Selenium WebDriver server

You can skip this step if you prefer to only test using a remote WebDriver provider like BrowserStack, but the reduced latency of testing an initial set of browsers locally can help you expediently resolve any initial issues. No browsers currently provide native support for the WebDriver API, so each browser requires a WebDriver implementation that will handle WebDriver API requests over HTTP and control the browser.

  • Download Selenium server (get the standalone .jar): this includes FirefoxDriver, SafariDriver, and OperaDriver
  • For Chrome and Internet Explorer support, download the appropriate driver and add the path to its executable to your PATH environment variable, making it available to Selenium server
  • Ensure that your Intern configuration is set to use your WebDriver server:
    tunnel: 'NullTunnel'
  • Launch Selenium server:
    java -jar selenium-server-standalone-2.47.1.jar
  • Continue on to the next section to launch Intern with debugging enabled…

Debugging Node.js with node-inspector

Debugging the test module (which is running in a Node.js environment) requires enabling debugging in Node.js and attaching a debugging UI using node-inspector. You will need to use a Blink-based browser like Chrome to debug, as node-inspector leverages the development tools in the Blink browser engine. (The test page can be running in any browser, but you will need a Blink-based browser to debug the test module that is executing in Node.)

node-inspector provides the node-debug command which is a drop-in replacement for node, so you will have to launch Intern’s test runner manually, rather than invoking intern-runner:

> node-debug node_modules/intern/runner config=myPackage/test/intern

This will launch the specified script (node_modules/intern/runner.js) in Node.js with debugging enabled and open the browser UI (in your default browser, so you’ll have to copy/paste the URL into Chrome or Opera if your default is not one of them). At this point you should see Chrome’s debugging UI. You can press F8 to continue script execution until your debugger statement is reached. From this point you can debug as usual. Keep in mind that in this environment, you only have access to inspect and debug the test module, not the test page.

node-inspector

This is the UI provided by node-inspector. Chrome’s developer tools are not actually open.

Debugging your test page after a failed test

After a test has failed, it is usually useful to debug a test page in the browser. Intern has an option to leave the browser running after testing completes: leaveRemoteOpen.

Test All the Browsers

We hope you find this information useful while developing effective and reliable tests. Once you are happy with your test suites, you can run them across a variety of browsers and platforms using your own Selenium Grid, BrowserStack, Sauce Labs, or TestingBot. If you encounter issues with Sauce Labs, Sauce Connect creates a log file (sauce_connect.log) in the working directory that you launch Intern from. You can also find more troubleshooting information in the Sauce Connect documentation.