# mocha-node-webdriver

> An example of configuring mocha to drive in-browser tests from node via webdriver.

Latest version **0.0.1** (published 2015-06-05) · MIT license · 0 weekly downloads

## Install

```sh
npm install mocha-node-webdriver
pnpm add mocha-node-webdriver
yarn add mocha-node-webdriver
bun add mocha-node-webdriver
```

## Health

**Score 15/100 (F)** — status: abandoned.

Positive: no vulnerabilities.

Warnings: low downloads; no types; no esm support; pre 1.0.

Negative: abandoned; low maintenance score.

## Facts

| | |
|---|---|
| Version | 0.0.1 |
| Published | 2015-06-05 |
| First published | 2015-06-05 |
| Weekly downloads | 0 |
| License | MIT |
| TypeScript types | none |
| Module format | CommonJS |
| Node | ~0.10.0 |
| Dependencies | 0 |
| Known vulnerabilities | 0 |
| Install scripts | no |
| GitHub stars | 0 |
| Author | Glen E. Ivey |
| Maintainers | gleneivey |
| Keywords | node.js, mocha, selenium, webdriver, test, automation |

## Links

- npm: https://www.npmjs.com/package/mocha-node-webdriver
- Repository: https://github.com/gleneivey/mocha-node-webdriver
- Issues: https://github.com/gleneivey/mocha-node-webdriver/issues
- npm.io page: https://npm.io/package/mocha-node-webdriver

## Alternatives

- [duck](https://npm.io/package/duck.md) — 4.2M weekly downloads
- [ava](https://npm.io/package/ava.md) — 560.2K weekly downloads
- [storybook-addon-module-mock](https://npm.io/package/storybook-addon-module-mock.md) — 71.7K weekly downloads
- [@ethereum-waffle/mock-contract](https://npm.io/package/@ethereum-waffle/mock-contract.md) — 40.0K weekly downloads
- [aws-elasticsearch-connector](https://npm.io/package/aws-elasticsearch-connector.md) — 37.4K weekly downloads

## Recent versions

- 0.0.1 (latest) — 2015-06-05

## README

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 install`ed 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](https://sites.google.com/a/chromium.org/chromedriver/getting-started)
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.

---
_Source: https://npm.io/package/mocha-node-webdriver · Machine-readable twin of the npm.io package page. Health data is recomputed on every publish._