Disabling SimulateRealUser breaks data driven

[Ohsha]

Hi, 

Having recorded and converted it to data driven of my script, I want to disable the Simulate Real User feature, so the text show up at once. So I set SimulateRealUser to false, but only to find that my data driven script is broken. 

This is the latest test studio. Please verify. 

Thanks

[Boyan Boev]

Hello Ohsha,

Thank you for trying Test Studio. I am afraid the version of the Test Studio you are using doesn't support date driven test with SimulateRealUser sets to false.

The good news is that in the latest internal build in the date driven property is available "recorded text" option as you can see in the attached screenshot, which can be used in order to get the desired functionality. I recommend to upgrade Test Studio to the our latest internal build. You can do that by logging in to your Telerik.com account and go to the Latest Internal Builds section.

Please let us know if we can assist you further.

All the best,
Boyan Boev
the Telerik team

[Shashi]

Hello,

I don't know the version used by the OP or the version of the internal build recommended by Telerik - but I just ran into this issue in the latest official version (2012.2.1420.0).  It showed up after I turned off SimulateRealUser on some Type statements in one of my tests .  I got around the issue by databinding the RecordedText field to the same variable as TypedText.

However, I saw a few minor issues while - and after - making this change:

a) I see databindings for both RecordedTextValue and TypedTextValue in the recorded step (see screen shot).  This could be misleading to someone reading the code (it may give the impression that the value being typed in is the same value occurring twice).  This is a visual issue only - only one value is actually used during the test execution.

b) In the version that we currently have (2012.1.411.0), if we bind TypedText to a variable,  the RecordedText value is automatically bound to the same variable.  However, that no longer seems to be the case in the new version - RecordedText remains blank even if I bind the TypedText value; so I have to explicitly bind it to the same variable.

c) The available bind data variables are now shown in a combo box inside the Collections dropdown.  It looks like this functionality has performance issues when the number of variables is large (as is the case with us) - it takes several seconds before the Collections dropdown is displayed.

d) This may be related to item c) - but sometimes, the Collections dropdown shows up blank and then disappears.  I have managed to resolve this thus far once by reopening the test solution and another type by reopening the test file.

Note that the reason we had to turn off the SimulateRealUser option in the first place was to get around another Test Studio issue - which has already been found by other users (PITS 14070).  Ideal solution (for us) would be for that issue to be fixed - however, I thought I would report the above issues as well in case we (or others) have to turn the option off for other reasons.

Thanks,
Shashi

[Mario]

Hello Shashi,

In case you were still curious, the original poster from this thread was using 2012.2.920 and Boyan had asked him to upgrade to our LIB at the time which was 2012.2.1022. 

As for the 'Recorded Text Content' property, it is expected behavior that it be used as the step's input text in place of the 'Typed Text' property when SimulateRealUser is false (note from step properties that they alternate enabled/disabled when changing SimulateRealUser). I'm happy to see that you've essentially figured this out already and have applied the same binding to both properties, though I should clarify that only one is really necessary depending on whether you plan to use the step with SimulateRealUser set to true or false.

a) You are correct in that only one value will be used but technically only one needs to be bound as well, the appropriate choice being based on the step's SimulateRealUser setting. The fact that two bindings appear in the step description is really due to our naming convention which is expected since you've bound two properties of this step (even though one will not be used).

b) I am sorry to say that I did not find this this difference between your two versions. Please see image DataDrivenType_411 where I needed to bind each separately, the same as with our current version, and both were added to the step's description, related to (a) above.

c) and d) I am sorry to hear that you've come across these issues with the newer data binding UI, we are not aware of such behavior. Please help us to recreate the scenario and investigate further, any additional information with regards to the amount of entries in your drop-down collection as well as frequency of (d) may be sufficient in allowing me to reproduce the behavior in my local environment.

As for your original reason for having to set SimulateRealUser to false, I have pinged our developer assigned to this task for any possible update/time frame he may have. Unfortunately due to our timezone difference, this will very likely take until tomorrow to pass along to you.

Regards,
Mario
Telerik

[Shashi]

Hi Marlo,

Thanks for your response.

For b), I think you may have misunderstood what I was referring to. 

Here are the steps in 2012.2.411.0:
a) Record a step that can be data-bound (or use an existing one).  Set SimulateRealUser to true.
b) Open up the (Collection) dropdown for "Bindings".
c) Specify a variable for TypedText - as you have done in your screen shot.
d) Click Set
e) Now open that dropdown again and select RecordedTextContent - you will see that it automatically has the variable that you specified for TypedText.

Now repeat the above steps in 2012.2.1420.0 - instead of typing in a value, select a value from the dropdown.  After you release the dropdown, you should see that RecordedTextContent dropdown is still blank.  If the behavior of the earlier version were retained, the RecordedTextContent would automatically select the variable that you selected in TypedText.

NOTE:  This issue is not a big deal - it is just a minor inconvenience for someone used to (read, spoiled :) ) by the earlier UI.

Regarding c) and d), I do not have an exact count - but a best guess would be more than 600 variables.  Data source (as I mentioned) for most of the tests is an XML file.  The performance issue with the dropdown (taking a long time to bring up the list) happens very frequently - the blank list has happened a few times (gets resolved when I close and reopen the test - or close and reopen the solution in Visual Studio).

I look forward to your input on the above as well as the info on PITS 14070 - we would really prefer to run with SimulateRealUser set to true.

Thanks,
Shashi

[Mario]

Hi Shashi,

I'm sorry but these steps have still lead me to the same conclusion as before, please refer to this video. I believe what is happening is that our old UI has made it seem as though both properties were bound after setting only the first. Note after completing up to step (d) how '$(Col1)' will remain in the input field no matter which of the two properties you highlight (it would have read 'type expression here' if the first binding had not existed), however you can also see that the second property is not bound until you explicitly highlight it and click 'Set' for the second time. Only after doing so is the 'RecordedTextContent' property bound, represented by the tiny gear icon which overlays the yellow cylinder in second property as it did with the first. Noting that this was a minor inconvenience anyway, I will leave it up to you to confirm or correct my findings if you should wish to do so.  

Moving on to the more important issue of sluggish behavior with the newer data binding UI. Unfortunately I was not able to reproduce the behavior in my local environment using a very simple test bound to an XML file containing 700+ variables, see video. We may have a better chance in doing so if we were to obtain a copy of your entire project. If this would be reasonable, we can take our discussion to a private ticket.  Before doing so, I do suggest that you test this behavior on a faster machine to see whether it is seen there as well.

Lastly, with regards to PITS 14070, the subject has been moved over to this entry of our newer public Feedback Portal. Our dev team has very recently responded via the comments section in the previous link, please review and let me know whether you have any additional questions.

Regards,
Mario
Telerik

[Shashi]

Hi Mario,

Thanks for your feedback on earlier issues - I will look into them further and get back to you if necessary.  I did see that the performance is much better after the server reboots.  I do see other issues with the tests (steps inexplicably hanging, etc) and a general sluggishness of the computer in conjunction with the issue reported below.  All the above issues generally go away after a server reboot as well.  So this may be a more general issue rather than one specific to the databinding dropdown. I will start a new thread to report this when I have a little more information. 

I encountered a new issue with the workaround to set SimulateRealUser to false.  One of our tests verifies the app's validation of the max limit of a text box which exhibits the original issue.  The app imposes the limit by not accepting text input in the text box when the max limit is reached - nothing is seen on screen and characters are not saved if user types beyond the limit.  The test verifies this validation functionality by typing in a string with length more than the max limit and verifies that the string in the text box was truncated to the limit. 

This validation step works in our current version with SimulateRealUser = true.  However, in the new version with SimulateRealUser = false, the verification step fails because the text box value is set to the original input string (which exceeds max length) rather than the truncated version.  I did try turning on FireKeyEvents - but that doesn't help (it may be because the app does not use Key events to validate the typed in string).

Any ideas on what I can do to get the validation step to pass?

I should mention here that the app is a Silverlight application and we are using Telerik's Silverlight controls.

Shashi

[Mario]

Hi Shashi,

In order to assist you in finding a suitable workaround, please help me to recreate an identical scenario in my local environment for troubleshoot this problem. If providing us with direct access to application will not be possible (eg. app is local and/or private), you can instead capture a Fiddler trace that will allow us to work with a "simulation" of the application. If you are unfamiliar with how to do so, this link will provide you with step-by-step instructions for download and use. Alongside the instructions from the previous link, please make sure to enable the 'Store binaries' and 'Decrypt HTTPS traffic' options prior to starting the capture (see image). Thank you for helping us advise you.

Regards,
Mario
Telerik

[Shashi]

Mario,

I have submitted support ticket 716647 for the issue with some details about the control and the problem test steps.  Please review and let me know if you have more questions.  I have not had time to look into the Fiddler logs, etc. - also, depending on what is in those logs, company confidentiality may prevent me from sharing that info with you.  I am hoping that what I have provided will be sufficient for you to reproduce that issue - if not, let me know what else will help and I will see what I can do.

I look forward to hearing further from you or someone else at Telerik on this issue.

Thanks,
Shashi

[Mario]

Hi Shashi,

Thank you for creating the new ticket so we can share such resources privately. Let's continue our conversation there.

Regards,
Mario
Telerik