Hello,
While evaluating the latest available release of Test Studio (2012.2.1420.0) for possible upgrade from our current version (2012.1.411.0), I noticed that the behavior of Type command (typing text into an input field) has changed in the scenario where the Type command is replacing existing text in the field. Both versions clear out the field before typing into it (without needing explicit commands to do this) - however, the clearing mechanism seems to be different between the two versions. Our current version instantaneously blanks out the field while the new version goes to the end of the string and backspaces all the way up to the start.
Note, all the above is with SimulateRealUser set to true - which we want to keep for typing in the new value.
The new behavior will greatly increase running time of many of our tests - especially those that do heavy text input and/or if the previous strings are really long (think of a test which is testing error handling - one of which is max length of string which can be as high as 255 characters).
I know of a few solutions to this issue - but none of them are ideal for us:
a) Record a step to type in blank string (or select and clear the string) before typing in the next value. This is not ideal as it will require massive changes (we use Type a lot in our tests).
b) Go to coded step and clear the field before typing into it. This is not ideal for the same reason as above and also we will end up with a LOT of coded steps (something we are trying to limit).
c) Turn off SimulateRealUser. Not ideal as we want to simulate real user for typing in the new value. Reasons for the other two options also apply to this option.
I am assuming this is by design. If so, I was wondering if there was any other way to restore the old behavior without modifying a lot of tests. Please let me know if this is a bug that has been/is being addressed.
Thanks,
Shashi
While evaluating the latest available release of Test Studio (2012.2.1420.0) for possible upgrade from our current version (2012.1.411.0), I noticed that the behavior of Type command (typing text into an input field) has changed in the scenario where the Type command is replacing existing text in the field. Both versions clear out the field before typing into it (without needing explicit commands to do this) - however, the clearing mechanism seems to be different between the two versions. Our current version instantaneously blanks out the field while the new version goes to the end of the string and backspaces all the way up to the start.
Note, all the above is with SimulateRealUser set to true - which we want to keep for typing in the new value.
The new behavior will greatly increase running time of many of our tests - especially those that do heavy text input and/or if the previous strings are really long (think of a test which is testing error handling - one of which is max length of string which can be as high as 255 characters).
I know of a few solutions to this issue - but none of them are ideal for us:
a) Record a step to type in blank string (or select and clear the string) before typing in the next value. This is not ideal as it will require massive changes (we use Type a lot in our tests).
b) Go to coded step and clear the field before typing into it. This is not ideal for the same reason as above and also we will end up with a LOT of coded steps (something we are trying to limit).
c) Turn off SimulateRealUser. Not ideal as we want to simulate real user for typing in the new value. Reasons for the other two options also apply to this option.
I am assuming this is by design. If so, I was wondering if there was any other way to restore the old behavior without modifying a lot of tests. Please let me know if this is a bug that has been/is being addressed.
Thanks,
Shashi
7 Answers, 1 is accepted
0
Hello Shashi,
Cody
Telerik
No this is not a bug, it is a deliberate change to work with the most recent versions of the Telerik controls. We found in some cases the old Clear Text method we were using did not work as expected. It was changed to the behavior you are seeing today to work reliably in all cases. I am sorry but there is no setting in the current version of Test Studio to make it behave the old way.
There is one other option that may not be so painful, decrease the KeyHoldTime and the TimeBetweenKepresses - see attached screen shot. The default is 100 & 10. This means it's typing 10 characters per second and waiting 10 milliseconds between key presses. By reducing these to 10 and 10 you will get 100 characters per second typing speed, a 10 fold increase.
Cody
Telerik
Free summer webinars on advanced web automation tactics hosted by Jim Holmes & Adam Goucher.
Reserve your seat today!
Reserve your seat today!
0
Bob
Top achievements
Rank 1
Rank 1
answered on 02 Jul 2013, 02:51 PM
Depending on how your app works, you could clear the fields in a non-traditional way through a single coded step run as a subtest
===
-Tab
-CTRL-A
-Backspace
===
Use the LOOP step to have this run for as many fields as are on each individual page.
This would meet requirement 1 as it would only require a single step on each of your forms. Requirement 2 would be met as you would only be adding a single coded step to improve performance on every page. This would emulate real user behavior as it is simulating keystrokes, satisfying requirement 3.
Of course, tab clearing everything may not work, so you may have LOOP the subtest a number of times on a single page as your target input changes focus. This would still meet requirements 2 and 3, but depending on your app may not be as easy to implement as your first solution.
===
-Tab
-CTRL-A
-Backspace
===
Use the LOOP step to have this run for as many fields as are on each individual page.
This would meet requirement 1 as it would only require a single step on each of your forms. Requirement 2 would be met as you would only be adding a single coded step to improve performance on every page. This would emulate real user behavior as it is simulating keystrokes, satisfying requirement 3.
Of course, tab clearing everything may not work, so you may have LOOP the subtest a number of times on a single page as your target input changes focus. This would still meet requirements 2 and 3, but depending on your app may not be as easy to implement as your first solution.
0
Shashi
Top achievements
Rank 1
Rank 1
answered on 03 Jul 2013, 06:55 PM
@Cody:
It would be great to have an option to clear the field the old way. It would be even better if it can be set at a step level (for particular steps), and at a global level (for all tests - existing and new). Could you consider this a feature request?
I tried your workaround - it certainly speeds up the delete. Are these settings available at a global level? (I didnt see them in the Settings dialog). If not, I would like to request its availability as a global level option. Otherwise, it would be a prohibitive effort to update all Type statements in all tests (at least in our case). However, I will certainly consider using it where they are most needed.
I don't know if you currently support test-level settings (i.e. settings applied to all steps in a test - but not other tests in the project/solution) - if not, I think it would be a useful feature to have. If you do this, the above settings would be good to have at this level as well.
By the way, do new global settings or changes to existing global settings values (made by Telerik from release to release) get applied to all tests in a solution automatically? If so, when does this happen?
@Robert:
Thanks for your suggestion. But if I am understanding you correctly, I would still have to add calls to the shared test before every Type step in every one of our tests (or those Type steps where they are needed) - is that correct? If so, then that is the same in terms of effort as adding a Type step to clear the field before the Type step for the new value. If I have misunderstood you, could you clarify?
I look forward to your responses ...
Thanks,
Shashi
It would be great to have an option to clear the field the old way. It would be even better if it can be set at a step level (for particular steps), and at a global level (for all tests - existing and new). Could you consider this a feature request?
I tried your workaround - it certainly speeds up the delete. Are these settings available at a global level? (I didnt see them in the Settings dialog). If not, I would like to request its availability as a global level option. Otherwise, it would be a prohibitive effort to update all Type statements in all tests (at least in our case). However, I will certainly consider using it where they are most needed.
I don't know if you currently support test-level settings (i.e. settings applied to all steps in a test - but not other tests in the project/solution) - if not, I think it would be a useful feature to have. If you do this, the above settings would be good to have at this level as well.
By the way, do new global settings or changes to existing global settings values (made by Telerik from release to release) get applied to all tests in a solution automatically? If so, when does this happen?
@Robert:
Thanks for your suggestion. But if I am understanding you correctly, I would still have to add calls to the shared test before every Type step in every one of our tests (or those Type steps where they are needed) - is that correct? If so, then that is the same in terms of effort as adding a Type step to clear the field before the Type step for the new value. If I have misunderstood you, could you clarify?
I look forward to your responses ...
Thanks,
Shashi
0
Bob
Top achievements
Rank 1
Rank 1
answered on 03 Jul 2013, 07:07 PM
As I said at the end of my post, it may not be as easy if you need to implement a coded clearing step in front of every field. If, however, a page is not very complex, you could loop the keyboard command sequence at the start of every new page and would only need to do it once. Imagine the following page:
First Name: [ -input- ]
Last Name: [ -input- ]
Address: [ -input- ]
State: [ -dropdown- ]
Zip: [ -input- ]
If I land on this page, my cursor is in the "First Name" box. If I press TAB - CTRL A - BACKSPACE, it deletes the text in the last name field. I use LOOP to repeat this statement in Address (clears it) State (does nothing, it's a dropdown) and Zip (clears it) then tab back to First Name (clears it).
This means instead of option 1 - making a ENTER TEXT step that is blank but not simulating typing - you would only need one coded step with the appropriate number of loops at the start of every page.
But let's assume that doing this in the STATE field caused an issue because the dropdown box didn't like hitting backspace and crashed the site. You could loop twice, do the text modifications and dropdown modification (Last Name, Address, State), then loop twice again (Zip and First Name). Since you're adding two identical coded steps instead of 4 unique text input steps, it's at least half the effort of your first solution.
Ex Test Workflow:
LOOP (2)
-Tab, CTRL A, Backspace
END
Enter Text in - Last Name, Address
Select Dropdown - State
LOOP (2)
-Tab, CTRL A, Backspace
END
Enter Text in - Zip, First Name
First Name: [ -input- ]
Last Name: [ -input- ]
Address: [ -input- ]
State: [ -dropdown- ]
Zip: [ -input- ]
If I land on this page, my cursor is in the "First Name" box. If I press TAB - CTRL A - BACKSPACE, it deletes the text in the last name field. I use LOOP to repeat this statement in Address (clears it) State (does nothing, it's a dropdown) and Zip (clears it) then tab back to First Name (clears it).
This means instead of option 1 - making a ENTER TEXT step that is blank but not simulating typing - you would only need one coded step with the appropriate number of loops at the start of every page.
But let's assume that doing this in the STATE field caused an issue because the dropdown box didn't like hitting backspace and crashed the site. You could loop twice, do the text modifications and dropdown modification (Last Name, Address, State), then loop twice again (Zip and First Name). Since you're adding two identical coded steps instead of 4 unique text input steps, it's at least half the effort of your first solution.
Ex Test Workflow:
LOOP (2)
-Tab, CTRL A, Backspace
END
Enter Text in - Last Name, Address
Select Dropdown - State
LOOP (2)
-Tab, CTRL A, Backspace
END
Enter Text in - Zip, First Name
0
Hello,
Cody
Telerik
I'm going to answer your questions a little out of sequence, the easier ones first. :-)
I don't know if you currently support test-level settings...
Yes we do. See the attached screen shot for an example.
By the way, do new global settings or changes to existing global settings values (made by Telerik from release to release) get applied to all tests in a solution automatically? If so, when does this happen?
I need to answer this from two perspectives:
- Changes to the Project Level Settings and/or Test List Settings - These settings affect the next time you launch the recorder or when you run a test via Quick Execute or execute a Test List. They're not attached to individual tests or steps. The are stored in the settings.aiis file and the specific .aiilist test list file. They are not kept in the individual .tstest files so these are not touched when you change these settings.
- Changes made during a version upgrade - The next time you open a test project after upgrading to a new version of Test Studio, the IDE will check to see if the project version is current. If it isn't first it makes a backup copy of the entire test project in the Backup folder. Then it iterates through all tests contained in the entire project and makes changes as required to be compatible with that version of Test Studio. All .tstest files could be affected by this process. It is only done once, but is done globally. The settings.aiis file and the .aiilist files will also be updated as needed.
Does that answer this particular question?
I tried your workaround - it certainly speeds up the delete. Are these settings available at a global level?
No I am sorry. The typing speed is only set at the per step level. I do see value in providing a global setting for this.
Otherwise, it would be a prohibitive effort to update all Type statements in all tests...
Yes I do sympathize. One option that I would consider is using something like Visual Studio to do a global find and replace inside the .tstest files. You have to be a little careful because you'll be using VS to modify the xml contained in our .tstest files, but this is doable.
I tried your workaround - it certainly speeds up the delete. Are these settings available at a global level?
No I am sorry. The typing speed is only set at the per step level. I do see value in providing a global setting for this.
Otherwise, it would be a prohibitive effort to update all Type statements in all tests...
Yes I do sympathize. One option that I would consider is using something like Visual Studio to do a global find and replace inside the .tstest files. You have to be a little careful because you'll be using VS to modify the xml contained in our .tstest files, but this is doable.
Regards,
Cody
Telerik
Free summer webinars on advanced web automation tactics hosted by Jim Holmes & Adam Goucher.
Reserve your seat today!
Reserve your seat today!
0
Ranjan
Top achievements
Rank 1
Rank 1
answered on 28 Nov 2013, 10:57 AM
Hi
I am unable to read Rad textBox value which is already avail due to cookie.
In case on Asp .net text works f9 kindly give solution for this.
Thanks & Regards,
BK Ranjan
I am unable to read Rad textBox value which is already avail due to cookie.
In case on Asp .net text works f9 kindly give solution for this.
Thanks & Regards,
BK Ranjan
0
Hello Ranjan,
Thank you for contacting us.
I am not sure that I understand you correctly. Please elaborate a bit more on your scenario.
How do you want to read the value, via code or via the stand alone version of Test Studio.
Please give us more detailed information and I will do my best to assist you.
Hope to hear from you soon.
Regards,
Boyan Boev
Telerik
Thank you for contacting us.
I am not sure that I understand you correctly. Please elaborate a bit more on your scenario.
How do you want to read the value, via code or via the stand alone version of Test Studio.
Please give us more detailed information and I will do my best to assist you.
Hope to hear from you soon.
Regards,
Boyan Boev
Telerik