protractor what does the timeout in expected conditions stand for? - protractor

Protractor: Version 1.8.0
browser.wait(EC.presenceOf(element), 3000);
what exactly does the 3 seconds stand for? and is there an error thrown when 3 seconds have passed and element cannot be found? or does the test just continue?
I ran a test with:
element(by.id('#input')).sendKeys('foo');
browser.wait(EC.presenceOf(element(by.xpath(BAD-LOCATOR)), 3000));
element(by.id('#input')).sendKeys('bar');
BAD-LOCATOR is just a xpath referencing a element that doesn't exists. but upon evaluating this line, the test waits beyond this time until it hits the jasmine defaultTimeoutInterval timeout (I set for 25sec). Why does it not fail in 3 secs since the promise did not get resolved in 3secs? I'm expecting the wait() to fail and the 2nd sendKeys command to execute since its next in control flow.
So the above block of code will print 'foo' into the textbox and on the next command wait until the jasmine timeout to error out (Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.). I'm expecting an error within 3secs. 'bar'never gets printed.

It's the time out, i mean after 3 seconds if the element isn't present until now it will time out.
For the jasmine error you are getting i suggest that you add the call back
describe("long asynchronous specs", function() {
beforeEach(function(done) {
done();
}, 1000);
You can also refer to Jasmine Asynchronous Support

Related

Webflux: OnErrorResume after repeats are exhausted is not being triggered

I am trying to execute the code after repeat exhaustion using onErrorResume but onErrorResume is not being trigger.
Here is the code sample
Mono.just(request)
.filter(this::isConditionSatified)
.map(aBoolean -> performSomeOperationIfConditionIsSatified(request))
.repeatWhenEmpty(Repeat.onlyIf(i -> true)
.exponentialBackoff(Duration.ofSeconds(5)), Duration.ofSeconds(10))
.timeout(Duration.ofSeconds(30)))
.delaySubscription(Duration.ofSeconds(10)))
.onErrorResume(throwable -> {
log.warn("Max timeout reached", throwable);
return Mono.just(false);
});
onErrorResume is never trigged. I am trying to use it as a fallback. My goal is if the repeat exhaustion is hit, return the false value.
My unit test complains of
expectation "expectNext(false)" failed (expected: onNext(false); actual: onComplete())
Any help or suggestion would be helpful.
since an empty source is valid by itself, repeatWhenEmpty doesn't necessarily propagate an exception after exhausting its attempts. The Repeat util from addons doesn't, even when the "timeout" triggers (as hinted in the timeout parameter's javadoc: "timeout after which no new repeats are initiated", ok that could be clearer).
since you're using repeatWhenEMPTY, I'm guessing that the empty case is always "irrelevant" to you and thus defaultIfEmpty(false) should be the acceptable solution.

If one Expect fails in protractor, will the spec execution continues?

I have two "expect" in my it block and my first it block failed,it still continues the execution and executing the rest of the code in my it block.
My expectation is, if first it block failed, execution stops right there and next it block should get executed.
it ("My se", function() {
expect(true).toBe(false);// it is failing
//my rest of my below code should not get executed.
My functionality code
expect(array[0]).toBe("foo");
});
it ("Second it block", function() {
//Continue the execution
});
Could some please help me with some idea, how i can achieve this. My execution of that particualr it block should stop and the next it should continue.
Ideally, expect statement should be the last statement of the it block. You need to update the test in that way to achieve the desired results.

ignore.synchronization=true/ browser.waitforAngularEnabled(true) takes so long when compared to browser.sleep()

While executing e2e tests in protractor when we are using ignore.synchronization=true/ browser.waitforAngularEnabled(true) to handle waits is too slow when compared to browser.sleep(10000) to proceed to next step. How to address these kind of wait issues to make the script execution faster?
Difference:
ignore.synchronization=true/ browser.waitforAngularEnabled(true) are used to make protractor wait until all the angular modules are loaded.
browser.sleep(// time in ms) is raw way of stopping the protractor for the given particular ms.
Solution:
To handle wait issues:
use browser.waitforAngularEnabled(false) after getting your base url. Then you can use expected waits which makes the protractor wait until that expectation is completed.
Refer https://www.protractortest.org/#/api?view=ProtractorExpectedConditions for more details
Hope it helps you

How to make Protractor's browser.wait() more verbose?

In Protractor tests I call many times browser.wait method for example to wait once the particular element will appear on the screen or it will be clickable.
In many cases tests passes on my local machine, but does not on other.
I receive very generic information about the timeout which doesn't help me a lot to debug / find a source of issue.
Is it possible to make a browser.wait more verbose, for example:
if at least defaultTimeoutInterval will elapse when waiting for particular element, will it be possible to console.log information about the element that it tried to wait for,
take a screenshot when the timeout error occurs,
provide full call stack when timeout appears in browser.wait
If the main issue is that you don't know for which element the wait timed out, I would suggest writing a helper function for wait and use it instead of wait, something like:
wait = function(variable, variableName,waitingTime){
console.log('Waiting for ' + variableName);
browser.wait(protractor.ExpectedConditions.elementToBeClickable(variablename),waitingTime);
console.log('Success');
}
Because protractor stops executing test after first fail, if wait timed out, console won't print success message after failing to load a certain element.
For screenshots I suggest trying out protractor-jasmine2-screenshot-reporter, it generates an easily readable html report with screenshots and debug information on failed tests (for example, in which code line the failure occured).
Look into using protractor's Expected Condition, you can specify what to wait for and how long to wait for it.
For screenshots there are npm modules out there that can take a screenshot when a test fails. This might help.
browser.wait returns a promise, so catch the error and print/throw something meaningful like:
await browser.wait(ExpectedConditions.visibilityOf(css), waitingTime).catch((error) =>
{
throw new CustomError(`Could not find ${css} ${error.message}`)
});

Not recovering from an f5 drop during spock test

Has anyone ever created a successful Spock test against an f5 dropped connection?
In my f5 rule, if a situation is satisfied - say a bad cookie, I drop the connection
if { [HTTP::cookie exists "badCookie"] } {
if { not ([HTTP::cookie "badCookie"] matches_regex {^([A-Z0-9_\s]+)$}) } {
drop
}
}
Testing this manually, in a browser, results in a slow but eventual timeout, time limit depending on the browser. But rather than manual tests for each of the f5 rules, I'd like to instead incorporate my tests into our Spock functional test library.
Using Spock, #Timeout() or #Timeout(value=5) just ends up doing a never ending increase in the timeout like:
[spock.lang.Timeout] Method 'abc' has not yet returned - interrupting. Next try in 0.50 seconds.
[spock.lang.Timeout] Method 'abc' has not yet returned - interrupting. Next try in 1.00 seconds.
[spock.lang.Timeout] Method 'abc' has not yet returned - interrupting. Next try in 2.00 seconds.
[spock.lang.Timeout] Method 'abc' has not yet returned - interrupting. Next try in 4.00 seconds.
[spock.lang.Timeout] Method 'abc' has not yet returned - interrupting. Next try in 8.00 seconds.
[spock.lang.Timeout] Method 'abc' has not yet returned - interrupting. Next try in 16.00 seconds.
Using the waitFor method approach in http://fbflex.wordpress.com/2010/08/25/geb-and-grails-tips-tricks-and-gotchas/ or https://github.com/hexacta/weet/blob/master/weet/src/groovy/com/hexacta/weet/pages/AjaxPage.groovy does not close out the method using a 5 second specification either.
An example of the code using each of those approaches (timeout class, timeout method, and waitFor) is at https://gist.github.com/ledlogic/b152370b95e971b3992f
My question is has anyone found a way to successfully run a Spock test to verify f5 rules are dropping connections?
For me using the #ThreadInterrupt annotation alongside the #Timeout annotation worked:
#ThreadInterrupt
#Timeout(value = 100, unit = MILLISECONDS)
def 'timeout test'() {
expect:
while(1) {true}
}
You'll find the full documentation here: http://docs.groovy-lang.org/docs/next/html/documentation/#GroovyConsole-Interrupt
However, this may not be sufficient to interrupt a script: clicking
the button will interrupt the execution thread, but if your code
doesn’t handle the interrupt flag, the script is likely to keep
running without you being able to effectively stop it. To avoid that,
you have to make sure that the Script > Allow interruption menu item
is flagged. This will automatically apply an AST transformation to
your script which will take care of checking the interrupt flag
(#ThreadInterrupt). This way, you guarantee that the script can be
interrupted even if you don’t explicitly handle interruption, at the
cost of extra execution time.