Page 1 of 1

Test data location as a parameter?

Posted: Sun Nov 20, 2011 7:55 am
by carsonw
Hello - we are primarily using another tool for automation and are investigating using Ranorex instead.

One of the requirements is that we can launch tests using CCNET on many different environments (around 10 or so right now). For a variety of reasons the environment configurations are not consistent - primarily in that the source code does not sit in the same drive or directory on each machine and it is certainly not in the same drive/directory as our development machines.

So, when we launch a Ranorex test we pass in the suite we want to run (which is great), but it always fails because the test data sheet cannot be found.

There must be some way to pass that information through to the executable, but I can't puzzle it out. I can see that the location is defined in the test suite file, but that doesn't really help me because I don't want to write a script to change that location in every test suite - there must be a way to pass that value in (if you can pass the test suite file location in, logically you must be able to past the test data file location as well otherwise your suite is unusable).

Thanks in advance!

Re: Test data location as a parameter?

Posted: Mon Nov 21, 2011 12:44 pm
by Support Team
Hello!

Thank you for investigating Ranorex!

Directly it is not possible at the time, but it is planned for the future versions.

Meanwhile, there are some possible workarounds.

Include file to your testsuite:
In the dialog for managing Datasources (screenshot), check the checkbox Include File in Test Suite. This will copy your file into the folder of your testsuite executable - and the executable will take the file from the folder of the exe. Info: To view all files within Project browser, use the Show All Files button in the project browser (screenshot).

Own argument parameter
The more flexible workaround would be reading out your own argument parameters.
With this workaround it's possible to call the testsuite with e.g.
TestParameter.exe /datacsvconnector:DynamicCsvConnector=c:\MyDynamicCsv.csv

Basically, there are two steps: First you have to read out the parameters of the arguments in the main method. Therefore,
open Program.cs file and edit the class Program to

Code: Select all

class Program
    {
        
        
        public static string dataCsvConnectorName
        {
        	get;set;
        }
        
        public static string dataCsvConnectorPath
        {
        	get;set;
        }
        
        [STAThread]
        public static int Main(string[] args)
        {
            Keyboard.AbortKey = System.Windows.Forms.Keys.Pause;
            int error = 0;
            
            foreach (string arg in args)
            {
            	
            	if (arg.StartsWith("/datacsvconnector"))
                {
                   dataCsvConnectorName = arg.Substring(arg.IndexOf(':')+1, arg.IndexOf('=') - arg.IndexOf(':')-1);
                   dataCsvConnectorPath = arg.Substring(arg.IndexOf("=")+1);
               }
	        }
            try
            {
                error = TestSuiteRunner.Run(typeof(Program), Environment.CommandLine);
            }
            catch (Exception e)
            {
                Report.Error("Unexpected exception occurred: " + e.ToString());
                error = -1;
            }
            return error;
        }
    }
Next, create a Code Module e.g. ReloadDataConnector.cs, alter the run method to:

Code: Select all

 void ITestModule.Run()
        {
            Mouse.DefaultMoveTime = 300;
            Keyboard.DefaultKeyPressTime = 100;
            Delay.SpeedFactor = 1.0;
            
            Report.Log(ReportLevel.Info,"Datasource '" + Program.dataCsvConnectorName + "' changed to '" + Program.dataCsvConnectorPath  + "'");
            (DataSources.Get(Program.dataCsvConnectorName).Connector as Ranorex.Core.Data.CsvDataConnector).FileName = Program.dataCsvConnectorPath;
            
            TestSuite.Current.GetTestCase("AddPerson").DataContext.ReloadData();
        }
Last step, create a testcase in your testsuite, add the ReloadDataConnector Codemodule to this testcase and after that add YOUR specific testcase with the dynamic data connector (structure in screenshot 3)

As I wrote above, these are two workarounds, in future version the the parameterization of the dataconnectors should work out of the box

Best Regards,
Martin
Ranorex Support Team

Re: Test data location as a parameter?

Posted: Mon Nov 21, 2011 6:43 pm
by carsonw
Ok thanks - I'll give that a try. Glad to hear that this is going to be included in future revisions - this would have been a show stopper for us because if we go ahead with Ranorex we will have at least 10 automation test run machines and probably about 7 developer machines all with various configurations.

As a note, I did try clicking the "include file" button, but all it did was copy the file into the executable directory - it still tried looking for the test file in the original target location (so I didn't see the point of this option).

The other workaround is a bit more involved than I would have hoped, but we'll see if we can sort it out. Thanks kindly!

Carson.

Re: Test data location as a parameter?

Posted: Mon Nov 21, 2011 6:53 pm
by sdaly
Another option for you may be to go for the profession licenses and use Ranorex in your preferred IDE with NUnit for test structuring. That way you can implement your own data management how you want it...

We use a test data class and an instance is created for each test and then serialised to xml. The test data class contains a deserialise method which gets the relevant xml files and desrialises it to the test data object. In that method you could make it look in the default location, then several fall back locations.... Just another idea :)

Re: Test data location as a parameter?

Posted: Mon Nov 21, 2011 7:11 pm
by carsonw
Cool thanks for the idea :)

Re: Test data location as a parameter?

Posted: Mon Nov 21, 2011 9:56 pm
by carsonw
Ok I was able to get this working - thanks again for the help!

One potential issue I can see though is this...

We use excel sheets for our data and we sometimes have several datasheets in the workbook.

The way it's set up now, you have to have a data connector for each datasheet in the book. So, if we had a workbook with 6 sheets... the command line is going to start to get pretty cumbersome.

For two, it looks like this:

mytest.exe /dataExcelConnectorName:Globals=c:\logintest.xls /dataExcelConnectorName:Logins=c:\logintest.xls

... and it works, which is great. But if I have 4, 5, or 6 or more sheets it's going to get out of control.

It would be nice if I could somehow say foreach dataconnector in suite set filename = X.

Not sure if this is possible at the moment, I will play with it some more when I get a chance, but this is a start.

Hopefully the built in future solution will accommodate this.

Carson.

Re: Test data location as a parameter?

Posted: Tue Nov 22, 2011 12:50 pm
by Support Team
Hi,
and it works, which is great. But if I have 4, 5, or 6 or more sheets it's going to get out of control.
What do you exactly mean, do you want to use more datasheets in a Test Case?
If so that's not recommended, you should use just one datasheet per Test Case.
The way it's set up now, you have to have a data connector for each datasheet in the book.
Yes, you have to have a test case per datasheet with one data connector.
the command line is going to start to get pretty cumbersome.
Can you please explain it more detailed, what gets pretty cumbersome?

Regards,
Markus
Ranorex Support Team

Re: Test data location as a parameter?

Posted: Mon Nov 28, 2011 11:29 pm
by carsonw
and it works, which is great. But if I have 4, 5, or 6 or more sheets it's going to get out of control.
What do you exactly mean, do you want to use more datasheets in a Test Case?
If so that's not recommended, you should use just one datasheet per Test Case.
Well, imagine if I have one xls file (let's call it test.xls) and it contains multiple datasheets. The data might be logically constructed that way because there's data that may be important to the test, but doesn't need to be repeated every iteration. Just a really simple example off the top of my head...
say you have a "global" sheet that holds data for your entire test - say it contains the URL that you should log into.
Then you have another datasheet "logins" that contains your variations - say a username and password.

Now in your test suite, I have one test called "Launch Browser" and it has a dataconnector called "Globals" to the "Globals" sheet on the test.xls file.
Then, I have another test called "UserLogging", and it has a dataconnector called "Logins" to the "Logins" sheet on the test.xls file.

Now, how can I handle this? I compile my test and the command line might look like this (doesn't work by the way):

test.exe /excelDataConnector:Globals=c:\Work\Ranorex\Testdata\test.xls /excelDataConnector:Logins=c:\Work\Ranorex\Testdata\test.xls

Even if it was one excel file per test case (ignoring multiple datasheets), as soon as I have multiple connectors in my test I now need to define every one of them through the command line somehow. If my test was huge and I had three or four connectors, my command line is going to start getting enormous (and again, the above solution isn't doing it right now for multiple connectors).

We have dozens and dozens of these sorts of sheets, some with many tabs (we have well over 13000 test iterations) and somehow we need to logically get this into a form Ranorex can use.

Failing that, we would have to rethink our entire approach to managing this data, but I am really loathe to change methods that work well for us for the sake of a tool (one of the reasons we are trying to get away from our current testing solution).

Re: Test data location as a parameter?

Posted: Tue Nov 29, 2011 12:21 am
by Ciege
Are you opposed to writing your own custom code and using Microsoft Office Interop to interact with your Excel sheets? Thats how we work here and I am able to gather whatever data I want from the spreadsheets regardless of the actual sheet it lives on...