dynamic data connector filename at runtime

Best practices, code snippets for common functionality, examples, and guidelines.
Marc
Posts: 10
Joined: Wed Feb 15, 2017 5:54 pm

dynamic data connector filename at runtime

Post by Marc » Thu May 11, 2017 11:50 pm

Hi, I'm on version 6.2.1.

Trying to figure out a method to dynamically assign the filename for the data connector sourcefile (a csv file) as a command line argument.

The closest I found was a post from 2011 that doesn't actually appear to work now, though that could just be my not following correctly. In that post it was noted that this is a feature that was coming, but I can't see how to do it?

how-to-pass-data-source-name-via-command-line-t10479.html
^^ That's the post, but I can't post URLs with this account (too new).

Thx,
-Marc

qwertzu
Posts: 178
Joined: Wed Jan 25, 2017 11:08 am

Re: dynamic data connector filename at runtime

Post by qwertzu » Mon May 15, 2017 12:08 pm

Hello Marc,

Unfortunately it is not possible to assign the filename for the data connector during runtime via command line.
However, could you explain what exactly you want to achieve?
Maybe we can find a workaround that would help you.

regards,

qwertzu

krstcs
Ranorex Guru
Posts: 2683
Joined: Tue Feb 07, 2012 4:14 pm
Location: Austin, Texas, USA

Re: dynamic data connector filename at runtime

Post by krstcs » Mon May 15, 2017 1:40 pm

If you really need dynamic data, you should use a database instead of flat files. Databases are designed specifically for dynamic data.
Shortcuts usually aren't...

Marc
Posts: 10
Joined: Wed Feb 15, 2017 5:54 pm

Re: dynamic data connector filename at runtime

Post by Marc » Mon May 15, 2017 10:09 pm

We are making a macro language that can be scripted and passed in as a data connector and we simply parse the line coming in and call our automation methods for testing. This lets Ranorex deal with filehandles, looping, and all that for us.

It's purpose is to allow our support analysts to make scripts to do common tasks, and prototype stuff easily, then hand off to my cohort and I to develop a purpose built testcase that can use the more normal use of the data connectors to provide permutation data for one repeating test.

If we're always locked into the same filename then we obviously risk accidental overwrites and such.

I find it odd that this (command line arg for filename of test data) isn't supported as I could easily see the need for the same testcase to have multiple datasets (sanity check, vs short regression, vs long regression).

I suppose we'll just use the parameter option and do our own file parser... not the end of the world, but feels like reinventing the wheel in this case.

Thanks :)

-Marc

qwertzu
Posts: 178
Joined: Wed Jan 25, 2017 11:08 am

Re: dynamic data connector filename at runtime

Post by qwertzu » Tue May 16, 2017 12:49 pm

Hi,

I would suggest adding your wish to the User Voice Platform.
If some other customers vote for this feature too, Ranorex may implement it.
Here is the link to Ranorex' UserVoice: http://uservoice.ranorex.com/forums/150 ... ve-ranorex

regards,

qwertzu

Vaughan.Douglas
Posts: 250
Joined: Tue Mar 24, 2015 5:05 pm
Location: Des Moines, Iowa, USA

Re: dynamic data connector filename at runtime

Post by Vaughan.Douglas » Thu May 18, 2017 4:51 pm

Marc wrote:We are making a macro language that can be scripted and passed in as a data connector and we simply parse the line coming in and call our automation methods for testing. This lets Ranorex deal with filehandles, looping, and all that for us.

It's purpose is to allow our support analysts to make scripts to do common tasks, and prototype stuff easily, then hand off to my cohort and I to develop a purpose built testcase that can use the more normal use of the data connectors to provide permutation data for one repeating test.

If we're always locked into the same filename then we obviously risk accidental overwrites and such.

I find it odd that this (command line arg for filename of test data) isn't supported as I could easily see the need for the same testcase to have multiple datasets (sanity check, vs short regression, vs long regression).

I suppose we'll just use the parameter option and do our own file parser... not the end of the world, but feels like reinventing the wheel in this case.

Thanks :)

-Marc
Are you actually trying to use dynamic test data or are you trying to create a keyword driven framework sitting over top of Ranorex? You can use the run configuration to do something like Long regression versus short regression, but that's just a difference in selecting which test cases to actually run. You can also change the range of the data source by command line. Example (sudo example anyway):

Code: Select all

KeePassTestSuite.exe /rc:SmokeTest /tcdr:AddEntryByRecording=1-2
I don't think you can actually change the binding SOURCE itself because you'd have to rebind all of the data elements in each test case.

You've proposed an interesting question and I'm interested in finding a solution just for academic fun, but I'm still not 100% sure of what you're really up to.
Doug Vaughan

Marc
Posts: 10
Joined: Wed Feb 15, 2017 5:54 pm

Re: dynamic data connector filename at runtime

Post by Marc » Thu May 18, 2017 10:06 pm

It's a keyword driven overlay.

We have a large staff of competent (but non programmer) people that write specs for new features and/or fixes for existing features.

We want to give them a way to (basically) write a batch file that will be interpreted by Ranorex and executed.
The end goal is empowering our staff to make prototype test cases that either trigger a bug or illustrate a missing feature need easily, even if not particularly robustly or exhaustively. That can be used to get the developers started on a patch, while QA can take that as a spec of sorts and write a "real" testcase for it.
I actually have a functioning prototype of this system, but of course if everyone were to be forced to use the same filename for their script... ick.

In an older post there was indication that a feature like this was coming.
I don't think any re-binding is actually required, as the sourcefile still will be the same format (column to variable map) I just need to (sleight of hand maybe) swap out the compiled in filename with that of one passed in as a command line parameter, even if it is a

Code: Select all

/tcpa:script=<filename here>
type of argument.

To that end, does anyone know where the filehandling part of Ranorex is, and if there is a way I could read a parameter variable (testcase or global, I don't care) and swap that in for the aforementioned compiled in filename?

Of course the super hack-job way (and I *really* want to avoid this) is to call ranorex with a batch file that first copies their script thusly:

Code: Select all

:: invoker.bat, called as: invoker <script file name>
copy %1 userScript.csv
ranorex.exe
del userScript.csv
Thanks,
-marc

Vaughan.Douglas
Posts: 250
Joined: Tue Mar 24, 2015 5:05 pm
Location: Des Moines, Iowa, USA

Re: dynamic data connector filename at runtime

Post by Vaughan.Douglas » Mon May 22, 2017 3:16 pm

Ok so first of all as someone who enjoys making all things bend to his will, this is a bad idea. The Ranorex API especially the less documented portions change fairly regularly as new and more robust features are added. The maintenance on your framework will eventually impede your ability to get work done. I'm not saying that you aren't capable, I'm saying from experience that you should tread lightly.

For prototyping with Ranorex, I'd have your users use Ranorex Studio and record the steps with a library integrated into the module itself. Then pass those along to your QA staff to port those into quality modules with a shared object repository and probably a Module Repository Project.

As the coverage builds the prototypers will use existing modules to piece together steps and have fewer and fewer points that need to be recorded.

If you want to build your own framework, I would suggest building your own framework. If it's a web app just use selenium.

All that being said and because I just can't help myself, I think you want to take a peek at the DataConnectorManager object.
Doug Vaughan

Marc
Posts: 10
Joined: Wed Feb 15, 2017 5:54 pm

Re: dynamic data connector filename at runtime

Post by Marc » Mon May 22, 2017 7:11 pm

Vaughan.Douglas wrote:Ok so first of all as someone who enjoys making all things bend to his will, this is a bad idea. The Ranorex API especially the less documented portions change fairly regularly as new and more robust features are added. The maintenance on your framework will eventually impede your ability to get work done. I'm not saying that you aren't capable, I'm saying from experience that you should tread lightly.
Yeah, this is one of my top three concerns (this isn't my first rodeo implementing something like this and the non-trivial maintenance it ultimately requires).

For prototyping with Ranorex, I'd have your users use Ranorex Studio and record the steps with a library integrated into the module itself.
My users will (out of habit from other tools) leave the studio open and eat up our licences. Yes training issue, but we all know the difference between theory and practice ;)
Then pass those along to your QA staff to port those into quality modules with a shared object repository and probably a Module Repository Project.

As the coverage builds the prototypers will use existing modules to piece together steps and have fewer and fewer points that need to be recorded.

If you want to build your own framework, I would suggest building your own framework. If it's a web app just use selenium.

All that being said and because I just can't help myself, I think you want to take a peek at the DataConnectorManager object.
Thanks :-)

As a simple workaround I just made a global parameter as filename and did the filehandling myself in user code.

Vaughan.Douglas
Posts: 250
Joined: Tue Mar 24, 2015 5:05 pm
Location: Des Moines, Iowa, USA

Re: dynamic data connector filename at runtime

Post by Vaughan.Douglas » Tue May 30, 2017 2:03 pm

Marc wrote:As a simple workaround I just made a global parameter as filename and did the filehandling myself in user code.
I've done something similar to control data elements per environment (example setting the environment to "dev" will modify the URL and credentials) to handling global popup blockers (ie popup blockers that I need to persist between modules).

I started out focusing on the limitations of Ranorex, so I'd code EVERYTHING. All modules were coded modules. all Rx paths where either written inline, a variable, or stored in a sudo-library. This meant I could create scenarios with extreme precision, but it also meant I had to own it as only a handful of folks could write code and even fewer had enough experience writing tests that they could follow along.

After a few iterations, I ended up rewriting everything into recorded modules. Now my less technical folks could understand and follow what was going on. I forced them into simplifying their scenarios. NO scenarios branching, period (this is the hardest thing to get used to). They say "If this happens then do this otherwise do this" and I usually say "ok which one is the pass condition?" and the other is a failure. If you want them to both be pass conditions, fine, then you have two scenarios. Believe me when I say this is easier said than done.

I don't actually record anything. I write my RxPath by hand and drag/drop steps into the module. This has increased adoption and implementation across my install base. This has also freed me up to handling those complex situations that can't be jammed into such a straight forward flow.

Finally they key to my personal flexibility is using Excel as a data source. Excel is an imperfect solution, but it does offer some advantages. Primarily the fact that you can get all crazy with Excel formula and Ranorex will just read the resultant cell text allows users to set all sorts of fun things. So for example, I may have a username but the password is contextual based on the environment. I can set a column in the datasheet to represent the environment and use some Excel magic to get the appropriate password based on the environment and username.

Likewise you could have the user set his/her username in a column and use index/match lookups to bring back all the appropriate data.
Marc wrote:My users will (out of habit from other tools) leave the studio open and eat up our licences. Yes training issue, but we all know the difference between theory and practice ;)
This is a huge issue. As far as I'm concerned Ranorex needs to offer a means to boot people off the license server from some sort of control panel (vote for this here). I don't have access to the license server in my organization, but as I understand this isn't a feature that is currently available. Our "offshore" resources just lock up their machines rather than logging out at the end of their day, which blows my mind. Why don't you just shut down or at the very least reboot.

Ok, I've enjoyed geeking out. Welcome to the Ranorex community and I look forward to your contributions!
Doug Vaughan