Hot answers tagged

27

Well this was embarrassingly simple cy.get('button.mat-button.mat-primary').eq(8).should('not.be.disabled') cy.get('button.mat-button.mat-primary').eq(8).should('be.disabled') and this will allow me to check if buttons are disabled or not. Didn't even need to use the "expect" route.


9

In our last project we also evaluated different tools among these were also Cypress and Selenium. At the end we decided for Selenium, because we were testing front end applications and for us Cross-Browser testing was one of the most important reasons, why we made the decision for selenium. Furthermore our test management had the requirement to integrate one ...


7

From the Cypress site: Because Cypress runs in the browser, it will never have multi-tabs support. We do have access to the browser automation APIs to actually switch tabs, but there is no reason for us to ever expose them. Most of the time this use case is needed when users click an that opens a new tab. Users then want to switch to that tab ...


7

Probably not, mainly because: WebDriver is a W3C Spec WebDriver supports all major programming languages WebDriver is supported by all major browser vendors WebDriver is 100% open-source Cypress has commercial owners and for example "Test parallelization" is not in their open-source offering. Cypress is JavaScript only, which is not everyones cup-of-tea ...


6

Open Source: I am a developer at Cypress.io. Cypress recently released its public beta and is now open source. The code for it's core product, the Test Runner can be found here. The Cypress Dashboard Service, used to display test recordings and data when tests are run in CI, will be free for open source projects and paid based on usage for private projects ...


6

Open source: Cypress.IO looks promising, but I have been holding off with starting to use it on a production project. My main reason that it is a commercial company and I cannot be sure they keep their open-source promise. I think development tools should be open-source. I don't want to invest my time and our company's resources if I am not sure I can re-...


5

Three things should be considered, all equally important: Performance: Will creating several tests increase the suite execution time? It highly depends on your framework. Even if the time to bootstrap a test is short, it can be damaging on the long-run; Test dependency: If you use only one test, you should be able to make the assertions independent - if the ...


5

The Cypress documentation shows examples how you can use should() to verify elements are enabled/disabled: https://docs.cypress.io/api/commands/should.html#Assert-the-checkbox-is-disabled cy.get(':button').should('be.disabled')


5

It really depends on what you need. I've used both, so here's my opinion: Cypress seems better at handling waits (your point n. 2), this could be such a pain in other tools, but it's an internal part of Cypress, which usually makes you write tests faster and the tests tend to be a bit more stable. Selenium is almost always used with some programming/...


4

$() is equal to findelement(by.css('')). And in your case the locator is: .Typography__StyledTypography-sc-153d8g4-0 jhYDmS TrainingQueueListstyles__EmptyListMessage-sc-19yfim3-1 ihRiqU which means find the element with the class name as Typography.... But this is not a valid locator as it contains space after Typography__StyledTypography-sc-153d8g4-0. ...


4

There's no such concept of waiting or even writing your own waits (like with Selenium) in Cypress. Cypress has this built in. I recommend reading their docs, it's one of the core concepts mentioned here https://docs.cypress.io/guides/core-concepts/retry-ability.html#Commands-vs-assertions The point here is, you write something like: cy.get('.my_element') ...


4

Get the text and add to a array Convert array to set and compare the size Set will have only unique elements (Removes the duplicates) So if length of set and array are different , it means there where duplicate entries in the array. var arr = [55, 44, 65, 55]; var set = new Set(arr); console.log(set.size === arr.length); set.forEach(x => {console.log(x)});...


4

What you're describing is mentioned here in the Cypress documentation. Cypress documentation also mentiones some workarounds. I think the bottom line for you is this part: A common use case for this is Single sign-on (SSO). In that situation you may POST to a different server and are redirected elsewhere (typically with the session token in the URL). If ...


3

The creators have strong opinions on why you should not use conditional logic in your test however, Cypress doesn't disallow the use of javascript control methods. Cypress has a robust API you can use to easily test a site but it also allows javascript logic so using any of the control structures you listed above already are allowed. I know this comment ...


3

Depends on the goal of the test. I like to differentiate test goals, for example between: Pure Functional, Tests which check if the functionality works in general. This should work on a stable pipeline, simple and fast for quick feedback loops. Browser/OS/Device compatibility, tests to garantuee it works on multiple different devices. Now you need to ...


3

From what I remember Selenium handles iFrames and parallel testing far better than Cypress. Finally, If you learn cypress without learning selenium you won't build transferable skills. I'm a javascript dev, but if push came to shove I could probably write a test suite in Java or Python because the api is the same and there's plenty documentation (in fact, I ...


3

Michael Bolton proposes testing coverage as: “X coverage is how thoroughly we have examined the product with respect to some model of X”. And he completes: "Test coverage, like quality, is not something that yields very well to quantitative measurements, except when we’re talking of very narrow and specific conditions." Being that, you can think ...


3

Remember context - what works for some may not work for you. Other than the suggestions above, consider your system and think about what you need. Cypress is a popular tool but not every test tool is applicable to all systems.


3

It seems you want to wait until routes resolve. If that is the case, you need to explicitly tell Cypress to do just that. For example, if I want Cypress to wait for a specific route, I write it like so: cy.intercept('http://example.com/route').as('getRoute'); cy.wait('@getRoute'); // once the route resolves, cy.wait will resolve as well Or similar example ...


2

Usually my tests have one assertion per test. However for this specific issue for UI tests there is one single over-riding factor (in this discussion about 1 or many) and it is Performance In UI tests I intentionally break that rule for 1 reason - speed. UI tests, e.g. browser tests are very slow and if they are used to give quick feedback you have to ...


2

I decide these things by asking a question: If a responsibility fails one assertion, do I still want information from the other assertions? Usually the answer is yes, in which case I put the assertions in separate tests. But for some situations, a failure in one assertion renders some other assertions meaningless or distracting. For those situations, I ...


2

Here: if(cy.get('a.auth0-lock-alternative-link').contains('Not your account?')) { cy.get('a.auth0-lock-alternative-link').contains('Not your account?').click(); } to evaluate expression in if statement you call contains('Not your account?') method. Since contains method has the default assertion that makes your test fail once the element does not contain ...


2

Go Agile. Try it in small incremental steps. I would at least give it a chance for initial prototype by making a quick smoke suite out of it and see from there how it goes and will take further incremental steps as per the outcome.


2

Ok so there is a way, but I am not sure if this is "the" way when it comes to Cypress. You can write a recursive function that will call itself when the button is present. I have used a site which has a similar button and got it to work, the code would look something like this: function loadMoreProducts() { cy.get('body').then((body) => { if (...


2

You can use the beforeEach function to execute actions before every single test. The Cypress documentation gives an example of how you can use beforeEach, but it expects you to implement the resetDb function. This is not a generic function supplied by Cypress. Either remove the call to resetDb or implement it as a Cypress Custom Command.


2

E2E testing should be testing without stubbing and then having another layer for testing in isolation where stubbing will be more valuable. For the isolation testing, there may be some instances in which an application sends XHR on page load, so stubbing those requests would be beneficial for execution time.


2

Cypress stub() and spy() are adopted from Sinon.js spies and stubs. Based on Sinon documentation: When to use stubs? Use a stub when you want to: Control a method’s behavior from a test to force the code down a specific path. Examples >include forcing a method to throw an error in order to test error handling. When you want to prevent a ...


2

Cypress does not support file upload out of the box. However there are several workaround that might or might not work for your particular case. You can observe the official cypress github discussion where people suggest their workarounds for your issue.


2

I recently found this code working in my case where I wanted to check if the element was enabled for next actions: this.button().then(($btn) => { if ($btn.is("enabled")) { //do something } else { //do something else } }) // in cypress terms cy.get(':button').then((x) => { if (x.is("enabled")) { //do ...


2

It depends on the context. If your users are using different browsers and operating systems, or desktop/mobile versions of your app, or different versions of browsers, then it is a good idea to test on multiple build agents.


Only top voted, non community-wiki answers of a minimum length are eligible