mirror/cypress
1
0
Fork 0
mirror of https://github.com/cypress-io/cypress.git synced 2026-02-20 14:10:57 -06:00
Code Issues Packages Projects Releases Wiki Activity

docs: FAQ + some media query styles

Browse Source 
- Styled each h2 in FAQ to have a question icon
- Commented out non-answered FAQ’s
- Moved some questions from old ‘incomplete’ FAQ
- Added table of contents to FAQ page + last updated
This commit is contained in:
Jennifer Shehane
2017-06-05 14:24:50 -04:00
parent 61a9170a2f
commit 2bc2149477
8 changed files with 303 additions and 187 deletions
Download Patch File Download Diff File Expand all files Collapse all files

187
docs/source/faq/index.md
View File

@@ -1,5 +1,5 @@
---
layout: plain
layout: page
title: FAQ
comments: false
containerClass: faq
@@ -7,71 +7,140 @@ containerClass: faq
# General Questions
## What is Cypress?
<!-- ## What is Cypress? -->
## Hasn’t this been done before?
<!-- ## Hasn’t this been done before? -->
## {% fa fa-question-circle green %} How is this different from 'X' testing tool?
## Is Cypress free?
Cypress is kind of a hybrid application/framework/service all rolled into one. It takes a little bit of other testing tools, brings them together and improves on them.
**Mocha**
[Mocha](http://mochajs.org/) is a testing framework for JavaScript. Mocha gives you the `it`, `describe`, `beforeEach` methods. Cypress isn't **different** from Mocha, it actually **uses** Mocha under the hood. All of your tests will be written on top of Mocha's `bdd` interface.
**Karma**
[Karma](http://karma-runner.github.io/) is a unit testing runner for JavaScript, which can work with either `Jasmine`, `Mocha`, or another JavaScript testing framework.
Karma also watches your JavaScript files, live reloads when they change, and is also the `reporter` for your tests failing / passing. It runs from the command line.
Cypress essentially replaces Karma because it does all of this already and much more.
**Capybara**
[Capybara](http://teamcapybara.github.io/capybara/) is a `Ruby` specific tool that allows you to write integration tests for your web application. In the Rails world, this is the *go-to* tool for testing your application. It uses `Selenium` (or another headless driver) to interact with browsers. It's API consists of commands that query for DOM elements, perform user actions, navigate around, etc.
Cypress essentially replaces Capybara because it does all of these things and much more. The difference is that instead of testing your application in a GUI-less console, you'd see your application at all times. You'd never have to take a screenshot to debug because all commands instantly provide you the state of your application while they run. Upon any command failing, you'll get a human-readable error explaining why it failed. There's no "guessing" when debugging.
Oftentimes Capybara begins to not work as well in complex JavaScript applications. Additionally, trying to TDD your application is often difficult. You often have to resort to writing your application code first (typically manually refreshing your browser after changes) until you get it working. From there you write tests, but lose the entire value of TDD.
**Protractor**
[Protractor](http://www.protractortest.org/) is basically the `Capybara` of the JavaScript world. It provides a nice Promise-based interface on top of Selenium, which makes it easy to deal with asynchronous code. Protractor comes with all of the features of Capybara and essentially suffers from the same problems.
Cypress replaces Protractor because it does all of these things and much more. One major difference is that Cypress enables you to write your unit tests and integration tests in the same tool, as opposed to splitting up this work across both Karma and Protractor.
Also, Protractor is very much focused on `AngularJS`, whereas Cypress is designed to work with any JavaScript framework. Protractor, because it's based on Selenium, is still pretty slow, and is prohibitive when trying to TDD your application. Cypress, on the other hand, runs at the speed your browser and application are capable of serving and rendering, there is no additional bloat.
**SauceLabs**
[SauceLabs](https://saucelabs.com/) is a 3rd party tool which enables Selenium-based tests to be run across various browsers and operating systems. Additionally, they have a JavaScript Unit Testing tool that isn't Selenium focused.
SauceLabs also has a `manual testing` mode, where you can remotely control browsers in the cloud as if they were installed on your machine.
Cypress's API is written to be completely compatible with SauceLabs, even though our API is not Selenium based at all. We will be offering better integration with SauceLabs in the future.
Ultimately SauceLabs and Cypress offer very different value propositions. SauceLabs doesn't help you write your tests, it takes your existing tests and runs them across different browsers and aggregates the results for you.
Cypress on the other hand **helps** you write your tests. You would use Cypress every day, building and testing your application, and then use SauceLabs to ensure your application works on every browser.
## {% fa fa-question-circle green %} Is Cypress free?
Cypress desktop app and CLI are free to use. The Cypress Dashboard is a premium feature for non-open source projects and offers recording videos, screenshots and logs in a web interface.
## What operating systems do you support?
## {% fa fa-question-circle green %} What operating systems do you support?
The desktop application can be installed in OSX and Linux. Windows is not yet supported, although you can use Cypress if you install a Linux VM using something like VirtualBox or using a Docker image.
The desktop application can be installed in OSX and Linux. [Windows is not yet supported](https://github.com/cypress-io/cypress/issues/74), although you can use Cypress if you install a Linux VM using something like VirtualBox or using a Docker image.
## Do you support native mobile apps?
## {% fa fa-question-circle green %} Do you support native mobile apps?
Cypress would never be able to run on a native mobile app, but would be able to run in a web view. In that mode, you'd see the commands display in a browser while you would drive the mobile device separately. Down the road we'll likely have first class support for this, but today it is not a current priority.
Currently you can control the [`.viewport()`](https://on.cypress.io/viewport) to test responsive, mobile views in a website or web application.
Currently you can control the [`.viewport()`](https://on.cypress.io/api/viewport) to test responsive, mobile views in a website or web application.
## Do you support X language or X framework?
## {% fa fa-question-circle green %} Do you support X language or X framework?
Cypress tests anything that runs in the context of a browser. It is backend, front-end, language and framework agnostic.
Any and all. Ruby, Node, C#, PHP - none of that matters. Cypress tests anything that runs in the context of a browser. It is backend, front-end, language and framework agnostic.
Your actual test code, however does need to be written in JavaScript (or a language that transpiles into JavaScript).
You'll write your tests in JavaScript, but beyond that Cypress works everywhere.
## Will Cypress work in my CI provider?
## {% fa fa-question-circle green %} Will Cypress work in my CI provider?
Cypress works in any CI provider.
## What are good use cases for Cypress?
## {% fa fa-question-circle green %} Does Cypress require me to change any of my existing code?
No. But if you're wanting to test parts of your application that are not easily testable, you'll want to refactor those situations (as you would for any testing).
## {% fa fa-question-circle green %} If Cypress runs in the browser, doesn't that mean it's sandboxed?
Yes, technically; it's sandboxed and has to follow the same rules as every other browser. That's actually a good thing because it doesn't require a browser extension, and it naturally will work across all browsers (which enables cross-browser testing).
But Cypress is actually way beyond just a basic JavaScript application running in the browser. It's also a Desktop Application and communicates with backend web services.
All of these technologies together are coordinated and enable Cypress to work, which extends its capabilities far outside of the browser sandbox. Without these, Cypress would not work at all. For the vast majority of your web development, Cypress will work just fine, and already **does** work.
## {% fa fa-question-circle green %} We use WebSockets, will Cypress work with that?
Yes.
<!-- ## What are good use cases for Cypress? -->
## What are bad use cases for Cypress?
<!-- ## What are bad use cases for Cypress? -->
## {% fa fa-question-circle green %} We have the craziest most insane authentication system ever, will Cypress work with that?
## Is there code coverage?
If you're using some crazy thumb-print, retinal-scan, time-based, key-changing, microphone audial decoding mechanism to log in your users, then no, Cypress won't work with that. But seriously, Cypress is a **development** tool, which makes it easy to test your web applications. If your application is doing 100x things to make it extremely difficult to access, Cypress won't magically make it any easier.
Because Cypress is a development tool, you can always make your application more accessible while in your development environment. If you want, simply disable crazy steps in your authentication systems while you're in your testing environment. After all, that's why we have different environments! Normally you already have a development environment, a testing environment, a staging environment, and a production environment. So simply expose the parts of your system you want accessible in each appropriate environment.
In doing so, Cypress may not be able to give you 100% coverage without you changing anything, but that's okay. Just use different tools to test the crazier, less accessible parts of your application, and let Cypress test the other 99%.
Just remember, Cypress won't make a non-testable application suddenly testable. It's on your shoulders to architect your code in an accessible manner.
## {% fa fa-question-circle green %} Can I use Cypress to script user-actions on an external site like `gmail.com`?
No. There are already lots of tools to do that. Using Cypress to test against a 3rd party application is not supported. It **may** work but will defeat the purpose of why it was created. You use Cypress *while* you develop **your** application, it helps you write your tests.
## {% fa fa-question-circle green %} Is there code coverage?
There is nothing currently built into Cypress to do this. Adding code coverage around end to end tests is much harder than unit and its possible it may not be feasible to do in a generic way. You can read in more detail about code coverage [here](https://github.com/cypress-io/cypress/issues/346).
## What kind of tests do I write in Cypress?
<!-- ## What kind of tests do I write in Cypress? -->
## Does Cypress use Selenium / Webdriver?
## {% fa fa-question-circle green %} Does Cypress use Selenium / Webdriver?
No. In fact Cypress' architecture is very different from Selenium in a few critical ways:
- Cypress runs in the context of the browser. With Cypress it's much easier to accurately test the browser, but harder to talk to the outside work. In Selenium it's the exact opposite. Although Cypress has a few commands that give you access to the outside world - like [.request()](http://on.cypress.io/request) and [.exec()](https://on.cypress.io/exec).
## Are there driver bindings in my language?
## {% fa fa-question-circle green %} Are there driver bindings in my language?
Cypress does *not* utilize WebDriver for testing, so does not use or have any notion of driver bindings.
## Does Cypress have an equivalent to Selenium IDE?
<!-- ## Does Cypress have an equivalent to Selenium IDE? -->
## {% fa fa-question-circle green %} Is Cypress open source?
We are working on open sourcing Cypress. You can read more [here](https://www.cypress.io/blog/2017/05/04/cypress-is-going-open-source/).
## Is Cypress open source?
<!-- ## How can I contribute to Cypress? -->
## How can I contribute to Cypress?
## I found a bug! What do I do?
## {% fa fa-question-circle green %} I found a bug! What do I do?
- Search existing [open issues](https://github.com/cypress-io/cypress/issues), it may already be reported!
- Update Cypress. Your issue may have [already been fixed](https://github.com/cypress-io/cypress/wiki/changelog).
@@ -79,18 +148,18 @@ Cypress does *not* utilize WebDriver for testing, so does not use or have any no
# Using Cypress
## How do I wait for an element not to exist?
<!-- ## How do I wait for an element not to exist? -->
## How do I do different things depending on what’s currently in the dom/url/cookies/localstore?
<!-- ## How do I do different things depending on what’s currently in the dom/url/cookies/localstore? -->
## How can I parallelize my runs?
## {% fa fa-question-circle green %} How can I parallelize my runs?
You can read more about parallelization [here](https://github.com/cypress-io/cypress/issues/64).
## Can I run a single test or group of tests?
## {% fa fa-question-circle green %} Can I run a single test or group of tests?
You can run a group of tests or a single test by placing an `.only` to a test suite or specific test.
@@ -98,11 +167,11 @@ You can run a single test headlessly by passing the `--spec` flag to `cypress ru
Currently there is no way to specify a group of tests to run headlessly. You can read more [here](https://github.com/cypress-io/cypress/issues/263).
## How do I test uploading a file?
## {% fa fa-question-circle green %} How do I test uploading a file?
It is possible to upload files in your application but its different based on how you've written your own upload code. You can read more about this [here](https://github.com/cypress-io/cypress/issues/170)
## What is the projectId for?
## {% fa fa-question-circle green %} What is the projectId for?
A `projectId` is added to your `cypress.json` after you setup your project for the Dashboard. This `cypress.json` is meant to be checked into source control.
@@ -111,7 +180,7 @@ The `projectId` identifies your project in the [Dashboard](https://on.cypress.io
You can forgo the projectId and CI keys altogether by running `cypress run` headlessly, but then you're basically opting out of the Dashboard and all its goodies.
## How do I get the native DOM reference of an element found using Cypress?
## {% fa fa-question-circle green %} How do I get the native DOM reference of an element found using Cypress?
Cypress wraps elements in jQuery so you'd just get the native element from there.
@@ -121,11 +190,9 @@ cy.get('button').then(($el) => {
})
```
## How do I make Cypress wait for an XHR request?
<!-- ## How do I make Cypress wait for an XHR request? -->
## How do I wait for multiple XHR requests to the same url?
## {% fa fa-question-circle green %} How do I wait for multiple XHR requests to the same url?
You should set up an alias (using [`.as()`](https://on.cypress.io/api/as)) to a single route that matches all of the XHRs. You can then [`.wait()`](https://on.cypress.io/wait) on it multiple times and Cypress keeps track of how many matching XHR requests there are.
@@ -141,21 +208,19 @@ cy.get('#list>li').should('have.length', 20)
<!-- ## How do I test drag-n-drop? -->
## How do I seed / reset my database?
## {% fa fa-question-circle green %} How do I seed / reset my database?
You can use either [`.request()`](https://on.cypress.io/request) or [`cy.exec`](https://on.cypress.io/exec) to talk to your backend to seed data.
You could also just stub XHR requests directly using [`.route()`](https://on.cypress.io/route) which avoids ever even needing to fuss with your database.
## How do I pass data to my webserver from Cypress?
<!-- ## How do I pass data to my webserver from Cypress? -->
## How do I test content inside an iframe?
## {% fa fa-question-circle green %} How do I test content inside an iframe?
Currently Cypress does not support selecting or accessing elements from within an iframe. You can read more about this [#here](https://github.com/cypress-io/cypress/issues/136).
## How do I preserve cookies/localstorage in between my tests?
## {% fa fa-question-circle green %} How do I preserve cookies/localstorage in between my tests?
By default, Cypress automatically clears all cookies **before** each test to prevent state from building up.
@@ -171,7 +236,7 @@ Cypress.Cookies.defaults({
You cannot currently preserve localStorage across tests and can read more [here](https://github.com/cypress-io/cypress/issues/461).
## Some of my elements animate in, how do I work around that?
## {% fa fa-question-circle green %} Some of my elements animate in, how do I work around that?
Oftentimes you can usually account for animation by asserting `.should('be.visible')` or another assertion on one of the elements you expect to be animated in.
@@ -189,7 +254,7 @@ cy.get('button', { timeout: 10000 }) // <-- wait up to 10 seconds for this 'butt
cy.get('element').click({ timeout: 10000 }).should('not.have.class', 'animating')
```
## Can I test anchor links that open in a new tab?
## {% fa fa-question-circle green %} Can I test anchor links that open in a new tab?
Cypress does not and may never have multi-tab support for various reasons.
@@ -198,27 +263,27 @@ Luckily there are lots of easy and safe workarounds that enable you to test the
[Read through this recipe to see how to test anchor links.](https://github.com/cypress-io/cypress-example-recipes/blob/master/cypress/integration/tab_handling_anchor_links_spec.js)
## How do I run my tests in another browser?
<!-- ## How do I run my tests in another browser? -->
## Where do I get the key to run my tests in CI?
<!-- ## Where do I get the key to run my tests in CI? -->
## Can I create more than one key for CI?
<!-- ## Can I create more than one key for CI? -->
## I have an app that needs to be tested across multiple user sessions, like a chat app across 2 browsers. How do I test that?
<!-- ## I have an app that needs to be tested across multiple user sessions, like a chat app across 2 browsers. How do I test that? -->
## I want to test clicking a link that navigates, how do I wait and check the resulting location url?
<!-- ## I want to test clicking a link that navigates, how do I wait and check the resulting location url? -->
## Is there a way to watch for an xhr request and assert that the response code came back a certain way?
<!-- ## Is there a way to watch for an xhr request and assert that the response code came back a certain way? -->
## I’m running a lot of tests that appear to slow down as they run, is there a way to fix this?
<!-- ## I’m running a lot of tests that appear to slow down as they run, is there a way to fix this? -->
## How do I get an input's value in Cypress?
## {% fa fa-question-circle green %} How do I get an input's value in Cypress?
Cypress DOM elements are just jQuery elements so you can use any method available in jQuery. Below are some examples of working with an input's value.
@@ -236,24 +301,24 @@ cy.get('input').then(($input) => {
cy.get('input').should('have.value', 'abc')
```
## How do I make conditional based assertions / control flow?
## {% fa fa-question-circle green %} How do I make conditional based assertions / control flow?
## How do I require "" node module in Cypress?
## {% fa fa-question-circle green %} How do I require "" node module in Cypress?
The code you write in Cypress is executed in the browser, so you can import or require JS modules, but only those that work in the browser.
Cypress doesn't have direct access to node or your file system. We recommend utilizing [`.exec()`](https://on.cypress.io/exec) to execute a shell command or a node script that will do what you need.
## Is there a way to give a proper SSL certificate to your proxy so the page doesn't show up as "not secure"?
## {% fa fa-question-circle green %} Is there a way to give a proper SSL certificate to your proxy so the page doesn't show up as "not secure"?
No, Cypress modifies network traffic in real time and therefore must sit between your server and the browser. There is no other way for us to achieve that.
## Can I use the Page Object pattern?
## {% fa fa-question-circle green %} Can I use the Page Object pattern?
As far as page objects are concerned, you should be able to use regular JavaScript functions and aliasing with [`.as()`](https://on.cypress.io/as) to essentially recreate what page objects give you.
# Dashboard
<!-- # Dashboard
## What is the Dashboard?
@@ -295,15 +360,15 @@ As far as page objects are concerned, you should be able to use regular JavaScri
## How secure is storing my test runs (videos and screenshots) on your servers?
## How secure is storing my test runs (videos and screenshots) on your servers? -->
# Company
## Who’s behind Cypress?
## {% fa fa-question-circle green %} Who’s behind Cypress?
You can read more about who's behind Cypress on our [here](https://www.cypress.io/about).
## Are you hiring?
## {% fa fa-question-circle green %} Are you hiring?
You can check our open positions [here](https://www.cypress.io/jobs).

2
docs/themes/cypress/layout/page.swig vendored
View File

@@ -1,4 +1,4 @@
<div id="content-wrap">
<div id="content-wrap" class="{{ page.containerClass }}">
<div id="content" class="wrapper">
<div id="content-inner">
<article class="article-container" itemscope itemtype="http://schema.org/Article">

53
docs/themes/cypress/source/css/_partial/faq.scss vendored
View File

@@ -1,31 +1,46 @@
.faq {
width: 750px;
margin: 0 auto 50px;
h1, h2, p {
font-family: $font-title;
#content-inner {
margin-left: 0;
}
h1 {
font-size: 2.5em;
line-height: 1em;
font-weight: 800;
margin: 2em 0 1em;
.article-inner {
margin-right: 350px;
}
&:first-of-type {
margin-top: 1em;
#article-toc {
width: 350px;
margin-right: -350px;
&.fixed {
right: 350px;
}
#article-toc-inner {
width: 350px;
}
}
h2 {
font-size: 1.4em;
line-height: 1.6em;
margin: 1.5em 0 0.5em;
font-weight: 500;
.toc-link {
white-space: nowrap;
overflow: hidden;
}
p {
font-size: 1em;
.article-footer, #sidebar, .article-header {
display: none;
}
.article {
h1 {
&:first-of-type {
margin-top: 0;
border-top: 0;
}
}
h2 {
margin-top: 2em;
padding-top: 2em;
}
}
}

136
docs/themes/cypress/source/css/_partial/media_queries.scss vendored Normal file
View File

@@ -0,0 +1,136 @@
@media screen {
html, body {
height: 100%;
}
.wrapper {
max-width: $max-width;
}
.inner {
padding: 0;
}
.post {
max-width: 800px;
}
.faq {
// max-width: 750px;
// margin: 0 auto 50px;
// padding: 0 30px;
}
}
@media screen and(min-width: 769px) {
.inner {
padding: 0 $gutter-width;
}
#sidebar .inner {
padding-right: 0;
}
#main-nav {
display: block;
}
#lang-select-wrap {
display: block;
}
#banner-title {
padding-top: 100px;
font-size: 50px;
}
#banner-start {
padding: 60px 0;
font-size: 18px;
}
#banner-share {
display: block;
}
#intro-feature-list {
flex-flow: row wrap;
}
.intro-feature-wrap {
box-flex: 1;
flex: 0 0 50%;
padding-top: 50px;
}
.intro-feature {
text-align: left;
padding-left: 70px;
}
.intro-feature-icon {
position: absolute;
top: 0;
left: 20px;
font-size: 24px;
width: 24px;
}
#intro-cmd-wrap {
margin: 50px auto 0;
}
#sidebar {
display: block;
}
#content-inner {
margin-left: $sidebar-width;
}
.article-container {
float: right;
width: 100%;
}
.article-inner {
margin-right: $sidebar-width;
}
#article-toc {
display: block;
}
.article-edit-link {
display: block;
}
#mobile-nav-toggle {
display: none;
}
#footer {
text-align: left;
}
#footer-copyright {
float: left;
}
#footer-links {
float: right;
margin-top: 0;
}
#article-toc {
display: block;
}
}
@media screen and(max-width: 768px) {
.article {
padding: 0 20px !important;
}
.article-inner {
margin-right: 0 !important;
}
#article-toc {
display: none;
width: auto;
margin-right: 0;
&.fixed {
right: auto;
}
#article-toc-inner {
width: 100% !important;
}
}
}

101
docs/themes/cypress/source/css/_partial/mobile_nav.scss vendored
View File

@@ -1,104 +1,3 @@
@media screen {
html, body {
height: 100%;
}
.wrapper {
max-width: $max-width;
}
.inner {
padding: 0;
}
.post {
max-width: 800px;
}
}
@media screen and(min-width: 769px) {
.inner {
padding: 0 $gutter-width;
}
#sidebar .inner {
padding-right: 0;
}
#main-nav {
display: block;
}
#lang-select-wrap {
display: block;
}
#banner-title {
padding-top: 100px;
font-size: 50px;
}
#banner-start {
padding: 60px 0;
font-size: 18px;
}
#banner-share {
display: block;
}
#intro-feature-list {
flex-flow: row wrap;
}
.intro-feature-wrap {
box-flex: 1;
flex: 0 0 50%;
padding-top: 50px;
}
.intro-feature {
text-align: left;
padding-left: 70px;
}
.intro-feature-icon {
position: absolute;
top: 0;
left: 20px;
font-size: 24px;
width: 24px;
}
#intro-cmd-wrap {
margin: 50px auto 0;
}
#sidebar {
display: block;
}
#content-inner {
margin-left: $sidebar-width;
}
.article-container {
float: right;
width: 100%;
}
.article-inner {
margin-right: $sidebar-width;
}
#article-toc {
display: block;
}
.article-edit-link {
display: block;
}
#mobile-nav-toggle {
display: none;
}
#footer {
text-align: left;
}
#footer-copyright {
float: left;
}
#footer-links {
float: right;
margin-top: 0;
}
}
#mobile-nav {
position: fixed;
top: 0;

6
docs/themes/cypress/source/css/_partial/page.scss vendored
View File

@@ -47,7 +47,7 @@
}
}
.article-content, .faq {
.article-content, .faq .article {
line-height: $line-height;
hr {
@@ -192,7 +192,7 @@
}
&+h2 {
margin-top: 0;
margin-top: 1.5em;
border-top: 0;
padding-top: 0;
}
@@ -200,7 +200,7 @@
h2 {
font-size: 1.3em;
line-height: 1em;
line-height: 1.5em;
font-weight: 500;
margin: 1.5em 0 0.5em 0;
padding-top: 1.5em;

2
docs/themes/cypress/source/css/_partial/toc.scss vendored
View File

@@ -48,7 +48,7 @@
width: $sidebar-width;
.sidebar-title {
margin-top: 0;
margin-top: 0;
}
&:before {

3
docs/themes/cypress/source/css/cypress.scss vendored
View File

@@ -4,10 +4,11 @@
@import "_partial/header";
@import "_partial/search";
@import "_partial/index";
@import "_partial/faq";
@import "_partial/sidebar";
@import "_partial/toc";
@import "_partial/page";
@import "_partial/mobile_nav";
@import "_partial/footer";
@import "_partial/highlight";
@import "_partial/faq";
@import "_partial/media_queries";