How to code review a test change

[conradb]

After going a little off track in a thread where I was looking at version control of the generated .cs code files I figured it wise to separate out this question better. I'm automating a WCF application, and most of the test changes are not "user-code", but other kinds of application may share experience when it comes to test code review.

I'm so totally not going to entertain anyone asking why I review test code changes, but if you want we can loop into a fresh topic on that.

As was pointed out in an older thread, we should be reviewing the generated and user.cs files. How do you guys and girls judge/review a change?
Things like :
1. Is the new test code actually weaker than before and no longer useful? Is the test now more maintainable or less?
2. Which files do we code-review, do we talk through the recording file or the actual C# files because they are easier to diff?
3. Does this change need to be done someplace else too, does it lend itself to refactoring instead?
4. When a change is to some RanorexPath, is it easy for you to understand the possible impact?

And many more, but in terms of the practical effort, what tips do users have?

[krstcs]

In no particular order:

1. You don't need to look at the locked .cs files. They are just a backend for the .rxrec files and since they are machine generated, there's nothing there to look at.

2. *.UserCode.cs files should only be looked at if you are actually writing user code in them. Otherwise they are just machine generated partials as well.

3. Repo XPaths are the core of what Ranorex is, but they are so dependent on what you need them to point at that it is almost useless to say what should and shouldn't be reviewed.


I work alone on our Ranorex automation, so there isn't anyone to review my work. I've been doing .NET development for 10 years (Java 5 years before that) and Ranorex for the last 5, so I'm pretty familiar with what Ranorex does. But I am a very advanced user as well, so I have done some heavy modifications that most would not want to even think about. I have to trust that the parts of the code that I let Ranorex generate and handle are working correctly.


One thing I will say is, your recordings should not need to be talked through. If you have to talk through them, you're making them too big. Keep them as small as possible and as modular as possible. Just drag-and-drop them into the test cases in your test suites where they are needed. This means that you really would only need to review the suites instead of the modules. If I need to enter a password and then click an OK button, that is two different actions, so I make 2 modules. One is 'Enter_Password', it takes a variable called 'Password' and enters it in the field. The other is 'Click_OK', and all it does is click the OK button. Then I can drop them in the test suite/case/group where in the order needed, bind the variables and be done. (Make sure your data source fields are named exactly the same as the module variables so you can use Autobind!!)


Every time I change an XPath I check it to make sure it works correctly. Every time. The XPath is just a description of the object so Ranorex can find it easily. As long as it points to the correct object after you change it there shouldn't be a problem. There are always elements that need special attention, but they become easy to spot and work with with continued use of Ranorex.


Hope that helps some...

[conradb]

Brilliant suggestions, yes that does help. Thank you for the inputs.

What is autobind?
And hopefully related to that, is there a way to harvest automation IDs in a form?

[krstcs]

Autobind is a button in the Data Binding tab of the test case properties window. When you click it, Ranorex will automatically bind all the data columns or parameters that are in that test case (or in parent cases or the suite) with module variables of the same name. This makes it much easier to bind a large amount of variables, if you name the data columns or parameters exactly the same as your module variables. The trick here is to use very descriptive, and even long, names so that you don't have two columns or variables with the same name that mean something different.


As for harvesting specific attributes of off all elements, you could do a loop and use "*.Find<T>(RanoreXPath)". Just make the RanoreXPath get all elements of the type you want and then just get the attribute's value. You will have do this in UserCode though.