Merge pull request #396 from cypress-io/develop

Develop

package.json

@@ -52,7 +52,7 @@
     "cypress": "^1.3.0",
     "dependency-check": "^3.0.0",
     "deps-ok": "^1.2.0",
-    "eslint": "4.15.0",
+    "eslint": "4.16.0",
     "eslint-plugin-cypress-dev": "1.1.2",
     "fs-extra": "^5.0.0",
     "ggit": "2.4.2",
@@ -65,10 +65,10 @@
     "gulp-debug": "^3.1.0",
     "gulp-rev-all": "^0.9.7",
     "human-interval": "^0.1.6",
-    "husky": "0.14.3",
+    "husky": "0.15.0-rc.2",
     "inquirer": "^5.0.0",
     "minimist": "^1.2.0",
-    "mocha": "^4.0.1",
+    "mocha": "^5.0.0",
     "nock": "^9.0.13",
     "npm-run-all": "^4.0.2",
     "pluralize": "^7.0.0",

source/faq/questions/using-cypress-faq.md

@@ -159,7 +159,7 @@ Check out our {% url 'Google Analytics Recipe' recipes#Stubbing-Google-Analytics
 
 ## {% fa fa-angle-right %} I'm trying to test a chat application. Can I run more than one browser at a time with Cypress?
 
-{% url "We've answered this question in detail here." trade-offs#Multiple-browsers %}
+{% url "We've answered this question in detail here." trade-offs#Multiple-browsers-open-at-the-same-time %}
 
 ## {% fa fa-angle-right %} Can I test a chrome extension? How do I load my chrome extension?
 

source/guides/getting-started/writing-your-first-test.md

@@ -353,7 +353,7 @@ Notice it highlights in purple. This did three things worth noting...
 We have now **pinned** this snapshot. Hovering over other commands will not revert to them. This gives us a chance to manually inspect the DOM of our application under test at the time the snapshot was taken.
 
 ***2. Event Hitbox***
-Since {% url `.click()` click %} is an action command, that means we also a red hitbox at the coordinates the event took place.
+Since {% url `.click()` click %} is an action command, that means we also see a red hitbox at the coordinates the event took place.
 
 ***3. Snapshot Menu Panel***
 There is also a new menu panel. Some commands (like action commands) will take multiple snapshots: **before** and **after**. We can now cycle through these.

source/guides/references/roadmap.md

@@ -16,10 +16,10 @@ Feature | Status
 {% issue 1096 'Firefox Browser Support - #310' %} | In progress
 {% issue 681 'Running Multiple Specs - #681' %} | In progress
 {% issue 681 'Spec Parallelism #681' %} | In progress
+{% issue 687 'Full Network Layer Stubbing - #687' %} | In progress
 {% issue 318 'Unit Test Support - #318' %} | In progress, orthogonal to other features
 {% issue 685 'Iframe Switching APIs - #685' %} | Partially complete
 {% issue 686 'Lifecycle Events - #686' %} | Proposal complete
-{% issue 687 'Full Network Layer Stubbing - #687' %} | Proposal complete
 {% issue 310 'Cross Browser Support - #310' %} | Proposal complete
 {% issue 495 'Screenshot Diffing - #495' %} | No proposal yet
 {% issue 311 'Native Events - #311' %} | No proposal yet
@@ -31,6 +31,7 @@ Feature | Status
 {% issue 681 'Spec Load Balancing - #681' %} | Done, unreleased, orthogonal to other features
 {% issue 681 'Spec Parallelism - #681' %} | In progress
 {% issue 981 'Third Party Integrations - #981' %} | In progress
+Billing Portal with Usage data | In progress
 {% issue 448 'Capture Logs of Everything - #448' %} | Partially complete
 {% issue 495 'Screenshot Diffing - #495' %} | No proposal yet
 {% issue 688 'Improve Failure Workflow - #688' %} | No proposal yet

source/guides/references/trade-offs.md

@@ -15,7 +15,7 @@ While at first it may seem like these are strict limitations in Cypress - we thi
 - Cypress is not a general purpose {% urlHash "automation tool" Automation-restrictions %}.
 - Cypress commands run {% urlHash "inside of a browser" Inside-the-browser %}.
 - There will never be support for {% urlHash "multiple browser tabs" Multiple-tabs %}.
-- You cannot use Cypress to drive {% urlHash "two browsers at the same time" Multiple-browsers %}.
+- You cannot use Cypress to drive {% urlHash "two browsers at the same time" Multiple-browsers-open-at-the-same-time %}.
 - Each test is bound to a {% urlHash "single origin" Same-origin %}.
 
 ***Temporary trade-offs:***
@@ -81,27 +81,21 @@ cy.get('a[href="/foo"]').should('have.attr', 'target', '_blank') // so simple
 
 This principle applies to everything in Cypress. Do not test what does not need testing. It is slow, brittle, and adds zero value. Only test the underlying thing that causes the behavior you care about testing.
 
-## Multiple browsers
+## Multiple browsers open at the same time
 
-Just like with multiple tabs - Cypress will never support controlling more than 1 browser at a time.
+Just like with multiple tabs - Cypress does not support controlling more than 1 open browser at a time.
 
-However it **is possible** to use Cypress to synchronize it with another backend process - whether it is Selenium or Puppeteer to drive a 2nd browser. We have actually seen this work together quite nicely!
+However it **is possible** to synchronize Cypress with another backend process - whether it is Selenium or Puppeteer to drive a 2nd open browser. We have actually seen this work together quite nicely!
 
-With that said, except in the most unusual and rare circumstances, we do not believe in ever needing to use two browsers at the same time.
+With that said, except in the most unusual and rare circumstances, you can still test most application behavior without opening multiple browsers at the same time.
 
-Trying to do this is not scalable, it is slow, and completely unnecessary.
-
-In virtually every situation where someone asks about this functionality they will ask the question like this:
+You may ask about this functionality like this:
 
 > I'm trying to test a chat application. Can I run more than one browser at a time with Cypress?
 
 Whether you are testing a chat application or anything else - what you are really asking about is testing collaboration. But, **you don't need to recreate the entire environment in order to test collaboration with 100% coverage**.
 
-Doing it this way will be faster, more accurate, and much more scalable.
-
-Trying to spin up the entire environment is a race to the bottom. Imagine when you want to test the collaboration of 3 users, then 4 users, then 5 users. Perhaps you then want to test how your backend handles the load of dozens, hundreds, or maybe thousands of users. Would you spin up a browser to simulate the environment for each one of them?
-
-No - because you can still test all of these scenarios without involving more than 1 browser.
+Doing it this way can be faster, more accurate, and more scalable.
 
 While outside the scope of this article, you could test a chat application using the following principles. Each one will incrementally introduce more collaboration:
 
@@ -115,7 +109,7 @@ While outside the scope of this article, you could test a chat application using
 
 Avoid the server, invoke your JavaScript callbacks manually thereby simulating what happens when "notifications come in", or "users leave the chat" purely in the browser.
 
-You can easily {% url "stub" stub %} everything and simulate every single scenario. Chat messages, offline messages, connections, reconnections, disconnections, group chat, etc.  Everything that happens inside of the browser can be fully tested. Requests leaving the browser could also be stubbed and you could simply assert that the request bodies were correct.
+You can {% url "stub" stub %} everything and simulate every single scenario. Chat messages, offline messages, connections, reconnections, disconnections, group chat, etc.  Everything that happens inside of the browser can be fully tested. Requests leaving the browser could also be stubbed and you could assert that the request bodies were correct.
 
 ***2. Stub the other connection:***
 
@@ -129,7 +123,7 @@ server ← browser
 server → browser
 ```
 
-Use your server to receive messages from the browser, and simply simulate "the other participant" by sending messages as that participant. This is certainly application specific, but generally you could insert records into the database or do whatever it takes for your server to act as if a message of one client needs to be sent back to the browser.
+Use your server to receive messages from the browser, and simulate "the other participant" by sending messages as that participant. This is certainly application specific, but generally you could insert records into the database or do whatever it takes for your server to act as if a message of one client needs to be sent back to the browser.
 
 Typically this pattern enables you to avoid making a secondary WebSocket connection and yet still fulfills the bidirectional browser and server contract. This means you could also test edge cases (disconnections, etc) without actually handling real connections.
 
@@ -147,7 +141,7 @@ server ← other connection
 server → browser
 ```
 
-To do this - you  need a background process outside of the browser to make the underlying WebSocket connection that you can then communicate with and control.
+To do this - you would need a background process outside of the browser to make the underlying WebSocket connection that you can then communicate with and control.
 
 You can do this in many ways and here is a simple example of using an HTTP server to act as the client and exposing a REST interface that enables us to control it.
 
@@ -203,7 +197,7 @@ app.get('/disconnect', (req, res) => {
 app.listen(8081, () => {})
 ```
 
-This avoids ever needing a 2nd browser, but still gives you an e2e test that provides 100% confidence that two clients can communicate with each other.
+This avoids ever needing a second open browser, but still gives you an end-to-end test that provides 100% confidence that the two clients can communicate with each other.
 
 ## Same-origin