Create a standalone library of tests : How To …

[tcalderwood]

Many of our controls have the same input requirements, for example lat/long values. Instead of writing a separate tests for each control, we want to pull the tests back into a library that we can call when ever we go to test that type of control, either passing in a control ID or control Name. In addition, these controls are spread across 15 different applications, so creating a stand alone library that we can include as need be would be very helpful. I am certain this is fairly easy, but as we are just starting out with Ranorex, our knowledge is very limited. A quick sample is all we need. Thanks

[Ciege]

You can create a DLL that has all of your combined code (in other words a framework).
Your framework can contain shared methods that can be called from various different tests or specific test methods that are identical between tests.
Once the DLL has been generated then all you need to do is make a reference to that DLL from the other tests and your shared methods will be available. Further it allows you to only need to make changes/fixes to one central location and all the other tests will be updated.

[Support Team]

Hello,

In Ranorex Studio 3.0 to make a DLL starting from an existing solution, right-click on the solution choose Add, then New Project, then choose Advanced, then Ranorex Class Library. You could also choose Module, then Ranorex Test Suite Module Library. A module in Ranorex is something you can drag into the test suite. By doing so the DLL would be automatically added to the list of references of your main test suite executable. Else you need to add the DLL using "Add Reference" in the context menu of the reference list of your (test suite) executable.

In your case a similar functional block of controls is spread over more applications. You could use RanoreXPaths like

Code: Select all

/.//text[@accessiblename="nameyouprovideCouldbeOtherAttributeToo"]

But then the whole desktop is searched which makes is slow.

You should therefore provide a root path to the function in the DLL, too, in order to make it faster. The root path is part of the repository entry. You could access it using the FolderClass.AbsoluteBasePath for folder entries or EntryNameInfo.AbsolutePath for repository entry EntryName.

Another way would be to provide the adapter instance for the container in the argument list of your function. In the function you use FindSingle of the adapter instance.
If you compile your DLL with .NET 3.5, then this could also be done using extension classes, in which you mark the first argument of your static function of a static class with this.

public static class BlockOne 
{
    	public static void FillWithData(this Ranorex.Adapter parent, string firstnamecontrol, string firstname, string lastnamecontrol, string lastname)
    	{
    		Ranorex.Text firstname_adapter = parent.FindSingle(".//text[@accessiblename='"+firstnamecontrol+"']");
    		firstname_adapter.TextValue = firstname;
    		Ranorex.Text lastname_adapter = parent.FindSingle(".//text[@accessiblename='"+lastnamecontrol+"']");
    		lastname_adapter.TextValue = lastname;
    		Ranorex.Button addbutton = parent.FindSingle(".//button[@controlname='btAdd']");
    		addbutton.Click();
    	}
}

Then you can use your function from the DLL as though it was a function of the container's adapter.

repo.FormVIP_Database.Self.FillWithData("First Name:", "John", "Last Name:", "Travolta");

Note: Repository folder entries are not adapter classes. For them the Self member must be used.

Regards,
Roland
Ranorex Support Team

[Tiano]

There are varieties of make systems that can be used. To name a few: GNU make (and other make clones) and build systems integrated into IDEs (for example Microsoft Visual Studio). The Boost preferred solution is Boost.Build system that is based on top of bjam tool. Make systems require some kind of configuration file that lists all files that constitute the library and all build options. For example the makefile that is used by make, or the Microsoft Visual Studio project cell phone spyware file, Jamfile is used by Boost.Build. For the sake of simplicity let's call this file the makefile.