Organization and Best Practice

[slither]

We recently bought Ranorex Pro with the intention of developing our test scripts in VS2008.
Our application is a large Enterprise application. We have a lot of forms (over 100) in it.

We will be creating a Repository for it using RanorexSpy. Once your repository is created, how do you use it?

Would you use the repository items straight into the testcases, or do you abstract it somewhat?

Also, are there other "best practices" that Ranorex users observe in order to create, manage and maintain the testcases and supporting code for larger applications?

I'd be interested to see a full project for a larger application (not just a sample, but a project built for solid test cases), so see how it could be structured and organized.

Maybe the Ranorex team could publish a real life test project, like the one they use to test RanorexStudio?

[Support Team]

Hi,

I see what you mean. And I'm really sorry for not providing you with a best practice example in our documentation. The good news for now: We're currently in the progress of creating an example project describing how to organize recordings, repositories and automation code in the context of testing complex software solutions.

We'll keep you up to date regarding this.

kind regards,

Christoph,
Ranorex Support Team

[BPyles]

Hi,

I am evaluating Ranorex as a possible tool for automated testing. I too would be interested in seeing documentation or an example project showing how to organize a project for testing a large .NET application.

Is there an example project or documentation for this ?

Thanks

[sundarpn]

Thats fantastic. I am looking forward to it too. Thx!

Hi,

I see what you mean. And I'm really sorry for not providing you with a best practice example in our documentation. The good news for now: We're currently in the progress of creating an example project describing how to organize recordings, repositories and automation code in the context of testing complex software solutions.

We'll keep you up to date regarding this.

kind regards,

Christoph,
Ranorex Support Team

[atom]

I would say start using MSTest to organise the development of your test cases
MSTest is the testing features inside VS2008

[anzacthecat]

Any more news on this?

[atom]

Hiya

There's many ways to organise test case code
Probably the choice depends on:
- How much time you have
- How your input data, output data, results, log files are going to be stored
- How skilled the auto dev team are
- If you want ROI now, or build a framework for the future

What we do is create a class for each window in the AUT
The properties of the class are the GUI elements of the window
The methods of the class are the user/business operations that can be done in the window
This then makes developing tests easy, as tests then are often just a sequence of user/business method calls, and so tests have no direct GUI interaction code inside them. This means if the GUI of a window changes, you only have to maintain the class for the window, and not change all tests using that window

Cheers

[Support Team]

Hi,

There is blog article online which gives some recommendations of how to organize a test project with Ranorex V2.x. http://www.ranorex.com/blog/organizing- ... rex-studio

The article also includes a sample project to download.

In addition I want you to know that we are currently finishing Ranorex V3.0 which might cover most of your requirements. Please get in contact with [email protected] if you need any further information about the new features of V3.0.

Regards,

Christoph,
Ranorex Support Team

[atom]

Hiya

This best practice is good!
However still requires Test Case EXE to be dependant on GUI object map
We removed this dependancy in our organisation

So say in our AUT we have 3 windows
In our "Common" library we add three classes:

clsWindow1
clsWindow2
clsWindow3

The (private) properties of the class reference the object map
The (public) methods of the class are the user operations that can be done in that window - and are the methods that will be called by test case .exe's

e.g.
Say Window1 has 3 text boxes
We will add 3 private properties to the class that are the GUI elements (note: they are private as we don't want test case exe to be dependant on them)
We then add the user methods e.g. EnterName(string Name)
This method then uses the private properties and Ranorex API to do necessary GUI operations
From test case then, we call EnterName("Clayton")

This approach makes developing tests really easy (after window classes are written)
As often are tests are then just method calls to each window class
It also means your test case .exe's have no reference to the object map, or even use Ranorex API (except for logging)
It also means if say Window1 changes, then you only have to maintain clsWindow1 and expose the same interface to test case .exe's

Cheers
Clayton