I'm working on an application that does many postbacks to the server. I've been having extreme difficulty handling loading, but I'd like to share my experience with everyone. I'm purposefully not saying what language my app is written in, because I believe the principles I'm about to discuss apply globally.
MY LESSON LEARNED:
As a little background, the application I'm working on is an application that we're currently integrating with. Because of this, my initial thought was to code as many scrips as possible and not worry about the quality. Instead of thinking about a smart way to handle load times, I relied heavily (HEAVILY) on Pauses (Thread.Sleep was my friend). If I had spent just a few hours at the inception thinking about how to handle load time, it would have saved me says of re-factoring pain when I found out I'd be working more on this product than I initially thought.
STRATEGIES FOR HANDLING LOAD TIME:
1. Whatever scripting tool you are using (selenium, Test Complete, Mercury, VS Coded UI Tests) should have some way of managing timeout times. That is to say, how long it will wait for an element before it gives up and throws an error. If you are evaluating a scripting tool, DO NOT give up on it before you have researched this. Currently, I'm using Selenium RC (c#), here is the method available for this job:
driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(10));
This will make the driver search for an element for 10 seconds if it's not immediately present. Note: If you are using some code to measure time, having this set will corrupt your results. You can easily toggle this setting on and off in your script, so it shouldn't be a big deal.
2. Another commonly used tactic is to wait for another thing to happen before proceeding. This can be particularly useful as you're navigating from page to page, especially if you don't want to set your ImplicitWait as long as 10 seconds. Here's a snippet of code that I wrote that will wait for an element to be present:
public static WaitForElement(string type, string value)
{
bool catchFlag = false;
while (catchFlag == false)
{
catchFlag = true;
try
{
Thread.Sleep(500);
driver.FindElement(By.Id(value));
}
catch
{
Thread.Sleep(500);
catchFlag = false;
}
}
}
Notice that I like to put a half second buffer to account for page rendering time and general server funkyness. I know, I know. It's a crutch and I shouldn't need it.
3. The dreaded forced delay. This should be your last alternative, but that doesn't mean it should never happen. I think it's all about weighing the cost benefit of using a delay to handle loading. if you know that there is absolutely no chance you'll ever have to wait more than 5 seconds between two actions, and you've spent 6 hours trying to figure out how to catch the ready state in your script and you are still at square 1, then by all means.. use a delay! Just don't use them everywhre because you are LAZY! Delay's create brittle scripts that are not reliable. Having said all that, I found them essential on one part of the application I'm working on, where a postback is done, but NOTHING on the page changes.
MY LESSON LEARNED:
As a little background, the application I'm working on is an application that we're currently integrating with. Because of this, my initial thought was to code as many scrips as possible and not worry about the quality. Instead of thinking about a smart way to handle load times, I relied heavily (HEAVILY) on Pauses (Thread.Sleep was my friend). If I had spent just a few hours at the inception thinking about how to handle load time, it would have saved me says of re-factoring pain when I found out I'd be working more on this product than I initially thought.
STRATEGIES FOR HANDLING LOAD TIME:
1. Whatever scripting tool you are using (selenium, Test Complete, Mercury, VS Coded UI Tests) should have some way of managing timeout times. That is to say, how long it will wait for an element before it gives up and throws an error. If you are evaluating a scripting tool, DO NOT give up on it before you have researched this. Currently, I'm using Selenium RC (c#), here is the method available for this job:
driver.Manage().Timeouts().ImplicitlyWait(TimeSpan.FromSeconds(10));
This will make the driver search for an element for 10 seconds if it's not immediately present. Note: If you are using some code to measure time, having this set will corrupt your results. You can easily toggle this setting on and off in your script, so it shouldn't be a big deal.
2. Another commonly used tactic is to wait for another thing to happen before proceeding. This can be particularly useful as you're navigating from page to page, especially if you don't want to set your ImplicitWait as long as 10 seconds. Here's a snippet of code that I wrote that will wait for an element to be present:
public static WaitForElement(string type, string value)
{
bool catchFlag = false;
while (catchFlag == false)
{
catchFlag = true;
try
{
Thread.Sleep(500);
driver.FindElement(By.Id(value));
}
catch
{
Thread.Sleep(500);
catchFlag = false;
}
}
}
Notice that I like to put a half second buffer to account for page rendering time and general server funkyness. I know, I know. It's a crutch and I shouldn't need it.
3. The dreaded forced delay. This should be your last alternative, but that doesn't mean it should never happen. I think it's all about weighing the cost benefit of using a delay to handle loading. if you know that there is absolutely no chance you'll ever have to wait more than 5 seconds between two actions, and you've spent 6 hours trying to figure out how to catch the ready state in your script and you are still at square 1, then by all means.. use a delay! Just don't use them everywhre because you are LAZY! Delay's create brittle scripts that are not reliable. Having said all that, I found them essential on one part of the application I'm working on, where a postback is done, but NOTHING on the page changes.
No comments:
Post a Comment