This issue was difficult to track down. Sometimes menuspy was accurate and sometimes not.
After some use, it seems to be most off when images are included on the page, so we suspect that menuspy is not properly calculating the height of images into it's scrolling algorithm. This is likely because the images have not loaded yet.
Can we calculate after the onload event? Does the onload event call before all images are loaded? Each image fires it's own load event, so you could check all images load event.
There are some pieces of material others have created in the community that mention Cypress. ๐
We would love to include these in our Media. Please take note of the categories we have in terms of media: Blogs, Screencasts, Talks, and Podcasts and make sure to place it in the correct category. When in doubt, just ask!
I'd like the same process for deployment as we have on master, where the docs are automatically deploy if docs directory was touched and the docs tests pass, except for deployment to go to docs-staging.cypress.io url when develop branch changes are made to docs.
And make sure docs scraping is not done in develop deployment.
Some of the resources don't appear to be loading correctly in docs-staging. I'd have to look at it more closely, but my first thought is that this url is incorrect in the hexo config when in staging, but I'd have to investigate more.
good observation, it might be broken then, I will look how we can overwrite it during build.
Can we actually test for this @jennifer-shehane ? I would love to run the e2e tests against deployed docs after deploy to catch this.
CypressError: Timed out retrying: expected '/api/events/catalog-of-events.html' to include 'and.html'
at Object.cypressErr (http://localhost:2222/__cypress/static/js/cypress.js:5729:15)
"API > Pagination > click on Next page > should display Prev link"
Uncaught TypeError: Cannot read property 'map' of undefined
Because this error occured during a 'before each' hook we are skipping the remaining tests in the current suite: 'click on Next page'
at MenuSpy.cacheItems (http://localhost:2222/js/vendor/menuspy.js:114:36)
Cypress + cy both emit a ton of events which developers can use to tap into for extensibility. These need to be documented and use cases suggested cypress-io/cypress#469
The public methods available on Cypress have expanded beyond a point where it can be an afterthought on the API page. Specifically, we are talking about methods that are:
Used by Cypress itself to write it's public API.
Would be useful to users if they wanted to extend Cypress and/or write their own custom commands.
I am proposing separating these methods into their own main navigation called something like, "Utilities" / "API Utilities" (I'm very much open to more name suggestions). This will be an area where writing Cypress custom commands will be more elegantly addressed and also serve as a good reference for contributors to Cypress once we are open source.
A first draft of the Utilities sidebar:
Overview
About
Writing Custom Commands
Cypress.Commands
add
overwrite
Cypress.dom
getElements
getFirstFixedOrStickyPositionParent
getFirstScrollableParent
getReasonIsHidden
isDescendent
isDetached
isDocument
isDom
isElement
isHidden
isJquery
isScrollable
isSelector
isTextLike
isType
isVisible
isWindow
positionProps
stringify
unwrap
wrap
Cypress.log <- whoops, this should have a nested file...
need to call this something (these are all on cy because they are all stateful - and can only be issued during a running test - also all of these are functions)
We have sensitive environment variables that are NOT passed to forked builds, like dashboard record key. So we still need to build the forks but without recording.
There are some questions that are asked in the Cypress gitter chat that we'd like to have in a searchable, centralized place - our FAQ.
Please take note of the categories we have in terms of our FAQ:
General Questions: Questions someone could ask without ever using Cypress. Maybe they have questions about how it works in general or what we support before diving in.
Using Cypress: Questions about how to use Cypress including the API, the Desktop GUI, or running the tests.
Make sure to place it in the correct category. When in doubt, just ask!
The list below is a rough draft. Some questions have rough answers taken from the chat, some have no answers. The questions and answers should be formatted clearly and edited.
Check off any questions from the list after adding it to the examples. Reference the PR to this issue #335.
Questions about Cypress:
Is there a way to ignore an exception thrown from my own application or a 3rd party library?
Read about some of our suggestions for this in our issue here.
Could Cypress be used as a replacement for protractor?
Protractor is essentially a wrapper around Selenium. In most cases Cypress can replace it just fine. There are some limitations to the way Cypress tests are ran (i.e. not via WebDriver, but within the browser under test itself). From my limited experience with Cypress (using it for few weeks now, I'm still evaluating) here are a few things you could test with Selenium (and hence Protractor) but you can't with Cypress:
Test in Firefox / IE / Edge.
Assert on clipboard contents.
Test TAB key (you can write your own .tab() command though, it's just not part of Cypress' API yet)
cypress CLI tool doesn't let you to execute a single test, just a single test suite. Not a big deal as you can just use it.only, but would be nice to have (and is offered by many Selenium-based runners)
Can't operate native browser dialogs / alerts.
can anyone tell me how much the dashboard feature costs?
We have not released pricing on the Dashboard yet but anticipate it being free for open source projects and having paid plan starting at $99/month
Does anyone know if it's possible to write Cypress tests in Typescript?
Is there a way to get a project recording link from a successful run/upload?
I think this is what you're asking for - cypress-io/cypress#494
In which case, not right now.
Is there any documentation about interacting with saving a file using the system dialog? As soon as the system dialog comes up it just waits forever, never times out.
You can't do this in Cypress currently. You'll need to bypass the way it normally works. Basically you could simply test the behavior before file prompting, like testing that an anchor has the right href. Or you could use cy.request() to programmatically download the file. You don't really need to test that a browser downloads a file because you would expect this to work. You just need to test the mechanism that would cause your application to prompt for file download and retain 100% coverage.
Is there any way can take screenshot with console?
No, not when running headlessly. The console would have to be open the whole time tests are run, then automatically failed when there are JavaScript errors on the page.
How do I make Cypress wait for an XHR request?
is there CLI option to run in chrome? Or is electron the only way to run headlessly?
How do I make conditional based assertions / control flow?
How do I run my tests in another browser?
Where do I get the key to run my tests in 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 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?
How do I pass data to my webserver from Cypress?
How do I test drag-n-drop?
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?
Any plans to add "Find React component in DOM" ability, like cy.getReactComponent() or something? (I'd guess you'd want to keep it separate from cy.get())
you could likely write this as a custom command yourself. Since you have the ability to access window globals, so long as your react application is exposed it should be possible to traverse the trees and access it that way (same as react dev tools essentially)
Is it possible to use cypress on .jspa?
Yes. Cypress works on anything rendered to a browser.
Once we're open source (soon!), we'll have it tagged in the repo too.
Is there an ESLint plugin for Cypress or a list of globals? describe/it/beforeEach etc globals come from Mocha. So you can use ESLint plugins for Mocha like this one.
When I visit my site directly, the certificate is verified, however the browser launched through Cypress is showing it as "Not Secure". Why?
This is normal. Cypress modifies the traffic between your server and the browser. The browser notices this and displays a certificate warning. However, this is purely cosmetic and does not alter the way your application under test runs in any way, so you can safely ignore this warning.
My question is, there's any option to run cypress with devtools open? We want to track network and console issues.
Yeah, this is definitely the motivation behind cypress-io/cypress#448, there is not a way to run cypress headlessly with devtools open. You may try running the tests locally and select the Electron browser, that's as close as you'll get with devtools open to replicating the environment that was run headlessly.
Can I test my Electron app?
Testing your Electron app will not 'just work', as Cypress is designed to test anything that runs in a browser and Electron is a browser + node.
So what benefits would one get for converting one's unit tests from Karma or Jest to Cypress?
Unit tests are not something we are really trying to solve right now. Most of the cy commands are useless in unit tests. The biggest benefit of writing unit tests in Cypress is that they run in a browser, which has debugger support built in.
We have internally experimented at doing DOM based component unit testing in Cypress - and that has the possibility of being an excellent "sweet spot" for unit tests. You'd get full DOM support, screenshot support, snapshot testing, and you could then use other cy commands (if need be). But as I mentioned this isn't something we're actively pushing, it just remains a thing that's possible if we wanted to go down that route.
With that said - we actually believe the best form of testing in Cypress is a combination of a "unit test" mixed with an "e2e test". We don't believe in a "hands off" approach. We want you to modify the state of your application, take shortcuts as much as possible (because you have native access to all objects including your app). In other words, we want you to think in unit tests while you write integration tests.
Add example of using request headers to cy.request doc:
Error: Constructing {% url %} tag helper failed
> The source file was: /Users/irinakous/git/cypress-documentation/source/api/events/removelistener.md
> Could not find a valid doc file in the sidebar.yml for: "once"
the full url was "once"
at getLocalFile (/Users/irinakous/git/cypress-documentation/lib/url_generator.js:194:5)
Error: Constructing {% url %} tag helper failed
> The source file was: /Users/irinakous/git/cypress-documentation/source/api/events/on.md
> Could not find a valid doc file in the sidebar.yml for: "removelistener"
the full url was "removelistener"
at getLocalFile (/Users/irinakous/git/cypress-documentation/lib/url_generator.js:194:5)
There are some phrases visitors to our documentation have searched for that return 0 results. Many of these could be integrated into the correct place to answer the likely question the visitor had. For example, if there were no results for "firefox", they were likely wanting to know about our browser support. So, we could write "Firefox, IE, etc.... are not currently supported" in this section of this document: https://docs.cypress.io/guides/core-concepts/launching-browsers.html#Browser-Environment.
Another simple way to address a phrase is to add a question about it in our FAQ document.
Check off any phrases from the list after adding it to the docs. Reference the PR to this issue #324.
Previous searches in our docs that returned 0 results:
I had difficulty finding the Typescript definitions the other day. I expected them to be in the examples area, but it's in this weird doc that's kind of out of place. Should be moved within examples.
The markdown below is being generated into an actual <option> and <select> element when converted to html. This does not happen locally however when I just start the server.
- {% url `.select()` select %} - Select an `<option>` within a `<select>`.
Npm install again. I've seen this happen in hexo. I have no idea why it
does this.
You might need to rm -rf node_modules and then npm cache clean and then npm
install again
On Tue, Aug 29, 2017 at 9:26 AM, Jennifer Shehane [email protected]
wrote:
The markdown below is being generated into an actual and
element when converted to html. This does not happen locally however when I
just start the server.
{% url .select() select %} - Select an <option> within a <select>.
[image: screen shot 2017-08-29 at 9 25 19 am]
https://user-images.githubusercontent.com/1271364/29823262-2c771ed6-8c9c-11e7-9b47-55372dce3bcd.png
โ
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cypress-io/cypress-monorepo/issues/394#issuecomment-325663041,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABNc8JQvqibYyhY4ecAc4Vc4Cgjw0TfRks5sdBGXgaJpZM4PF6bb
.
@jennifer-shehane commented on Wed Aug 30 2017
Another fun example of these code examples not being escaped properly. ๐
Left side is production / rightside is local
// this makes it seem like you'd do a synchronous query// to get the <body> which in Cypress code you never doexpect($('body')).to.have.attr('foo','bar')
Proposed
// more accurately reflects how you'd make this// in Cypressexpect($el).to.have.attr('foo','bar')
A user was having an issue determining why their cy.route() url was not matching their API calls. By passing this debug option, it helped them determine the issue. We should probably include a note about this in our cy.server() doc.
ERROR Plugin load failed: hexo-prism-plugin
TypeError: Cannot read property 'inside' of undefined
at Object.<anonymous> (/Users/jennifer/Dev/Projects/cypress-documentation/node_modules/prismjs/components/prism-django.js:32:31)
at Module._compile (module.js:556:32)
at Object.Module._extensions..js (module.js:565:10)
at Module.load (module.js:473:32)
at tryModuleLoad (module.js:432:12)
at Function.Module._load (module.js:424:3)
at Module.require (module.js:483:17)
at require (internal/module.js:20:19)
at componentsSet.forEach (/Users/jennifer/Dev/Projects/cypress-documentation/node_modules/node-prismjs/index.js:27:27)
at Array.forEach (native)
at Object.<anonymous> (/Users/jennifer/Dev/Projects/cypress-documentation/node_modules/node-prismjs/index.js:27:4)
at Module._compile (module.js:556:32)
at Object.Module._extensions..js (module.js:565:10)
at Module.load (module.js:473:32)
at tryModuleLoad (module.js:432:12)
at Function.Module._load (module.js:424:3)
at Module.require (module.js:483:17)
at require (/Users/jennifer/Dev/Projects/cypress-documentation/node_modules/hexo/lib/hexo/index.js:216:21)
at /Users/jennifer/Dev/Projects/cypress-documentation/node_modules/hexo-prism-plugin/index.js:5:15
at /Users/jennifer/Dev/Projects/cypress-documentation/node_modules/hexo/lib/hexo/index.js:232:12
at tryCatcher (/Users/jennifer/Dev/Projects/cypress-documentation/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/Users/jennifer/Dev/Projects/cypress-documentation/node_modules/bluebird/js/release/promise.js:512:31)