Pros and cons with using Ranorex Studio vs Visual Studio

[Stian]

Hey guys!

We are about to go for Ranorex as our complementary solution to GUI automation using the Microsoft Platform.
This is primarily for getting cross-browser support - and likely device support later on.

Currently we have developed some proof-of-concept testing using mainly Ranorex Studio, but keeping a visual studio solution updated and hooking it all up to TFS and MTM. It is important for us to be able to run the test cases through MTM.

While this works pretty well I find it fairly clunky to work with two studios and would like your opinion on what the pros and cons are with using VS and the Ranorex API instead vs using Ranorex Studio.

So far I have come up with the following:

Pros with using only Visual Studio with Ranorex API and Spy:

- Intellisense
- ReSharper
- Only one studio that all developers and testers are familiar with
- Still get to use Ranorex Spy, RanorexPath and the nice Ranorex repository

Cons:
- Missing out on some handy functionality in Ranorex Studio, perhaps?

It would be great if you guys would share your experience and opinions on either way of doing this. I am leaning towards using only Visual Studio, but I am worried that I might be setting myself up for some trouble down the line (will the API continue to be supported by Ranorex? Will I miss out on some very nifty features in Ranorex Studio? Is ranorex Studio required for device automation? etc.)

Thanks for any response!

Stian

[Ciege]

We work only in VS using the Ranorex API (all coded no record/playback). We also forgo the repository. All of our team is well versed in VS and were able to use Ranorex quite easily within it.

Since we don't do any record playback there wasn't a strong reason for us to switch IDEs.

[Stian]

Thank you Ciege. Do you use MS uimap instead of the Ranorex repository?
...and if you do, is it as flexible and easy to keep tidy and structured?

[Ciege]

Actually we use no repository at all... All of our elements are found at runtime using a home built custom framework. Nothing is hard coded other than the element ID that we need to search for and interact with (again all at runtime).

[Stian]

That's interesting! We'll stick with a repository, though, and I think the Ranorex repo is a good choice for that.

Thanks again

[IanF]

We have a Ranorex TFS MTM solution here. I use the Ranorex to develop my tests.

The MTM soulutions has it flaws.

http://social.msdn.microsoft.com/Forums ... fcbb6086dd

[artur_gadomski]

There already was a post very similar to this. But in my opinion when writing tests in code you are better off with VS. If you use recordings you should choose Ranorex Studio.

[Stian]

There already was a post very similar to this. But in my opinion when writing tests in code you are better off with VS. If you use recordings you should choose Ranorex Studio.

Thank you Artur.

Yes, I am leaning towards going the only-VS way here. Just wanted to confirm with you guys that it is a viable way to do it.

[IanF]

Except for the cases where people don't use the repository I don't see why you would want to make your job harder by doing it all in code in Visual Studio.

You do realise you can use the Recorder without recording...

You can drag and drop objects in the IDE you can paramatise and you can call coded sections. You can make small reusable tests. To me using Visual Studio seems like an extra step you don't really need to make.

[Ciege]

First off I don't necessarily agree that you are making your job harder by using VS as your IDE.

Actually, I believe you make yourself more of an asset to your company (in many cases) by learning VS. Two of the strong benefits here are:

1) If your company already uses VS as its IDE, then you become an asset to your company and Dev team by learning the same methodology of development that is used by your Dev team. You learn the ins and outs of VS. Further, if your Dev team already has coding standards and practices in place, you can apply those to your automation code continuing to further you experience and make you a more valuable employee.

2) Again if your company already uses VS as an IDE, you can leverage the knowledge of your Dev team to help you. Devs are a crazy bunch in general, but many times they don't want to have to learn a whole new way of doing something if they don't have to. If you use VS, then your Dev team can use Ranorex to implement their own automation tests for their code. Granted it won't be as good as a professional automation engineer, but it will certainly give you a great head start to flesh out their automated test cases into a larger library of tests to use in QA.

Those are just a couple of benefits... While I agree the Ranorex IDE (SharpDevelop) is a great IDE as well and better than most proprietary IDEs currently used by many automation solutions, I still think learning the de facto standard IDE used in the .NET world is of more benefit to your skill set and will help propel you into a life of crime... uh, I mean development... if that is indeed the direction you want to take your career.

Just my humble opinion...

[Stian]

Excellent points, Ciege.
When one gets comfortable with coding the tests in VS and get familiar with using the Ranorex API, implementing tests can be quite quick and effectively done.
I don´t necessarily agree that coding the tests manually is slower or less efficient than using the recorder.

All our developers use Visual Studio and everyone is required to follow a set of coding practices and rules set in ReSharper. Using VS enables us to conform to these rules also for our gui automation.

[IanF]

I use both VS and Ranorex IDE's...

I don't understand the drive to only code automation. The recorder (not recording) module to me is quick and simple to use for building small reusable tests. If required you can call in coded sections. Also using a tool like Ranorex like this gets around the prime developer being hit by a bus and no one else having any idea whats been done.

I gave up on code heavy automation years ago. Our jobs are to provide robust maintainable automation, not to sit back and write 1000's of lines of code.