tag:blogger.com,1999:blog-2468094238199231967.post908431047298887097..comments2022-04-05T05:32:28.515+03:00Comments on Here be Robots!: Too much sleep is better than not enoughPekka Klärckhttp://www.blogger.com/profile/00901693165404242900noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-2468094238199231967.post-15944319085854907792016-11-18T13:34:31.454+02:002016-11-18T13:34:31.454+02:00Hi Catherine,
I think it is a good idea. I even t...Hi Catherine,<br /><br />I think it is a good idea. I even thought that I had implemented that but it has been 3 years since I've left the Robot Framework project so I really can't remember.<br /><br />I think it would be fairly easy to make an implementation that would always increase the wait time by let say 10 %. This would generate logarithmic number of checks and in the same time the possible increase in waited time would be minimal.Mikko Korpelahttps://www.blogger.com/profile/15817076154969501663noreply@blogger.comtag:blogger.com,1999:blog-2468094238199231967.post-84262350363119715072016-11-18T12:31:53.439+02:002016-11-18T12:31:53.439+02:00i think that "BuiltIn.Wait Until Keyword Succ...i think that "BuiltIn.Wait Until Keyword Succeeds" could be adapted to manage case when we have to wait a very long time (more than 1 hour in endurancy tests): the same way gmail increases its retry connection delay when you are disconnected from the network, "BuiltIn.Wait Until Keyword Succeeds" could wait a longer time at each iteration (let's say: (delay + original delay) each time), this is a compromise to prevent too much logs and to wait not too long in the latest iteration. what is your opinion?catherine beloinnoreply@blogger.comtag:blogger.com,1999:blog-2468094238199231967.post-1489709165876991472011-03-15T15:11:12.001+02:002011-03-15T15:11:12.001+02:00I think that the best solution is to use the Holly...I think that the best solution is to use the Hollywood principle (the test is notified in the appropriate time) but this isn't always possible in test cases..<br /><br /> Polling is also very good in many cases and can be easier to implement than notification system.<br /><br /> Sometimes I've seen cases where polling isn't the perfect solution.<br /><br /> For example when it takes a very long time to do the operation that we are waiting (lets say at least 30 minutes -- hard limit) and one round of polling will take a very little time (lets say 0.01 seconds). In this kind of situation polling will produce huge logs (30*60/0.01 == 180 000 rounds).<br /><br /> I would most likely first sleep 29.9 minutes and then start polling. I would also abstract this waiting functionality from the test case to a separate function.<br /><br /> Does anyone have other ideas to handle this kind of long waits in tests that can't use notification systems?<br /><br /> Or other timing related war storiesMikko Korpelahttps://www.blogger.com/profile/15817076154969501663noreply@blogger.comtag:blogger.com,1999:blog-2468094238199231967.post-52695936035425876382011-03-09T18:12:32.582+02:002011-03-09T18:12:32.582+02:00I prefer polling over any other technique. I also ...I prefer polling over any other technique. I also feel that hard coded wait periods are the worse which could be adopted in test automation.tarun khttps://www.blogger.com/profile/11392748105802885663noreply@blogger.com