mocha-node-webdriver v0.0.1

mocha-node-webdriver

An example of using mocha to write web app integration tests that run in node.js and execute through a browser using Selenium WebDriver.

This repository contains a minimal configuration for writing integration tests:

• in JavaScript
• that execute in node.js
• written for the mocha test-runner
• using selenium-webdriver to control a browser
• that can access either remote or local servers
• which start/stop the local server instance as needed

There is a trivial web "application" for use as a test target under the directory local_server. It has its own package.json file and has to be npm installed separately, but is otherwise boring.

To run the tests in this example, you'll need to have git, node, npm, and the Chrome browser installed already. If you don't, or the versions don't match this code's requirements, error messages will let you know. In addition, setup chromedriver for your system Once prerequisites in place, follow these steps particular to this example:

1. go to somewhere you want to keep your local copy of this repository
2. git clone https://github.com/gleneivey/mocha-node-webdriver.git
3. cd mocha-node-webdriver
4. npm install
5. cd local_server
6. npm install
7. cd ..
8. grunt

The Gruntfile in this example defines three tasks, including the default which is a union of the other two. grunt local launches a local web server, opens the Chrome browser, and then navigates the browser to the server (localhost:3000) to execute a handful of trivial tests. grunt remote launches Chrome and perform tests against two common public web services. Simply executing grunt runs both sets of tests. If you've been able to install and things are configured correctly, mocha should run and report "6 passing" tests.

Details of Note

• The default grunt task which runs all the tests does not simply invoke the other two tasks. Instead, it has its own mochacli configuration that covers all the test files. Composing the other two tasks would run mocha twice, which would cause the test browser to be launched and closed twice.
• There are several things that would be configureable in a real system (the local server port, test file paths, etc.) that have been hard-coded for simplicity/clarity.
• Integration tests are slow. The file test/mocha.opts is used to increase mocha's default test timeout from 2 seconds to 30 seconds. Hopefully this is high enough to accommodate any system you're trying to run these tests on, but if you get timeout failures, try increasing the value here.
• The file test/for_all_tests.js contains code that puts the driver variable into the global name space, as well as mocha before() and after() calls that initialize and close the browser and WebDriver sessions. This file must be included in the file list given to mocha, and cannot be named by the --require option or required from within the test files.
• The remote tests don't perform a search on www.google.com like many other Selenuim WebDriver examples do. It turns out that it's actually difficult for Chrome to navigate off a Google results page with a simple driver.get(). When putting this example together, the results page was constantly "navigating" itself (to check to see if it could sing in to Google+, etc.), and the Selenium-requested navigation worked less than 10% of the time.