mirror of
https://github.com/cypress-io/cypress.git
synced 2026-04-28 10:49:48 -05:00
docs: remove hr's / fix some syntax
This commit is contained in:
Jennifer Shehane
@@ -30,8 +30,6 @@ Within Cypress, you have the ability to choose whether to stub responses or allo
|
||||
|
||||
Let's investigate both strategies, why you would use one versus the other, and why you should regularly use both.
|
||||
|
||||
***
|
||||
|
||||
## Option 1: Don't Stub Responses
|
||||
|
||||
Requests that aren't stubbed will actually reach your server. By *not* stubbing your responses, you are writing true **end to end** tests. This means you are driving your application the same way a real user would.
|
||||
@@ -65,8 +63,6 @@ If you are writing a traditional server-side application where most of the respo
|
||||
- Helpful to have one test around the *happy path* of a feature
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
## Option 2: Stub Responses
|
||||
|
||||
Stubbing responses enables you to control every aspect of the response, including the response body, the status, headers, and even network delay. Stubbing is extremely fast, most responses will be returned in less than 20ms.
|
||||
@@ -94,8 +90,6 @@ You don't have to do any work on the server. Your application will have no idea
|
||||
- Mix and match, typically have one true end to end test, and then stub the rest
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
# How to stub responses
|
||||
|
||||
Cypress makes it easy to stub a response and control the `body`, `status`, `headers`, or even delay.
|
||||
@@ -109,8 +103,6 @@ These two commands work together to control the behavior of your responses withi
|
||||
|
||||
[`cy.server`](https://on.cypress.io/api/server) enables stubbing, while [`cy.route`](https://on.cypress.io/api/route) provides a routing table so Cypress understands which response should go with which request.
|
||||
|
||||
***
|
||||
|
||||
# Requests
|
||||
|
||||
Cypress will automatically indicate when an XHR request happens in your application. These are logged in the Command Log regardless of whether or not you are using stubbing. This provides you a visual indicator when a request has started and when it is finished. Additionally, Cypress will take a snapshot of the DOM when the request is made and another snapshot when the response comes back.
|
||||
@@ -119,23 +111,20 @@ By default, Cypress is configured to *ignore* requests that are used to fetch st
|
||||
|
||||
Cypress automatically collects the request `headers` and the request `body` and will make this available to you.
|
||||
|
||||
***
|
||||
|
||||
# Server + Routing Table
|
||||
|
||||
```javascript
|
||||
cy
|
||||
// enable response stubbing
|
||||
.server()
|
||||
// enable response stubbing
|
||||
cy.server()
|
||||
|
||||
// Route all GET requests that have a
|
||||
// URL that matches the RegExp /users/
|
||||
// and force the response to be: []
|
||||
.route({
|
||||
method: "GET",
|
||||
url: /users/,
|
||||
response: []
|
||||
})
|
||||
// Route all GET requests that have a
|
||||
// URL that matches the RegExp /users/
|
||||
// and force the response to be: []
|
||||
cy.route({
|
||||
method: "GET",
|
||||
url: /users/,
|
||||
response: []
|
||||
})
|
||||
```
|
||||
|
||||
Each [`cy.route`](https://on.cypress.io/api/route) you provide will automatically route those requests to specific responses and control their body, response headers, or even force additional network delay.
|
||||
@@ -149,28 +138,24 @@ Once you start a server with [`cy.server`](https://on.cypress.io/api/server), al
|
||||
- [`cy.server`](https://on.cypress.io/api/server)
|
||||
- [`cy.route`](https://on.cypress.io/api/route)
|
||||
|
||||
***
|
||||
|
||||
# Fixtures
|
||||
|
||||
When stubbing a response, you typically need to manage potentially large and complex JSON objects. Cypress has support for [fixtures](https://on.cypress.io/guides/creating-fixtures), and even allows you to integrate fixture syntax directly into responses.
|
||||
|
||||
```javascript
|
||||
cy
|
||||
.server()
|
||||
cy.server()
|
||||
|
||||
// we set the response to be the activites.json fixture
|
||||
.route("GET", /activities/, "fixture:activities.json")
|
||||
// we set the response to be the activites.json fixture
|
||||
cy.route("GET", /activities/, "fixture:activities.json")
|
||||
```
|
||||
|
||||
You can additionally reference [aliases](https://on.cypress.io/guides/using-aliases) within responses. These aliases do not have to point to fixtures, but that is a common use case. Separating out a fixture enables you to work and mutate that object prior to handing it off to a response.
|
||||
|
||||
```javascript
|
||||
cy
|
||||
.server()
|
||||
cy.server()
|
||||
|
||||
.fixture("activities.json").as("activitiesJSON")
|
||||
.route("GET", /activities/, "@activitiesJSON")
|
||||
cy.fixture("activities.json").as("activitiesJSON")
|
||||
cy.route("GET", /activities/, "@activitiesJSON")
|
||||
```
|
||||
|
||||
***
|
||||
@@ -180,22 +165,21 @@ cy
|
||||
Whether or not you choose to stub responses, Cypress enables you to declaratively [`cy.wait`](https://on.cypress.io/api/wait) for requests and their responses.
|
||||
|
||||
```javascript
|
||||
cy
|
||||
.server()
|
||||
.route(/activities/, "fixture:activities").as("getActivities")
|
||||
.route(/messages/, "fixture:messages").as("getMessages")
|
||||
cy.server()
|
||||
cy.route(/activities/, "fixture:activities").as("getActivities")
|
||||
cy.route(/messages/, "fixture:messages").as("getMessages")
|
||||
|
||||
// visit the dashboard, which should make requests that match
|
||||
// the two routes above
|
||||
.visit("http://localhost:8888/dashboard")
|
||||
// visit the dashboard, which should make requests that match
|
||||
// the two routes above
|
||||
cy.visit("http://localhost:8888/dashboard")
|
||||
|
||||
// pass an array of Route Aliases which forces Cypress to wait
|
||||
// until it sees a response for each request that matches
|
||||
// each of these aliases
|
||||
.wait(["@getActivities", "@getMessages"])
|
||||
// pass an array of Route Aliases which forces Cypress to wait
|
||||
// until it sees a response for each request that matches
|
||||
// each of these aliases
|
||||
cy.wait(["@getActivities", "@getMessages"])
|
||||
|
||||
// these commands will not run until the wait command resolves above
|
||||
.get("h1").should("contain", "Dashboard")
|
||||
// these commands will not run until the wait command resolves above
|
||||
cy.get("h1").should("contain", "Dashboard")
|
||||
```
|
||||
|
||||
Declaratively waiting for responses has many advantages:
|
||||
@@ -203,8 +187,6 @@ Declaratively waiting for responses has many advantages:
|
||||
- Source of failure is clearer
|
||||
- You can make assertions about the XHR objects
|
||||
|
||||
***
|
||||
|
||||
## Removing Flake
|
||||
|
||||
One advantage of declaratively waiting for requests is that it decreases test flake. You can think of [`cy.wait`](https://on.cypress.io/api/wait) as a guard that indicates to Cypress when you expect a request to be made that matches a specific routing alias. This prevents commands from running until responses come back and it guards against situations where your requests are initially delayed.
|
||||
@@ -212,29 +194,26 @@ One advantage of declaratively waiting for requests is that it decreases test fl
|
||||
**Auto-complete Example:**
|
||||
|
||||
```javascript
|
||||
cy
|
||||
.server()
|
||||
.route(/search/, [{item: "Book 1"}, {item: "Book 2"}]).as("getSearch")
|
||||
cy.server()
|
||||
cy.route(/search/, [{item: "Book 1"}, {item: "Book 2"}]).as("getSearch")
|
||||
|
||||
// our autocomplete field is throttled
|
||||
// meaning it only makes a request after
|
||||
// 500ms from the last keyPress
|
||||
.get("#autocomplete").type("Book")
|
||||
// our autocomplete field is throttled
|
||||
// meaning it only makes a request after
|
||||
// 500ms from the last keyPress
|
||||
cy.get("#autocomplete").type("Book")
|
||||
|
||||
// wait for the request + response
|
||||
// thus insulating us from the
|
||||
// throttled request
|
||||
.wait("@getSearch")
|
||||
// wait for the request + response
|
||||
// thus insulating us from the
|
||||
// throttled request
|
||||
cy.wait("@getSearch")
|
||||
|
||||
.get("#results")
|
||||
.should("contain", "Book 1")
|
||||
.and("contain", "Book 2")
|
||||
cy.get("#results")
|
||||
.should("contain", "Book 1")
|
||||
.and("contain", "Book 2")
|
||||
```
|
||||
|
||||
What makes this example above so powerful is that Cypress will automatically wait for a request that matches the `getSearch` alias. Instead of forcing Cypress to test the *side effect* of a successful request (the display of the Book results), you can test the actual *cause* of the results.
|
||||
|
||||
***
|
||||
|
||||
## Clear Source of Failure
|
||||
|
||||
In our example above, we added an assertion to the display of the search results.
|
||||
@@ -253,8 +232,6 @@ With Cypress, by adding a [`cy.wait`](https://on.cypress.io/api/wait) guard, you
|
||||
|
||||
Now we know exactly why our test failed. It had nothing to do with the DOM. Instead we can see that either our request never went out or a request went out to the wrong URL.
|
||||
|
||||
***
|
||||
|
||||
## Asserting about the XHR Object
|
||||
|
||||
Another benefit of using [`cy.wait`](https://on.cypress.io/api/wait) on requests is that it allows you to access the actual `XHR` object. This is useful when you want to make assertions about this object.
|
||||
@@ -262,20 +239,19 @@ Another benefit of using [`cy.wait`](https://on.cypress.io/api/wait) on requests
|
||||
In our example above we can assert about the request object to verify that it sent data as a query string in the URL. Although we're mocking the response, we can still verify that our application sends the correct request.
|
||||
|
||||
```javascript
|
||||
cy
|
||||
.server()
|
||||
.route(/search/, [{item: "Book 1"}, {item: "Book 2"}]).as("getSearch")
|
||||
cy.server()
|
||||
cy.route(/search/, [{item: "Book 1"}, {item: "Book 2"}]).as("getSearch")
|
||||
|
||||
.get("#autocomplete").type("Book")
|
||||
cy.get("#autocomplete").type("Book")
|
||||
|
||||
// this yields us the XHR object which includes
|
||||
// fields for request, response, url, method, etc
|
||||
.wait("@getSearch")
|
||||
.its("url").should("include", "/search?query=Book")
|
||||
// this yields us the XHR object which includes
|
||||
// fields for request, response, url, method, etc
|
||||
cy.wait("@getSearch")
|
||||
.its("url").should("include", "/search?query=Book")
|
||||
|
||||
.get("#results")
|
||||
.should("contain", "Book 1")
|
||||
.and("contain", "Book 2")
|
||||
cy.get("#results")
|
||||
.should("contain", "Book 1")
|
||||
.and("contain", "Book 2")
|
||||
```
|
||||
|
||||
**The XHR object that [`cy.wait`](https://on.cypress.io/api/wait) yields you has everything you need to make assertions including:**
|
||||
|
||||
@@ -16,8 +16,6 @@ Cypress comes built in with the ability to [`stub`](https://on.cypress.io/api/st
|
||||
|
||||
These commands are useful when writing both **unit tests** and **integration tests**.
|
||||
|
||||
***
|
||||
|
||||
# Libraries and Tools
|
||||
|
||||
Cypress automatically bundles and wraps these libraries:
|
||||
@@ -31,8 +29,6 @@ Cypress automatically bundles and wraps these libraries:
|
||||
|
||||
You can refer to each of these libraries documentation for more examples and explanations.
|
||||
|
||||
***
|
||||
|
||||
# Common Scenarios
|
||||
|
||||
{% note info Example test! %}
|
||||
@@ -81,8 +77,6 @@ You generally stub a function when it has side effects you are trying to control
|
||||
[Read more about how to use cy.stub](https://on.cypress.io/api/stub)
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
## Spies
|
||||
|
||||
A spy gives you the ability to "spy" on a function, by being able to capture and then assert that the function was calling with the right arguments, or that the function was called a certain number of times, or even what the return value or context the function was called with.
|
||||
@@ -97,8 +91,6 @@ cy.spy(obj, "method")
|
||||
[Read more about how to use cy.spy](https://on.cypress.io/api/spy)
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
## Clock
|
||||
|
||||
There are situations when it is useful to control your applications `date` and `time` in order to force its behavior or avoid slow tests.
|
||||
@@ -117,17 +109,14 @@ There are situations when it is useful to control your applications `date` and `
|
||||
Once you've enabled [`cy.clock`](https://on.cypress.io/api/clock) you can then control time by **ticking** it ahead by milliseconds.
|
||||
|
||||
```javascript
|
||||
cy
|
||||
.clock()
|
||||
.visit("http://localhost:3333")
|
||||
.get("#search").type("foobarbaz")
|
||||
.tick(1000)
|
||||
cy.clock()
|
||||
cy.visit("http://localhost:3333")
|
||||
cy.get("#search").type("foobarbaz")
|
||||
cy.tick(1000)
|
||||
```
|
||||
|
||||
[`cy.clock`](https://on.cypress.io/api/clock) is special in that it can be called **prior** to visiting your application, and we will automatically bind it to the application on the next [`cy.visit`](https://on.cypress.io/api/visit). We bind **before** any timers from your application can be invoked. This works identically to [`cy.server`](https://on.cypress.io/api/server) + [`cy.route`](https://on.cypress.io/api/route).
|
||||
|
||||
***
|
||||
|
||||
## Assertions
|
||||
|
||||
Once you have a `stub` or a `spy` in hand, you can then create assertions about them.
|
||||
@@ -183,8 +172,6 @@ expect(user.updateEmail).to.have.returned("jane@devs.com") // true
|
||||
expect(user.fail).to.have.thrown("Error") // true
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
# Integration and Extensions
|
||||
|
||||
Beyond just integrating these tools together we have also extended and improved the collaboration of these tools.
|
||||
|
||||
@@ -9,8 +9,6 @@ When you're ready to start testing, Cypress launches the browser for you. It doe
|
||||
1. To create a clean, pristine testing environment.
|
||||
2. To access the exclusive browser API's for automation.
|
||||
|
||||
***
|
||||
|
||||
# Launching Browsers
|
||||
|
||||
When Cypress is initially [run from the Desktop application](https://on.cypress.io/guides/installing-and-running#section-running-tests-from-the-gui), you can choose to run Cypress in a select number of browsers including:
|
||||
@@ -39,22 +37,16 @@ Additionally, we've made the browsers spawned by Cypress look different than reg
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Electron Browser
|
||||
|
||||
In addition to the browsers found on your system, you'll notice that `Electron` is another available browser (it may be the only browser if Cypress does not detect any compatible browsers on your system). The `Electron` browser is a version of Chrome that is bundled with [Electron](https://electron.atom.io/) (the platform underlying the Cypress app). Cypress uses it when running headless via `cypress run`. It may be useful for debugging issues that only occur when running headless.
|
||||
|
||||
The `Electron` browser does not have its own Dock icon or any chrome (address bar, tabs, bookmarks, etc).
|
||||
|
||||
***
|
||||
|
||||
## Unsupported Browsers
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
# Clean Testing Environment
|
||||
|
||||
When we launch browsers we open them in a way that makes testing more reliable and accessible. We do this in three ways:
|
||||
@@ -63,8 +55,6 @@ When we launch browsers we open them in a way that makes testing more reliable a
|
||||
2. Disabling virtually everything that gets in the way of testing
|
||||
3. Enabling access to browser automation API's
|
||||
|
||||
***
|
||||
|
||||
## Cypress Profile
|
||||
|
||||
Cypress generates its own isolated profile away from your regular browsing profile. This means things like `history` entries, `cookies`, and `3rd party extensions` from your regular browsing session will not affect Cypress.
|
||||
@@ -75,8 +65,6 @@ Wait, I need my developer extensions such as React Dev Tools, Batarang, or Ember
|
||||
|
||||
That's no problem - you simply have to reinstall them **once**. We'll continue to use this Cypress testing profile on subsequent launches so all of your configuration will automatically be preserved. Note that in the [Electron browser](#section-electron-browser), while it's possible to use the dev tools, it's not possible to install developer extensions.
|
||||
|
||||
***
|
||||
|
||||
## Testing Barriers
|
||||
|
||||
Cypress automatically disables certain functionality in your browser which can get in the way of automated testing.
|
||||
@@ -93,21 +81,13 @@ For instance we will automatically:
|
||||
- Disable a ton of background network traffic
|
||||
- Disable background and renderer throttling
|
||||
|
||||
***
|
||||
|
||||
## Tabbed Browsing
|
||||
|
||||
***
|
||||
|
||||
# Automation API's
|
||||
|
||||
## Cypress Extension
|
||||
<talk about not using the debugger protocol>
|
||||
|
||||
***
|
||||
|
||||
## Browser Drivers
|
||||
|
||||
***
|
||||
|
||||
## No Selenium Server
|
||||
|
||||
@@ -17,8 +17,6 @@ It provides a set of commands that can be used to do things like:
|
||||
You generally install the CLI tool so you can progamatically install and run Cypress. This is commonly used when running Cypress from your CI provider.
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
# Installation
|
||||
|
||||
```shell
|
||||
@@ -29,8 +27,6 @@ This will make the `cypress` command globally available from your command line.
|
||||
|
||||
You can now execute the following commands:
|
||||
|
||||
***
|
||||
|
||||
# Available Commands
|
||||
|
||||
## `cypress install`
|
||||
@@ -56,8 +52,6 @@ Additionally if you have a `CYPRESS_VERSION` environment variable set, it will a
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## `cypress update`
|
||||
|
||||
Updates Cypress to the latest version. This does the same thing as `cypress install`.
|
||||
@@ -67,8 +61,6 @@ Updates Cypress to the latest version. This does the same thing as `cypress inst
|
||||
cypress update
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## `cypress run`
|
||||
|
||||
Runs Cypress headlessly without spawning a browser.
|
||||
@@ -123,8 +115,6 @@ cypress run --config pageLoadTimeout=100000,watchForFileChanges=false
|
||||
|
||||
You can read more about [environment variables](https://on.cypress.io/environment-variables) and [configuration](https://on.cypress.io/configuration) here.
|
||||
|
||||
***
|
||||
|
||||
## `cypress run --record`
|
||||
|
||||
You can also have your test runs recorded [once your project is setup to record](https://on.cypress.io/guides/projects).
|
||||
@@ -151,8 +141,6 @@ cypress run --record
|
||||
|
||||
You can [read more](https://on.cypress.io/how-do-i-record-runs) about recording runs here.
|
||||
|
||||
***
|
||||
|
||||
## `cypress open`
|
||||
|
||||
Opens the Cypress application. This is the same thing as double-clicking the application.
|
||||
@@ -176,20 +164,14 @@ cypress open --config pageLoadTimeout=100000,watchForFileChanges=false
|
||||
cypress open --env host=api.dev.local
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## `cypress get:path`
|
||||
|
||||
Returns the path Cypress will be installed to. Additionally checks to see if Cypress already exists at that path.
|
||||
|
||||
***
|
||||
|
||||
## `cypress verify`
|
||||
|
||||
Verifies that the Cypress application is found.
|
||||
|
||||
***
|
||||
|
||||
## `cypress version`
|
||||
|
||||
Outputs both the version of the CLI Tool and the installed Cypress application.
|
||||
|
||||
@@ -157,15 +157,14 @@ export "EXTERNAL_API_SERVER=https://corp.acme.co"
|
||||
And then in your tests:
|
||||
|
||||
```javascript
|
||||
cy
|
||||
.request({
|
||||
method: "POST",
|
||||
url: Cypress.env("EXTERNAL_API_SERVER") + "/users/1",
|
||||
body: {
|
||||
foo: "bar",
|
||||
baz: "quux"
|
||||
}
|
||||
})
|
||||
cy.request({
|
||||
method: "POST",
|
||||
url: Cypress.env("EXTERNAL_API_SERVER") + "/users/1",
|
||||
body: {
|
||||
foo: "bar",
|
||||
baz: "quux"
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
Refer to the dedicated [Environment Variables Guide](https://on.cypress.io/guides/environment-variables) for more examples.
|
||||
|
||||
@@ -20,8 +20,6 @@ Additionally we've integrated the dashboard into the Cypress [Desktop Applicatio
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Example Projects
|
||||
|
||||
Once you're logged into the [Dashboard](https://on.cypress.io/dashboard) you can view any [public project](https://on.cypress.io/what-is-project-access).
|
||||
@@ -34,8 +32,6 @@ Here are some of our own public projects you can look at:
|
||||
- [cypress-example-todomvc](https://dashboard.cypress.io/#/projects/245obj)
|
||||
- [cypress-example-piechopper](https://dashboard.cypress.io/#/projects/fuduzp)
|
||||
|
||||
***
|
||||
|
||||
# Frequently Asked Questions
|
||||
|
||||
## How do I record my tests?
|
||||
@@ -45,8 +41,6 @@ Here are some of our own public projects you can look at:
|
||||
|
||||
After recording your tests, you will see them in the Dashboard and in the Desktop Application.
|
||||
|
||||
***
|
||||
|
||||
## How is this different than CI?
|
||||
|
||||
Cypress is **complimentary** to your CI provider, and plays a completely different role.
|
||||
@@ -59,8 +53,6 @@ Our dashboard provides you with the low level details of *what* happened during
|
||||
|
||||
When a run happens and a test fails - instead of going and inspecting your CI provider's `stdout` output, you can log into the [Dashboard](https://on.cypress.io/dashboard) and see all of the test run results. It should be instantly clear what the problem was.
|
||||
|
||||
***
|
||||
|
||||
## How much does this cost?
|
||||
|
||||
Everything is free while we are in Beta.
|
||||
@@ -72,14 +64,11 @@ Public projects will be free but will likely have a monthly usage cap on them.
|
||||
We will offer similar pricing models of other Developer Tools you are familiar with using.
|
||||
|
||||
Plans will likely start around the $99/month level.
|
||||
***
|
||||
|
||||
## Can I host this myself?
|
||||
|
||||
No, although we are looking to build an on-premise version of the Dashboard for use in private clouds. If you're interested in our on-premise version, [let us know](mailto:hello@cypress.io)!
|
||||
|
||||
***
|
||||
|
||||
## Can I choose not to use it?
|
||||
|
||||
Of course. The dashboard is a separate service from the Desktop Application and will always remain optional. We hope you'll find a tremendous amount of value out of it, but it is not coupled to being able to run your tests.
|
||||
|
||||
@@ -31,14 +31,10 @@ You cannot delete or edit the name of this organization.
|
||||
All existing Cypress projects prior to version 0.19.0 were automatically added to your personal organization.
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
# Creating an Organization
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Inviting Users
|
||||
|
||||
You can invite users to Cypress from our [Dashboard](https://on.cypress.io/dashboard). Invited users will see the projects and runs for your organization.
|
||||
@@ -54,8 +50,6 @@ Even though we are in a **private beta**, any user you invite will automatically
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## User Roles
|
||||
|
||||
User's can be assigned roles that affect their access to certain features.
|
||||
@@ -64,8 +58,6 @@ User's can be assigned roles that affect their access to certain features.
|
||||
- **Admin:** Can also invite, edit and delete users.
|
||||
- **Owner:** Can also transfer or delete projects. Can delete and edit the organization.
|
||||
|
||||
***
|
||||
|
||||
## User Requests
|
||||
|
||||
We have also built Cypress with the ability for users to "Request" access to a given organization. This makes for a very natural flow.
|
||||
@@ -76,8 +68,6 @@ This means instead of you having to invite team members up front, they can simpl
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Transferring Projects
|
||||
|
||||
You can transfer projects that you own to another organization or another user.
|
||||
@@ -86,8 +76,6 @@ This functionality only exists in our [Dashboard](https://on.cypress.io/dashboar
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
# Deleting an Organization
|
||||
|
||||
You can delete organizations that you own as long as they don't have any projects. You must first transfer ownership of your projects to another organization before you can delete them.
|
||||
|
||||
@@ -8,8 +8,6 @@ A Cypress project represents the directory of files and folders that make up you
|
||||
|
||||
This is often the same repository as your code, but can also be a subfolder or a separate repository altogether.
|
||||
|
||||
***
|
||||
|
||||
# Adding a new Project
|
||||
|
||||
Projects can **only** be added to Cypress through our [Desktop Application](https://on.cypress.io/guides/installing-and-running).
|
||||
@@ -22,8 +20,6 @@ Projects can **only** be added to Cypress through our [Desktop Application](http
|
||||
Projects added in our Desktop Application are strictly local to your computer. They are not tracked in any way by Cypress servers and do not communicate with us until they are [setup to be recorded](#section-recording-runs).
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
# Setting up a Project to Record
|
||||
|
||||
You can also setup your project to have its test runs recorded and displayed in both the Desktop Application and the Dashboard.
|
||||
@@ -62,8 +58,6 @@ During a run we record all failing tests, logs, screenshots, and videos.
|
||||
|
||||
You are now ready to record your runs. Typically you would record your runs when running in [Continuous Integration](https://on.cypress.io/guides/continuous-integration) but you can also record your runs from your local computer.
|
||||
|
||||
***
|
||||
|
||||
## How do I record runs?
|
||||
|
||||
Now that your project is setup, Cypress has inserted your unique [projectId](#section-what-is-a-projectid-) into `cypress.json`.
|
||||
@@ -96,16 +90,13 @@ Once tests run, you will see them show up in the [Dashboard](https://on.cypress.
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## What is a projectId?
|
||||
|
||||
Once you setup your project to record, we generate a unique `projectId` for your project, and automatically insert it into your `cypress.json` file.
|
||||
|
||||
**The `projectId` is a 6 character string in your cypress.json:**
|
||||
|
||||
```javascript
|
||||
// cypress.json
|
||||
```json
|
||||
{
|
||||
"projectId": "a7bq2k"
|
||||
}
|
||||
@@ -113,8 +104,6 @@ Once you setup your project to record, we generate a unique `projectId` for your
|
||||
|
||||
This is how we uniquely identify your project. If you manually alter this, **Cypress will no longer be able to identify your project or find the recorded builds for it**. We recommend that you check your `cypress.json` including the `projectId` into source control.
|
||||
|
||||
***
|
||||
|
||||
## What is a Record Key?
|
||||
|
||||
Once you're setup to record test runs, we automatically generate a **Record Key** for the project.
|
||||
@@ -133,8 +122,6 @@ You can also find your Record Key inside of the **Settings** tab.
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## How do a projectId and Record Key work together?
|
||||
|
||||
Cypress uses your `projectId` and **Record Key** together to uniquely identify projects.
|
||||
@@ -151,8 +138,6 @@ Think of your record key as the key that enables you to **write and create** bui
|
||||
If your Record Key is accidentally exposed, you simply need to remove it and generate a new one from our [Dashboard](https://on.cypress.io/dashboard).
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
## What is the difference between public and private projects?
|
||||
|
||||
**A public project** means that anyone can see the recorded runs for it. It's similar to how public projects on Github, Travis, or Circle are handled. Anyone who knows your `projectId` will be able to see the recorded runs for public projects.
|
||||
@@ -161,16 +146,12 @@ If your Record Key is accidentally exposed, you simply need to remove it and gen
|
||||
|
||||
A Record Key has nothing to do with **viewing** build data - it's a "write only" key. Even if it is accidentally leaked, it will not affect who can "see" your builds.
|
||||
|
||||
***
|
||||
|
||||
# Transferring Ownership of a Project
|
||||
|
||||
You can transfer projects that you own to another organization you are a part of or to another user in the organization. This functionality only exists in our [Dashboard](https://on.cypress.io/dashboard).
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
# Deleting a Project
|
||||
|
||||
You can delete projects you own. This will also delete all of their recorded runs. This functionality only exists in our [Dashboard](https://on.cypress.io/dashboard).
|
||||
|
||||
@@ -11,8 +11,6 @@ To record your runs:
|
||||
1. First [setup your project to record](https://on.cypress.io/recording-project-runs)
|
||||
2. Then [run the command](https://on.cypress.io/how-do-i-record-runs) `cypress run --record --key <record_key>`
|
||||
|
||||
***
|
||||
|
||||
# What is recorded during a run?
|
||||
|
||||
We capture the following:
|
||||
@@ -30,8 +28,6 @@ We have already begun the implementation for capturing even more things from you
|
||||
|
||||
These will be added in subsequent releases.
|
||||
|
||||
***
|
||||
|
||||
## Standard Output
|
||||
|
||||
Standard output includes details and summaries of your tests based on the [reporter](https://on.cypress.io/guides/reporters) you have set. By default it is the `spec` reporter.
|
||||
@@ -40,8 +36,6 @@ Standard output includes details and summaries of your tests based on the [repor
|
||||
|
||||
You will also see a summary at the bottom indicating the files we've recorded.
|
||||
|
||||
***
|
||||
|
||||
## Test Failures
|
||||
|
||||
Any tests that fail during a run can be found under the **Failures** tab. Each failure is listed under it's nested test title.
|
||||
@@ -54,8 +48,6 @@ Any tests that fail during a run can be found under the **Failures** tab. Each f
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Screenshots
|
||||
|
||||
All screenshots taken during the entire run can be found under the **Screenshots** tab. Both screenshots taken during failures and screenshots taken using the [`cy.screenshot`](https://on.cypress.io/api/screenshot) command are located here. Each screenshot displays the application as well as the Cypress Command Log.
|
||||
@@ -64,8 +56,6 @@ Each screenshot will display under the test title it was taken in.
|
||||
|
||||
|
||||
|
||||
***
|
||||
|
||||
## Videos
|
||||
|
||||
Any videos taken during the run can be found under the **Videos** tab. You can also download the video of a run.
|
||||
|
||||
@@ -27,8 +27,6 @@ cy
|
||||
.visit(Cypress.env("host"))
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
# Setting Environment Variables
|
||||
|
||||
There are 4 different ways to set environment variables. Each has a slightly different use case.
|
||||
@@ -44,8 +42,6 @@ Don't feel obligated to pick just one method. It is common to use one strategy f
|
||||
|
||||
When your tests are running, you can use the [`Cypress.env()`](https://on.cypress.io/api/env) function to access the values of your environment variables.
|
||||
|
||||
***
|
||||
|
||||
## Option #1: Set in `cypress.json`
|
||||
|
||||
Any key/value you set in your [`cypress.json`](https://on.cypress.io/guides/configuration) under the `env` key will become an environment variable.
|
||||
@@ -77,8 +73,6 @@ Cypress.env("some") // => "value"
|
||||
- Only works for values which should be the same on across all machines
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
## Option #2: Create a `cypress.env.json`
|
||||
|
||||
You can create your own `cypress.env.json`, which Cypress will automatically check. Values in here will overwrite conflicting values in `cypress.json`.
|
||||
@@ -113,8 +107,6 @@ Cypress.env("api_server") // => "http://localhost:8888/api/v1/"
|
||||
- Overkill for 1 or 2 environment variables
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
## Option #3: Export as `CYPRESS_*`
|
||||
|
||||
Any environment variable on your machine that starts with either `CYPRESS_` or `cypress_` will automatically be added and made available to you.
|
||||
@@ -148,8 +140,6 @@ Cypress.env("api_server") // => "http://localhost:8888/api/v1/"
|
||||
- Not as obvious where values come from vs the other methods
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
## Option #4: Pass in from the CLI as `--env`
|
||||
|
||||
Lastly you can also pass in environment variables as options when [using the CLI tool](https://github.com/cypress-io/cypress-cli).
|
||||
@@ -185,8 +175,6 @@ Cypress.env("api_server") // => "http://localhost:8888/api/v1/"
|
||||
- Pain to write the `--env` options everywhere you use Cypress
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
# Overriding Configuration
|
||||
|
||||
If your environment variables match a standard configuration key then instead of setting an `environment variable` they will instead override the configuration value.
|
||||
|
||||
@@ -11,8 +11,6 @@ Cypress supports the following reporters:
|
||||
* [`junit`](https://github.com/michaelleeallen/mocha-junit-reporter)
|
||||
* Custom reporters ([see below](#section-custom-reporters))
|
||||
|
||||
***
|
||||
|
||||
# Custom Reporters
|
||||
|
||||
Cypress supports custom reporters, whether local to your project or installed through npm.
|
||||
@@ -33,7 +31,7 @@ Specify the path to your custom reporter to use it:
|
||||
|
||||
`cypress.json`:
|
||||
|
||||
```javascript
|
||||
```json
|
||||
{
|
||||
"reporter": "reporters/custom.js"
|
||||
}
|
||||
@@ -45,13 +43,11 @@ Command line:
|
||||
cypress run --reporter reporters/custom.js
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## npm Reporters
|
||||
|
||||
If you have installed a custom reporter through npm, specify the package name:
|
||||
|
||||
```javascript
|
||||
```json
|
||||
// cypress.json
|
||||
{
|
||||
"reporter": "mochawesome"
|
||||
@@ -68,13 +64,11 @@ cypress run --reporter mochawesome
|
||||
You need to install any peer dependencies the reporter requires, even if they're bundled with Cypress. For example, [mochawesome](https://github.com/adamgruber/mochawesome) requires `mocha` as a peer dependency. You will need to install mocha as a dev dependency of your own project for it to work (`npm install mocha --save-dev`).
|
||||
{% endnote %}
|
||||
|
||||
***
|
||||
|
||||
# Reporter Options
|
||||
|
||||
Some reporters accept options to customize their behavior. These can be specified in your `cypress.json` or via the command line:
|
||||
|
||||
```javascript
|
||||
```json
|
||||
// cypress.json
|
||||
{
|
||||
"reporter": "junit",
|
||||
|
||||
Reference in New Issue
Block a user