Problem when renaming code steps

[Mark]

I have a script that contains about 176 steps.  Within those 176 steps I have about 20 coded steps, the coded steps are sprinkled throughout the test.  I needed to change the names of the coded steps, rather than open up each coded step one at a time, I clicked on the "class" button so that I could scroll through all of the code for the test and change the step names all at one time.  I changed the names of the coded steps, closed the class, saved the class and then noticed that Test Studio had moved everyone of the coded steps to the bottom of the test. Obviously having the test rearranged was not what I was looking for.   Has this happened to anyone else?

[Daniel Djambov]

Hi Mark,

I'm sorry for the problem you have, but unfortunately what you experience is a desired behavior.

Here is how it works - when changing a name of a coded step class we don't know if this is a new coded step or edit of existing one, so we place the coded step in the steps sequence bellow the marker in Test Explorer for where the next recorded step to be. In your case the marker has been at the bottom of the test and when editing all coded steps, they were all put at the bottom.

In this case, what you want to do - edit all coded steps at the same time will not preserve the test steps sequence. You will have to do the renaming of the coded steps one by one, making sure the cursor for record next step is above the currently edited coded step in order not to have your test rearranged.

I'm sorry for the inconvenience and not being able to offer you another solution, but hope this guide will help you in not ruining your tests in such scenarios.

Regards,
Daniel Djambov
the Telerik team

[Shashi]

Mark,

Another option is to change the names in the test file first and then change it in the coded step file - yes, I know this is still tedious but might be a few less mouseclicks.

Daniel: 
Telerik could make this easier by automating the second step i.e. if user changes the name in the test file, automatically change it in the corresponding coded step in the code-behind file.  Another suggestion is to support what Mark wants to do as a global option.

 

In connection with this, a couple of other features which would be very useful is to allow multiple coded steps to be associated with the same function and to allow users to change the function associated with a coded step (these are independent requests although I imagine the implementation of the second feature would be influenced by whether or not you implement the first).

Shashi