I'm using Selenium to do some automated testing in a C# app. I have a component that's not disappearing after the 90 seconds explicit wait. Is there an upper limit to the timeout:
Driver.WaitUntil(ExpectedConditions.InvisibilityOfElementLocated(By.CssSelector("section > h1 > img")), 90);
I haven't found anything indicating there's an upper limit.
Cannot say about explicit wait upper limit, but if you want to make it more you can put the wait in loop. So the loop will make it 90*number of loops.
WebDriverWait constructor is WebDriverWait(IWebDriver, TimeSpan) TimeSpan has several properties, one of them is Days, witch receives double as parameter. So theoretically you can do
WebDriverWait wait = new WebDriverWait(driver, TimeSpan.FromDays(double.MaxValue));
And see what happens first, your explicit wait ends or the sun goes supernova :)
(The script will probably crash much sooner).
Related
I am using selenium for a while and have some question about the IWebElement Wait procedure.
We have the Explicit Wait and Implicit I use them and understand the meaning but..
How can I make selenium no wait for element at all?
I tried not to use wait functions but still when I call FindElement or GoToUrl its not always return immediately sometimes still wait for 0 to 60 sec
I noticed that in most of time the wait in FindElement didn't return the element and wait for no reason.
for example: call for element id can take 3 sec and not immediately (lot off calls lot of time...)
maybe I am doing something wrong.
the main purpose is to take full control of the program and handle the wait time myself (for better efficiency)
maybe there are better articles to understand selenium architecture of finding elements ? (not the selenium API)
(I am using latest version of selenium 2.48.0)
Code example:
driver = new FirefoxDriver();
js = driver as IJavaScriptExecutor;
driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(0));
driver.Manage().Window.Maximize();
driver.Navigate().GoToUrl("someUrl");
IList<IWebElement> loginFrame = driver.FindElements(By.TagName("iframe"));
driver.SwitchTo().DefaultContent().SwitchTo().Frame(loginFrame[0]);
driver.FindElement(By.Id("userID")).SendKeys("username");
driver.FindElement(By.Id("userPassword")).SendKeys("userPassword");
driver.FindElement(By.Id("login")).Click();
driver.SwitchTo().DefaultContent();
driver.FindElement(By.XPath("//div[#class='something']/ul/li[2]/a")).Click();
driver.FindElement(By.PartialLinkText("someText")).Click(); // *
At Last call its throw exception after something like 3 ~ 5 seconds and not immediately (When I set Implicit to 60 sec it's find the element!)
I am not sure what you mean by "how can I make selenium no wait for element at all? "
If you mean that you dont want selenium to wait at all for an element at all. I think this might work -
driver.manage().timeouts().implicitlyWait(0, TimeUnit.SECONDS);
WebElement textbox = driver.findElement(By.id("textbox"));
Use this and write your own method which takes a locator and no of seconds to wait and then set the implicit wait inside the method depending on what has been passed to the method.
public WebElement locateElementById(int timeInSec, String id){
driver.manage().timeouts().implicitlyWait(timeInSec, TimeUnit.SECONDS);
WebElement element = driver.findElement(By.id(id));
return Element
}
Something like this. And then you can call it with the seconds you want.
when you want 0 seconds pass 0 when you want 10 seconds pass 10.
I wants to apply dynamic wait in ranorex.
To open a webpage I used static wait like this :-
Host.Local.OpenBrowser("http://www.ranorex.com/Documentation/Ranorex/html/M_Ranorex_WebDocument_Navigate_2.htm",
"firefox.exe");
Delay.Seconds(15);
Please provide me a proper solution in details. Waiting for your humble reply.
The easiest way is use the wait for document loaded method. This allows you to set a timeout that is the maximum to wait, but will continue when the element completes it's load. Here is the documentation on it,
http://www.ranorex.com/Documentation/Ranorex/html/M_Ranorex_WebDocument_WaitForDocumentLoaded_1.htm
First of all, you should be more detailed about your issues. Atm you actually don't state any issue and don't even specify the reason for the timeout.
I don't actually see why you would need a timeout there. The next element to be interacted with in your tests will have it's own search timeouts. In my experience I haven't had a need or a reason to have a delay for the browser opening.
If you truelly need a dynamic delay there, here's what you actually should validate.
1) Either select an element that always exists on the webpage when you open the browser or
2) Select the next element to be interacted with and build the delay ontop of either of these 2
Let's say that we have a Input field that we need to add text to after the page has opened. The best idea would be do wait for that element to exists and then continue with the test case.
So, we wait for the element to exist (add the element to the repository):
repo.DomPart.InputElementInfo.WaitForExists(30000);
And then we can continue with the test functionality:
repo.DomPart.InputElement.InnerText = "Test";
What waitForExists does is it waits for 30 seconds (30000 ms) for the element to exists. It it possible to catch an exception from this and add error handleing if the element is not found.
The dynamic functionality has to be added by you. In ranorex at one point you will always run into a timeout. It might be a specified delay, it might be the timeout for a repo element, etc. The "dynamic" functionality is mostly yours to do.
If this is not the answer you were looking for, please speicify the reason for the delay and i'll try to answer your specific issue more accurately.
I have a small problem regarding threading in C#.
For some reason, my thread speeds up from 32ms delay to 16ms delay when I open Chrome, when I close Chrome it goes back to 32ms. I'm using Thread.Sleep(1000 / 60) for the delay.
Can somebody explain why this is happening, and maybe suggest a possible solution?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading;
namespace ConsoleApplication2
{
class Program
{
static bool alive;
static Thread thread;
static DateTime last;
static void Main(string[] args)
{
alive = true;
thread = new Thread(new ThreadStart(Loop));
thread.Start();
Console.ReadKey();
}
static void Loop()
{
last = DateTime.Now;
while (alive)
{
DateTime current = DateTime.Now;
TimeSpan span = current - last;
last = current;
Console.WriteLine("{0}ms", span.Milliseconds);
Thread.Sleep(1000 / 60);
}
}
}
}
Just a post to confirm Matthew's correct answer. The accuracy of Thread.Sleep() is affected by the clock interrupt rate on Windows. It by default ticks 64 times per second, once every 15.625 msec. A Sleep() can only complete when such an interrupt occurs. The mental image here is the one induced by the word "sleep", the processor is in fact asleep and not executing code. Only that clock interrupt is going to wake it up again to resume executing your code.
Your choice of 1000/60 was a very unhappy one, that asks for 16 msec. Just a bit over 15.625 so you'll always wake back up at least 2 ticks later: 2 x 15.625 = 31 msec. What you measured.
That interrupt rate is however not fixed, it can be altered by a program. It does so by calling CreateTimerQueueTimer() or the legacy timeBeginPeriod(). A browser in general has a need to do so. Something simple as animating a GIF requires a better timer since GIF frame times are specified with a unit of 10 msec. Or in general any multi-media related operation needs it.
A very ugly side-effect of a program doing this is that this increased clock interrupt rate has system-wide effects. Like it did in your program. Your timer suddenly got accurate and you actually got the sleep duration you asked for, 16 msec. So Chrome is changing the rate to, probably, 1000 ticks per second. The maximum supported. And good for business when you have a competing operating system.
You can avoid this problem by picking a sleep duration that's a closer match to the default interrupt rate. If you ask for 15 then you'll get 15.625 and Chrome cannot have an effect on that. 31 is the next sweet spot. Etcetera, integer multiples of 15.625 and rounded down.
UPDATE: do note that this behavior changed just recently. Starting at Win10 version 2004, the effect is no longer global so Chrome can no longer affect your program.
Starting at Win11, an app with an inactive window operates with the default interrupt rate.
This is possibly occurring because Chrome (or some component of Chrome) is calling timeBeginPeriod() with a value that increases the resolution of the Windows API function Sleep(), which is called from Thread.Sleep().
See this thread for more information: Can I improve the resolution of Thread.Sleep?
I noticed this behavior with Windows Media Player some years ago: The behavior of one of our applications changed depending on whether Windows Media Player was running or not. It turned out, WMP was calling timeBeginPeriod().
However, in general, Thread.Sleep() (and by extension, the Windows API Sleep()) is extremely inaccurate.
Basically, Thread.Sleep isn't very accurate.
Thread.Sleep(1000/60) (which evaluates to Thread.Sleep(16)), asks the thread to go to sleep and come back when 16ms has elapsed. However, that thread might not get to execute again until a greater amount of time has elapsed; say, for example, 32ms.
As for why Chrome is having an effect, I don't know but since Chrome spawns one new thread for each tab, it'll have an effect on the system's threading behaviour.
First, 1000 / 60 = 16 ms
The PC clock has a resolution of around 18-20ms, Sleep() and the result of DateTime.Now will be rounded to a multiple of that value.
So, Thread.Sleep(5) and Thread.Sleep(15) will delay for the same amount of time. And that can be 20, 40 or even 60 ms. You do not get much guarantees, the argument for Sleep() is only a minimum.
And another process (Chrome) that hogs the CPU (even a little) can influence the behavior of your program that way. Edit: that is the reverse of what you're seeing, so something a little else is happening here. Still, it's about rounding to timeslices.
You are hitting a resolution issue with DateTime. You should use Stopwatch for this kind of precision. Eric Lippert states that DateTime is only accurate to around 30 ms, so your readings with it in this case will not tell you anything.
Measurement is half of your problem. The actual time variation for your loop is due to Sleep resolution (as stated in the other answers).
This question is about System.Threading.Thread.Sleep(int). I know there is no method for a decimal value, but I really need to work with decimals.
I have a device which takes 20.37 milliseconds to turn by 1 degree. So, I need to put the code to sleep for an appropriate multiplication of 20.37 (2 degrees = 20.37*2 etc). Since the thread class got no decimal sleep method, how can I do this?
That does not work that way. Sleep will grant you that the thread sats idle for x time, but not that it won't stay idle for more. The end of the sleep period means that the thread is available for the scheduler to run it, but the scheduler may chose to run other threads/processes at that moment.
Get the initial instant, find the final instant, and calculate the current turn by the time passed. Also, do not forget to check how precise the time functions are.
Real-time programming has some particularities in its own as to advice you to seek for more info in the topic before trying to get something to work. It can be pretty extensive (multiprocessing OS vs monoprocessing, priorities, etc.)
Right, as pointed out in the comments, Thread.Sleep isn't 100% accurate. However, you can get it to (in theory) wait for 20.27 milliseconds by converting the milliseconds to ticks, and then making a new TimeSpan and calling the method with it, as follows:
Thread.Sleep(new TimeSpan(202700))
//202700 is 20.27 * TimeSpan.TicksPerMillisecond (which is 10,000)
Again, this is probably not going to be 100% accurate (as Thread.Sleep only guarantees for AT LEAST that amount of time). But if that's accurate enough, it'll be fine.
You can simply divide the integer - I just figured that out.
I needed less than a milisecond of time the thread sleeps so I just divided that time by an integer, you can either define a constant or just type in:
System.Threading.Thread.Sleep(time / 100);
Or what number you want.
Alternatively, as mentioned, you can do it like:
int thisIsTheNumberYouDivideTheTimeBy = 100;
Thread.Sleep(time / thisIsTheNumberYouDivideTheTimeBy);
Its actually quite simple. Hope that helped.
By the way, instead of
System.Threading.Thread.Sleep(x);
you can just type
Thread.Sleep(x);
unless you haven't written
using System.Threading;
in the beginning.
I had the same problem. But as a work around, i substitute the float vslie but convert to int value in the passing. The code itself rounds off for me and the thread sleeps for that long. As i said, its a work around and i'm just saying, not that it's accurate
You can use little bit of math as a workaround.
Let´s assume, that you don´t want to be extremely precise,
but still need overall float precise sleep.
Thread.Sleep(new Random().Next(20,21));
This should give you ~20.5 sleep timing. Use your imagination now.
TotalSleeps / tries = "should be wanted value", but for single sleep interval, this will not be true.
Dont use new Random() make an instance before.
How can i do Thread.Sleep(10.4166667);?
OK i see now that Sleep is not the way to go.
So i use Timer but timer is also in ms put i need more precise
Is there timer with nanosecond accuracy?
So you want your thread to sleep precisely for that time and then resume? Forget about it. This parameter tells the system to wake the Thread after at least this number of milliseconds. At least. And after resuming, the thread could be put to sleep once again in a blink of an eye. That just how Operating Systems work and you cannot control it.
Please note that Thread.Sleep sleeps as long as you tell it (not even precisely), no matter how long code before or after takes to execute.
Your question seems to imply that you want some code to be executed in certain intervals, since a precise time seems to matter. Thus you might prefer a Timer.
To do such a precise sleep you would need to use a real time operating system and you would likely need specialized hardware. Integrity RTOS claims to respond to interrupts in nanoseconds, as do others.
This isn't going to happen with C# or any kind of high level sleep call.
Please note that the argument is in milliseconds, so 10 is 10 milliseconds. Are you sure you want 10.41 etc milliseconds? If you want 10.41 seconds, then you can use 10416.
The input to Thread.Sleep is the number of milliseconds for which the thread is blocked. After that it will be runnable, but you have no influence over when it is actually scheduled. I.e. in theory the thread could wait forever before resuming execution.
It hardly ever makes sense to rely on specific number of milliseconds here. If you're trying to synchronize work between two threads there are better options than using Sleep.
As you already mentioned: You could combine DispatcherTimer with Stopwatch (Making sure the IsHighResolution and Frequency suits your needs). Start the Timer and the Stopwatch, and on discreet Ticks of the Timer check the exact elapsed time of the stopwatch.
If you are trying to rate-limit a calculation and insist on using only Thread.Sleep then be aware there is a an underlying kernel pulse rate (roughly 15ms), so your thread will only resume when a pulse occurs. The guarantee provided is to "wait at least the specified duration." For example, if you call Thread.Sleep(1) (to wait 1ms), and the last pulse was 13ms ago, then you will end up waiting 2ms until the next pulse comes.
The draw synchronization I implemented for a rendering engine does something similar to dithering to get the quantization to the 15ms intervals to be uniformly distributed around my desired time interval. It is mostly just a matter of subtracting half the pulse interval from the sleep duration, so only half the invocations wait the extra duration to the next 15ms pulse, and half occur early.
public class TimeSynchronizer {
//see https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-sleep
public const double THREAD_PULSE_MS = 15.6d;//TODO read exact value for your system
public readonly TimeSpan Min = TimeSpan.Zero;
public TimeSynchronizer(TimeSpan? min = null) {
if (min.HasValue && min.Value.Ticks > 0L) this.Min = min.Value;
}
private DateTime _targetTimeUtc = DateTime.UtcNow;//you may wish to defer this initialization so the first Synchronize() call assuredly doesn't wait
public void Synchronize() {
if (this.Min.Ticks > 0L) {
DateTime nowUtc = DateTime.UtcNow;
TimeSpan waitDuration = this._targetTimeUtc - nowUtc;
//store the exact desired return time for the next inerval
if (waitDuration.Ticks > 0L)
this._targetTimeUtc += this.Min;
else this._targetTimeUtc = nowUtc + this.Min;//missed it (this does not preserve absolute synchronization and can de-phase from metered interval times)
if (waitDuration.TotalMilliseconds > THREAD_PULSE_MS/2d)
Thread.Sleep(waitDuration.Subtract(TimeSpan.FromMilliseconds(THREAD_PULSE_MS/2d)));
}
}
}
I do not recommend this solution if your nominal sleep durations are significantly less than the pulse rate, because it will frequently not wait at all in that case.
The following screenshot shows rough percentile bands on how long it truly takes (from buckets of 20 samples each - dark green are the median values), with a (nominal) minimum duration between frames set at 30fps (33.333ms):
I am suspicious that the exact pulse duration is 1 second / 600, since in SQL server a single DateTime tick is exactly 1/300th of a second