3

** POST UPDATED **

For our system and integration tests on a Microsoft Dynamics environment, we are using Visual Studio 2010 Coded UI. I am an unexperienced user of Visual Studio, but have experience with test automation.

Whenever the VS-Coded-UI-test is typing text in edit boxes, there is a change that one of the characters that has to be typed is omitted. An address field like Beverly Hills 90210 could easily become Beverly ills 90210, breaking my tests. It happens around 1 in the 200 characters (educated guess).

Has someone experienced this before? And where could the problem be located: Type rate of VS, Broken keyboard driver, Hiccup of the browser so it could not receive a text input properly, something else?

And is there a possibility to lower the typing rate of the test-driver in VS coded ui?

UPDATE, 2012-05-24: Still not found a solution. I use now a work around that reduce the change of failing, but it is still not ideal.

Work around code (yes, it is dirty):

// put this method in a base class or easy accessable component
protected void ExecuteWithRetry(Action method, int maxRetryCount = 2)
{
    try
    {
        method();
    }
    catch (Exception)
    {
        if (maxRetryCount > 0)
        {
            ExecuteWithRetry(method, maxRetryCount - 1);
        }
        else
        {
            throw;
        }
    }
}

Whenever I use a piece of code where an text field is set, I call this through this method:

UIMap.SetUserfieldsParams.EnterAddress = @"555 Sunset Boulevard";
UIMap.SetUserfieldsParams.EnterZIP = @"90210";
ExecuteWithRetry(UIMap.SetUserfields);

UPDATE, 2012-06-18: It seems to be caused by the impersonation we use. The logged on user to our web-application is directly extracted from the AD server by the user name that started IE. By starting IE through impersonation, we can do our tests with other users without (manually) log off and log on into Windows. We use impersonation by using Process.Start(ProcessStartInfo startInfo) in namespace System.Diagnostics.Process

AutomatedChaos
  • 7,267
  • 2
  • 27
  • 47

1 Answers1

3

My first guess is that it is happening because it is typing to fast and your application isn't ready to receive the next key. You can change the time between keys being entered by using KeyBoard.SendKeysDelay, the default on my machine at least is 10 ms.

Do you happen to have continue on error turned off? I am kind of surprised that you aren't getting an exception that stops the test at the point when the value is entered.

stoj
  • 679
  • 1
  • 10
  • 18
  • I just discovered the PlayBackSettings.DelayBetween option, assuming it was for between actions on the UI and not _inside_ actions (because the typing is faster then 10 chars/second), but it is certainly worth a try. Continue on error is turned off, so there is an exception when it verifies the just set value. Next week, when I am back on that project, I can let you know. – AutomatedChaos Mar 16 '12 at 09:05
  • 1
    You are right on the DelayBetween, it doesn't seem to effect keyboard input... The correct way to change keyboard input speed is KeyBoard.SendkeysDelay – stoj Mar 16 '12 at 11:37
  • OK, I changed the Keyboard.SendkeyDelay setting, but the problem still persists, even if I set the timeout to 50ms (really slow when lots of data has to be set). Still searching, I'll keep you informed. – AutomatedChaos Mar 21 '12 at 10:28
  • Is there a common thread to the failures? Does it do it on the same control or controls? As a work around you could always turn continue on error back on and catch/retry when it fails. – stoj Mar 21 '12 at 14:37
  • No, it happens on editboxes, comboboxes and editable textarea's. Strangely enough, I have managed to try it on other machines and it only happen on this one PC. I think I will let the IT Service team do a fresh OS install on this particular PC. It could be that some drivers or dll's are gone rogue. – AutomatedChaos Mar 21 '12 at 14:59