I have a waitForSelector() that fails in 1/5 times due to some target-side JS sometimes loading after 5000ms, which causes Casper to stop operation.
How can I make casper continue operating if a waitForSelector() fails?
waitForSelector takes an onTimeout parameter, which if provided prevents the script from throwing an error.
http://docs.casperjs.org/en/latest/modules/casper.html#waitforselector
You would wrap it in a try catch.
try {
do the code that you need it to do.
}
catch (err) {
optional code if it fails.
}
Related
I have an 'afterEach' hook for each test. This will write some value to json.
The value for 'TestDetails' is available globally in in the test file.
afterEach(function () {
cy.readFile('cypress/dataFiles/data1.json').then(function (t1) {
t1["testDetails"] = testDetailsValue;
cy.writeFile('cypress/dataFiles/data1.json', JSON.stringify(t1));
})
})
The first test is login test and launching the browser and navigating to login page takes more than 10 seconds.
When test is executed, the below error is displayed:
CypressError: `cy.readFile("cypress/dataFiles/data1.json")` timed out after waiting `4000ms`.
Because this error occurred during a `after each` hook we are skipping the remaining tests in the current suite:
Due to this error, unable to write the value in json in after each hook.
Could anyone please help on this?
I think that means that your file doesn't exist. See https://docs.cypress.io/api/commands/readfile#Existence
I am attempting to use the Cypress (at 7.6.0) retries feature as per https://docs.cypress.io/guides/guides/test-retries#How-It-Works
but for some reason it seems to be not working, in that a test that is guaranteed to always fail:
describe('Deliberate fail', function() {
it('Make an assertion that will fail', function() {
expect(true).to.be.false;
});
});
When run from the command line with the config retries set to 1,
npx cypress run --config retries=1 --env server_url=http://localhost:3011 -s cypress/integration/tmp/deliberate_fail.js
it seems to pass, with the only hint that something is being retried being the text "Attempt 1 of 2" and the fact that a screenshot has been made:
The stats on the run look also to be illogical:
1 test
0 passing
0 failing
1 skipped (but does not appear as skipped in summary)
Exactly the same behavior when putting the "retries" option in cypress.json, whether as a single number or options for runMode or openMode.
And in "open" mode, the test does not retry but just fails.
I am guessing that I'm doing something face-palmingly wrong, but what?
I think your problem is that you are not testing anything. Cypress will retry operations that involve the DOM, because the DOM takes time to render. Retrying is more efficient than a straight wait, because it might happen quicker.
So I reckon because you are just comparing 2 literal values, true and false, Cypress says, "Hey, there is nothing to retry here, these two values are never going to change, I'm outta here!"
I was going to say, if you set up a similar test with a DOM element, it might behave as you are expecting, but in fact it will also stop after the first attempt, because when it finds the DOM element, it will stop retrying. The purpose of the retry is to allow the element to be instantiated rather than retrying because the value might be different.
I will admit that I could be wrong in this, but I have definitely convinced myself - what do you think?
Found the cause .. to fix the problem that Cypress does not abort a spec file when one of the test steps (the it() steps) fails, I had the workaround for this very old issue https://github.com/cypress-io/cypress/issues/518 implemented
//
// Prevent it just running on if a step fails
// https://github.com/cypress-io/cypress/issues/518
//
afterEach(function() {
if (this.currentTest.state === 'failed') {
Cypress.runner.stop()
}
});
This means that a describe() will stop on fail, but does not play well with the retry apparently.
My real wished-for use case is to retry at the describe() level, but that may ne expensive as the above issue just got resolved but the solution is only available to those on the Business plan at $300/mo. https://github.com/cypress-io/cypress/issues/518#issuecomment-809514077
I have built my own error handing in OpenScript osing standard Java
try{
}
catch () {
}
Everything works correctly, It handles exception correctly.
But the problem is that afterwards script does not go to the next iteration, but just calls the public void finish() throws Exception {}
How can I make script go to the next iteration after successfully handling of the exception?
Ok, I found the solution.
The situation is that if OpenScript generates one of its own exceptions (e.g. form is not found), than even if you catch it using standard java syntax, then this execution handling seems to be working, but script does not go to the next iteration.
So, the solution is as follows: (it is actually described in documentation):
beginStep("Trying to execute code, which may go wrong", 0);
// Setting error recovery to warning, so the script will not halt
setErrorRecovery(FormsErrorRecovery.ERR_FORMS_FT_ERROR, ErrorRecoveryAction.Warn);
/*
Some code, which can generate error (e.g. form is not found) needs to go here
*/
// setting error recovery back to Fail, so the script will halt at unexpected error
setErrorRecovery(FormsErrorRecovery.ERR_FORMS_FT_ERROR, ErrorRecoveryAction.Fail);
endStep();
// The hasLastError variable is automatically set to true if there was an error in the previous beginStep() --- endStep() block.
if(!hasLastError()){
/* code goes here to be executed if there was no error */
}
else {
/* code goes here to execute if there was an error */
}
This question has been asked before, but the answer given was to re-write the specific code that was used in that case.
The Mocha documentation only mentions changing the duration of timeouts, and not the behaviour on timeout.
In my case, I want to test code that under certain conditions does not have any side effects. The obvious way to do this is to call the code, wait for Mocha to time out, and then run some assertions on my spies, e.g.:
this.onTimeout(function() {
assert.equal(someObject.spiedMethod.called, false);
});
someAsyncFunction();
Is this possible, or do I have to resort to setting my own timeout, e.g.:
// 1. Disable the mocha timeout
this.timeout(0);
// 2. create my own timeout, which should fire before the mocha timeout
setTimeout(function() {
assert.equal(someObject.spiedMethod.called, false);
done();
}, 2000);
someAsyncFunction();
Mocha's own timeouts are designed only to detect when tests are considered to be slow beyond anything reasonable. An asynchronous computation could be buggy in such a way that causes it to never terminate. Rather than wait forever, Mocha lets you decide that after X time it should fail the test. As soon as the timeout is hit, Mocha gives up on the test that timed out.
So you have to set your own timeouts.
Was facing a similar problem & also didn't find a way to do that in mochajs.
However, if you want to run some code on test timeout, you could structure your code like this:
describe('something', function() {
const TEST_TIMEOUT = 10000
this.timeout(TEST_TIMEOUT)
beforeEach('set timeout callback', function() {
setTimeout(function() {console.log('hi')}, TEST_TIMEOUT)
})
})
A few caveats:
1- I'm not sure if it'd affect a test's result. But if it were to, I'd setTimeout with TEST_TIMEOUT minus some time to make sure my assertions run before the mochajs timeout fires.
2- On the contrary, if the goal of the callback is not to do some assertions but to run some code (e.g., cleanup or logging), I'd set the timeout to be TEST_TIMEOUT plus some time.
Starting with mocha v4 (or with --no-exit flag in previous versions), as long as you have a timeout (or other handlers/the process didn't terminate), mocha will not force exit as it used to, so you can be comfortable your code will run.
I'm running a persistable Workflow in an MVC 3 Application, which is working out well, but when the workflow is completed, a WorkflowApplicationCompletedException is thrown. The Workflow is completed sucessfully, the last actions done and the instance deleted from the database.
I've had no luck searching for an answer so far, so any ideas what is causing the exception would be appreciated. My current workaround is catching the exception and doing my stuff there for the OnCompleted-Event.
I'm simply creating a WorkflowApplication, loading it and resuming the bookmark.
Any hints or suggestions appreciated.
Thanks
application.Load(new Guid(basket.StandardFields.Settings));
application.ResumeBookmark(application.GetBookmarks().First().BookmarkName, WorkflowInputs);
application.PersistableIdle = delegate(WorkflowApplicationIdleEventArgs e)
{
if (e.Bookmarks != null && e.Bookmarks.Count > 0)
{
_viewName = e.Bookmarks[0].BookmarkName;
}
syncContext.OperationCompleted();
return PersistableIdleAction.Unload;
};
application.Completed = delegate (WorkflowApplicationCompletedEventArgs e)
{
CompleteWorkflow(syncContext);
};
application.SynchronizationContext.OperationStarted();
try
{
application.Run();
}
catch(WorkflowApplicationCompletedException)
{
CompleteWorkflow(syncContext);
}
Edit
It seems that the application.ResumeBookmark(bookmark, WorkflowInputs) starts the Workflow and Completes the activities, then when I call run, it complains the it's already completed. But if I don't call run when resume workflow is called, the browser never gets any information and I think it stays waiting endlessly cause not even a refresh can knock it out of the waiting state.
It seems that with ResumeBookmark there is no need to call Run afterwards. I think I was doing it at the wrong place before and so the workflow got messed up, but it seems to be working fine now.
if(hasWorkflow)
application.ResumeBookmark(application.GetBookmarks().First().BookmarkName, WorkflowInputs);
else
application.Run();
MSDN:
Represents the exception that is
thrown when an operation on a workflow
instance is not valid because the
instance has completed.
The code you show appears valid. However, somewhere you are attempting to resume a workflow that has entered the completed state. You should be checking the Completed property of any Workflow you are attempting to resume. Thrown an InvalidOperationException and you'll see where this is happening.
If this doesn't identify where the problem is, your workflow may not be bookmarking properly. That code is in the activity that is creating the bookmark, so I can't tell if it is being done correctly...