In my Cypress tests, I create some data in before block and then my test script is run that locates in it block. I checked business side flow and it seems like there is no error about app side. I just want to understand that why my test's result is success after second attempt. Does Cypress has this kind of solution to handle an error maybe?
Cypress has the ability to automatically retry any failed tests. I would check your Cypress configuration's value for retries.openMode.
Related
I have cypress UI tests running remotely. Our authentication team has recently made a change that redirects the page twice, previously only once. This change has caused my tests to fail at cy.visit('/') with error "Exceeded maxRedirects. Probably stuck in a redirect loop https://mybetawebsite/redirect=signin&redirect=signin"
When I asked them about this erorr, they told me to follow the redirect a second time.
I know cy.visit follows redirects
(https://docs.cypress.io/api/commands/visit#Redirects) , but it does only once or multiple times?
Previously, when my tests were passing, I could see 302(redirection) at cy.visit (to different url for auth) and test used to continue and pass.
in my cypress.json,
baseUrl: https://mybetawebsite
How do I handle second redirect?
When I run a suite of tests using Cypress, I get a TON of HTTP request logs to the terminal output. I think this image best shows the issue. In it, you can see the command I run to start cypress, and that following it comes a long list of every HTTP request made during the tests.
Is there a way to hide them all?
You can add the following to cypress.json:
"morgan": false,
The logs you see are from express (a built-in server within cypress).
I have a test suite of around 1000 test cases, but sometimes if one test case fails due to some unclosed popup window, all of the subsequent test cases will also fail because the popup modal will not allow protractor to interact with page elements.(My app is that way)
So I want to create some condition such as i will refresh the page if a test case fails or I will go to my homepage link if test case fails as all tc's start from same starting point.
This will prevent all my subsequent test cases from failing. This method was called recovery scenario in QTP/UFT days.
I was also facing these kind of issue that if one test case fails subsequent all test cases will fail,Not sure if there is any recovery scenarios available in protractor but I am using before all, after all, before each and after each to start my each test from a clean state. I have added a helper function to navigate to Home page and I call every time this function from before each.
this is helpful link
Before all my tests (running in jasmine under protractor) I have to login to my system and if login fails I should not run any test. But even when I use proccess.exit (which is node feature to halt program execution), tests are still executed and all failed .
beforeAll(function(done){
mainPage.resize();
loginPage.login(env.regularUser).then(function(){
mainPage.navigate();
mainPage.waitLoading();
done();
}, function(){
process.exit(1);
});
});
How can I prevent tests execution in beforeAll block?
If I understand correctly, this is the same or a related problem to:
Does jasmine-node offer any type of "fail fast" option?
Feature Request - fail-fast option
Bail on first failure
--fail-fast CLI option
Quitting on first failure
In other words, this is something a testing framework (in this case jasmine) should have. At the moment, this is an open feature request.
As a current workaround, use jasmine-bail-fast third-party package.
Even when all tests are passing, I see many many instances of this message amid the successful test output:
...
in the single-post view
behaves like editing a comment
HTTP request failed.
HTTP request failed.
HTTP request failed.
...
What is causing it?
One possibility is that requests made by for example third-party analytics scripts on your page are failing.
You can see their activity by inspecting the output of poltergeist's page.driver.network_traffic at the end of a test.
If you think this is the problem, you could take those scripts out of the picture by
including them in the page only if you're not running tests, or
using poltergeist's page.execute_script to replace appropriate functions in those third-party scripts with no-op functions. (That takes more work but leaves the page contents more production-like, which might catch a few more possible errors.)