WebDriverWait timeout waits for the driver implicit timeout instead of the explicit timeout provided - selenium-webdriver

I am using python with Selenium WebDriver to test an angular based web-app.
In the login helper subroutine, on login, I want to check if it was successful before continuing with rest of the tests.
For this , I have the following piece of code:
login_success = WebDriverWait(self.driver,5).until(EC.visibility_of_element_located((By.CLASS_NAME,"hr-landing")))
if login_success:
self.logger.info("Looks like login was successful")
else:
login_errors = self.get_login_errors()
self.logger.debug(login_errors)
The problem I am facing is with the first line in the code. For a successful login, it returns quickly as the class 'hr-landing' is found.
However, for a failed login, that class is not found , and I wish for the Wait to timeout in 5 seconds as specified in my call to WebDriverWait.
However, the call times out only after 30 seconds (which is the implicit wait I have set on my driver)
How can I get around this issue ? I feel there is no point to providing the explicit timeout , because it is still respecting the implicit one.
Thanks a lot !
Moez.

This is the issue generally we face when both implicit and explicit waits are used. On fail get_login_errors() is called so i am expecting it have implicit waits.
To avoid such issues i hope good to use fluent waits which explained here
Thank You,
Murali

Related

Can the time out issue be the consequence of browser.sleep() and browser.waitForAngular?

In protractor scripts i'm always having problem of time out, even if i put a big time out jasmine interval, allscripttimeout...
And in some places i'm obliged to wait until element are present like in home page until the url is totally loaded.
Can the time out issue be the consequence of
browser.sleep(time_ms);
browser.waitForAngular();
If so, how can i fix this problem ?
Here the problem in details
Thanks,
Yes they could be -- browser.sleep() would only timeout if you had it sleep longer than your Jasmine timeout interval (default is 30 seconds).
browser.waitForAngular() is automatically applied to every webDriver action by Protractor so you shouldn't need to call it. If this time's out then your app is still synchronizing something.
Both of these would result in A Jasmine spec timed out. Resetting the WebDriver Control Flow. following by Error: Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL. if it takes too long.
I'm not positive how you would fix it - you've had a lot of questions about timeouts (for good reason), but at this point I think you need to use browser.ignoreSynchronization = true; and treat your app as non-Angular if you're having this many timeout issues. Something is preventing synchronization from finishing.
There are several helper methods that you can create and execute seamlessly on non-Angular apps by extending Protractor's functions to avoid explicit browser.sleep()'s . For example, the below code pauses test execution until isPresent returns true (or until a failure by exceeding the timeout I specified)
Util.prototype.waitForElementPresent = function (el, time) {
var timeout = time || 0,
return browser.wait(function() {
return el.isPresent();
}, timeout)
};

Selenium Chrome Webdriver Implicit wait()

I am beginner in Selenium. Tried with basic webpage open, timeout and close with the below code. But the browser is closing without performing wait(). What could be the problem here. ?
WebDriver SDriver = new ChromeDriver();
SDriver.get("https://www.google.co.in");
SDriver.manage().window().maximize();
SDriver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
SDriver.close();
An implicit wait only occurs if you're searching for an element, but can't find it.
So if you're searching for something, and you set implicit wait to 10 seconds, it'll wait a maximum of 10 seconds before it cancels, since it didn't find the element in time.
What you meant to use was an explicit wait, which is, in your scenario, essentially similar to calling Thread.sleep().

What is Selenium WebDriver's default implicit wait value?

What is Selenium WebDriver's default implicit wait value?
The selenium documentation says that it is "0" but when I call .findElement on a brand new project, where a element doesn't exist on the DOM, it seems to get a TimeoutException after a while rather than hang indefinitely. Does "0" mean wait forever or not?
The default value for implicit waits is indeed zero, which means (and always has meant) "fail findElement immediately if the element can't be found." You shouldn't be receiving a TimeoutException directly from findElement. You'll likely only be receiving that when using a so-called "explicit wait", using the WebDriverWait construct.
I believe, in SeleniumBasic at least, the implicit wait is 3000ms, or 3 seconds. You can find out for yourself by simply using msgbox(driver.timeouts.implicitwait()).

App Engine: Is it possible to enqueue tasks asynchronously?

Many of my handlers add a task to a task queue to do non-critical background processing. Since this processing isn't critical, if the call to taskqueue.add() throws an exception, my code just ignores it.
Tonight the task queue seemed to be down for around half an hour. Although my handlers correctly ignored the failure, they took about 5 seconds for the taskqueue.add() call to timeout and move on to processing the rest of the page. This therefore made my site run very slowly.
So, is it possible to enqueue a task asynchronously - meaning a way to add a task, without waiting to see if the addition succeeded?
Alternatively, is there a way to reduce that timeout from 5 seconds down to eg 1 second?
Thanks.
You can use the new taskqueue methods create_rpc and add_async. If you don't care if the add succeeds, simply call add_async and ignore the result. If you care, but only want to wait 1 second, set the deadline when calling create_rpc, and use the return value as the RPC argument to add_async. Call get_result to find out if the tasks were successfully added.
I think you can't do anything about it because the RPC call underneath the add method is a synchronous blocking API call.
You could try to add some check using the Capabilities API.
I am pretty sure GAE announced that TQ adds will be async with the next release (experimental feature).

Why does my Wcf Duplex service gets in faulted state after first call to the service?

What I am trying to do is have a wcf duplex service that multiple clients register to. When a client calls the service, the other clients are notified of the call.
Right now, I have a Silverlight app that calls a wcf duplex service. On the first call everything is working correctly including duplex communication. On the second call to the service I am getting a :
The communication object, System.ServiceModel.Channels.ClientPollingDuplexSessionChannel, cannot be used for communication because it is in the Faulted state.
My service has 2 different methods; RegisterClient and ReassignOwner. If I call the same method twice or both method once in any order I am still getting this error.
After researching on the subject I thought it might be a timeout problem. I checked what the default timeout value was and it's 10 minutes. I do both calls within the span of 2-3 minutes tops. I have also increased the Inactivity timeout and the Receive timeout to 4 hours just to be sure and I am still getting this problem.
Next, I thought my service might be generating an exception which would cause the client to go in a faulted state. To test this, I have put try/catch statements in the 2 methods of my service and ran the program in debug mode. I did not catch any exception. I also tried commenting out all the code from those 2 methods (so no exception can be generated) and just calling those 2 empty methods and I still got the exception.
By reading other related post here on SO, I decided to try WCF tracing. I enabled it in my web.config and set the switch value to Warning. I get 2 warnings:
Description Faulted System.ServiceModel.Channels.ServicePollingDuplexSessionChannel
Description Faulted System.ServiceModel.Channels.ServiceChannel
Here is how my service is defined in the code behind .svc.cs file:
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single, AutomaticSessionShutdown = false)]
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
public class NotificationService : BaseService, INotificationDuplexService
In my service contract my methods both have the following attributes:
[OperationContract(AsyncPattern = true, IsOneWay = true,
Action = "http://www.abc.org/NotificationDuplex/INotificationDuplexService/MethodName")]
Both my methods are implemented in an async fashion with a Begin and an End method.
Here is how I invoke my methods
base.InvokeAsync(this.onBeginRegisterClientDelegate, new object[] {
id}, this.onEndRegisterClientDelegate, this.onRegisterClientCompletedDelegate, userState);
Anybody know why this is happening or have any clue to how I could continue trying to solve this problem ?
Does your ServiceContract require a CallbackContract? If so, I suggest that you read about callback reentrancy here - it's a good description of how WCF can proactively fault your communication channels to prevent a deadlock when you are using callbacks, and what you should do to prevent it.
Another solution which I have seen referenced and I implemented myself is to set up a "heartbeat." I have my configuration set to MultipleMessagesPerPoll, and the service keeps running without a problem because I have the client pinging the server at least once every 9 seconds. That seemed to be a bit of a magic number -- after nine seconds the channel times out and goes into a faulted state. Just set up a thread to ping the service (using a method called ping or something) and the service can respond back to the client with a "pong."
Agree that this problem does not seem to be a problem on Chrome or other browsers.
Finally I have found the awnser in a similar question : Silverlight PollingDuplex InnerChannel faulted with multipleMessagesPerPoll (serverPollTimeout)
It seems there is a bug when you set the PollingDuplexHttpBinding to PollingDuplexMode.MultipleMessagesPerPoll and you run your application under IE 8 (other browsers aren't affected).
The solution is to put the PollingDuplexMode to SingleMessagePerPoll which is less performant but focntionnal in IE8.

Resources