Develop

package.json

@@ -134,7 +134,7 @@
   "dependencies": {
     "@contentful/rich-text-html-renderer": "13.4.0",
     "check-more-types": "2.24.0",
-    "contentful": "7.9.1",
+    "contentful": "7.10.0",
     "debug": "4.1.1",
     "docsearch.js": "2.6.3",
     "font-awesome": "4.7.0",

source/_data/plugins.yml

@@ -112,6 +112,11 @@
       link: https://github.com/bartlett705/npm-cy
       keywords: [github, actions, npm]
 
+    - name: 'vscode-cy-helper'
+      description: Visual Studio Code extension for cypress and cucumber preprocessor
+      link: https://marketplace.visualstudio.com/items?itemName=Shelex.vscode-cy-helper
+      keywords: [vscode, extension, intellisense]
+
 - name: Custom Commands
   plugins:
     - name: cy-view

source/guides/guides/continuous-integration.md

@@ -482,12 +482,40 @@ return server.start()
 node scripts/run-cypress-tests.js
 ```
 
-# Known Issues
+# Common problems and solutions
 
 ## In Docker
 
 If you are running long runs on Docker, you need to set the `ipc` to `host` mode. {% issue 350 'This issue' %} describes exactly what to do.
 
+## Xvfb
+
+When running on Linux, Cypress needs an X11 server; otherwise it spawns its own X11 server during the test run. When running several Cypress instances in parallel, the spawning of multiple X11 servers at once can cause problems for some of them. In this case, you can separately start a single X11 server and pass the server's address to each Cypress instance using `DISPLAY` variable.
+
+First, spawn the X11 server in the background at some port, for example `:99`. If you have installed `xvfb` on Linux or if you are using one of our Docker images from {% url cypress-docker-images https://github.com/cypress-io/cypress-docker-images %}, the tools below should be available.
+
+```shell
+Xvfb :99 &
+```
+
+Second, set the X11 address in an environment variable
+
+```shell
+export DISPLAY=:99
+```
+
+Start headless Cypress as usual
+
+```shell
+npx cypress run
+```
+
+After all tests across all Cypress instances finish, kill the Xvfb background process using `pkill`
+
+```shell
+pkill Xvfb
+```
+
 # See also
 
 - {% url cypress-example-kitchensink https://github.com/cypress-io/cypress-example-kitchensink#ci-status %} is set up to run on multiple CI providers.

source/guides/tooling/code-coverage.md

@@ -423,6 +423,12 @@ From now on, the front end code coverage collected during end-to-end tests will
 
 You can explore the above combined full stack coverage report at the {% url 'coveralls.io/github/cypress-io/cypress-example-realworld' https://coveralls.io/github/cypress-io/cypress-example-realworld %} dashboard.
 
+# Future work
+
+We are currently exploring two additional features for code coverage during end-to-end tests. First, we would like to avoid "manual" instrumentation step using Istanbul.js library and instead capture the native code coverage that can be collected by the Chrome browser's V8 engine. You can find a proof-of-concept example in {% url bahmutov/cypress-native-chrome-code-coverage-example https://github.com/bahmutov/cypress-native-chrome-code-coverage-example %} repository.
+
+Second, we would like to capture the code coverage from *the locally running back end server* that is serving the front end web application and handles the API requests from the web application under test. We believe that E2E tests with additional {% url "API tests" https://www.cypress.io/blog/2017/11/07/add-gui-to-your-e2e-api-tests/ %} that Cypress can perform can effectively cover a lot of back end code.
+
 # Examples
 
 You can find full examples showing different code coverage setups in the following repositories: