docs: fix spelling and grammar errors (#18910)

This commit is contained in:
Charles Kerr 2019-06-21 16:19:21 -05:00 committed by GitHub
parent bef9610f6a
commit 792f6b246c
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
18 changed files with 40 additions and 40 deletions

View file

@ -2,7 +2,7 @@
To write automated tests for your Electron app, you will need a way to "drive" your application. [Spectron](https://electronjs.org/spectron) is a commonly-used solution which lets you emulate user actions via [WebDriver](http://webdriver.io/). However, it's also possible to write your own custom driver using node's builtin IPC-over-STDIO. The benefit of a custom driver is that it tends to require less overhead than Spectron, and lets you expose custom methods to your test suite.
To create a custom driver, we'll use nodejs' [child_process](https://nodejs.org/api/child_process.html) API. The test suite will spawn the Electron process, then establish a simple messaging protocol:
To create a custom driver, we'll use Node.js' [child_process](https://nodejs.org/api/child_process.html) API. The test suite will spawn the Electron process, then establish a simple messaging protocol:
```js
var childProcess = require('child_process')
@ -22,7 +22,7 @@ appProcess.on('message', (msg) => {
appProcess.send({ my: 'message' })
```
From within the Electron app, you can listen for messages and send replies using the nodejs [process](https://nodejs.org/api/process.html) API:
From within the Electron app, you can listen for messages and send replies using the Node.js [process](https://nodejs.org/api/process.html) API:
```js
// listen for IPC messages from the test suite

View file

@ -1,6 +1,6 @@
# Boilerplates and CLIs
Electron development is un-opinionated - there is no "one true way" to develop,
Electron development is unopinionated - there is no "one true way" to develop,
build, package, or release an Electron application. Additional features for
Electron, both for build- and run-time, can usually be found on
[npm](https://www.npmjs.com/search?q=electron) in individual packages, allowing developers to build both

View file

@ -14,13 +14,13 @@ It's a virtual framebuffer, implementing the X11 display server protocol -
it performs all graphical operations in memory without showing any screen output,
which is exactly what we need.
Then, create a virtual xvfb screen and export an environment variable
Then, create a virtual Xvfb screen and export an environment variable
called DISPLAY that points to it. Chromium in Electron will automatically look
for `$DISPLAY`, so no further configuration of your app is required.
This step can be automated with Paul Betts's
[xvfb-maybe](https://github.com/paulcbetts/xvfb-maybe): Prepend your test
commands with `xvfb-maybe` and the little tool will automatically configure
xvfb, if required by the current system. On Windows or macOS, it will
Xvfb, if required by the current system. On Windows or macOS, it will
do nothing.
```sh
@ -51,8 +51,8 @@ For Jenkins, a [Xvfb plugin is available](https://wiki.jenkins-ci.org/display/JE
### Circle CI
Circle CI is awesome and has xvfb and `$DISPLAY`
[already setup, so no further configuration is required](https://circleci.com/docs/environment#browsers).
Circle CI is awesome and has Xvfb and `$DISPLAY`
[already set up, so no further configuration is required](https://circleci.com/docs/environment#browsers).
### AppVeyor