Organization and Best Practice

Class library usage, coding and language questions.
slither
Posts: 11
Joined: Thu Jun 18, 2009 3:27 pm

Organization and Best Practice

Post by slither » Fri Jun 26, 2009 5:17 pm

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? :wink:

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Organization and Best Practice

Post by Support Team » Thu Jul 02, 2009 12:44 pm

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
.
Image

BPyles
Posts: 5
Joined: Thu Feb 25, 2010 10:21 pm

Re: Organization and Best Practice

Post by BPyles » Thu Mar 25, 2010 7:51 pm

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
Posts: 17
Joined: Wed Mar 17, 2010 7:36 pm

Re: Organization and Best Practice

Post by sundarpn » Fri Mar 26, 2010 3:25 pm

Thats fantastic. I am looking forward to it too. Thx! :D
Support Team wrote: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
Posts: 357
Joined: Sun Dec 07, 2008 11:14 pm
Location: Dublin, Ireland

Re: Organization and Best Practice

Post by atom » Wed Apr 07, 2010 5:50 pm

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

anzacthecat
Posts: 31
Joined: Mon Jan 10, 2011 1:05 pm

Re: Organization and Best Practice

Post by anzacthecat » Tue Feb 01, 2011 2:29 pm

Any more news on this?

atom
Posts: 357
Joined: Sun Dec 07, 2008 11:14 pm
Location: Dublin, Ireland

Re: Organization and Best Practice

Post by atom » Wed Feb 02, 2011 10:13 am

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

User avatar
Support Team
Site Admin
Site Admin
Posts: 11709
Joined: Fri Jul 07, 2006 4:30 pm
Location: Graz, Austria

Re: Organization and Best Practice

Post by Support Team » Wed Feb 02, 2011 12:05 pm

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
.
Image

atom
Posts: 357
Joined: Sun Dec 07, 2008 11:14 pm
Location: Dublin, Ireland

Re: Organization and Best Practice

Post by atom » Wed Feb 02, 2011 1:25 pm

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