Best practice to bind data at runtime

Ask general questions here.
tvu
Posts: 195
Joined: Tue Apr 07, 2015 10:47 pm

Best practice to bind data at runtime

Post by tvu » Wed Jun 15, 2016 12:18 am

Normally, when I want to repeatedly run a test case I would just bind that test case to a CSV file. The report log will show the results for each iteration.

Now, my issue is that I can't get the test data and the number of iterations until runtime. What's the best way to bind this dynamic data so that everything is reported correctly.

I can think of two ways to do this:
  • Have a test case with two inner test case. The second inner test case will be bind to a CSV file that has the headers, but no test data. The first inner test case would determine the test data and populate this CSV. My concern is that I don't know when the data gets bind. If it gets bind at the start of the test suite then this won't work. But, if it gets bind immediately prior to the execute of the second inner test case then it should work.
  • Create the test case and test iteration all by code. But, I couldn't find the best way to do this on the site. This test case and all iteration will be a part of a larger test suite that is setup in the traditional manner and not by code.
The first option seems a lot simpler to setup and maintain, but I don't know if it will work because of the concern regarding the timing of the data bind. If the second option is the best way then please provide some information on how to setup a test case and test iteration via code. It will need to add the result to the current test suite that would be running.

Thanks in advance.

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

Re: Best practice to bind data at runtime

Post by krstcs » Wed Jun 15, 2016 2:43 pm

If you are wanting dynamic data, you need to use a database, not a static file or simple connector. Ranorex is not designed for dynamic data connectors (connectors whose data changes based on current test conditions), so you would also need to make modules that change the SQL queries right before their use. I do this all the time with SQL Server.
Shortcuts usually aren't...

tvu
Posts: 195
Joined: Tue Apr 07, 2015 10:47 pm

Re: Best practice to bind data at runtime

Post by tvu » Wed Jun 15, 2016 7:03 pm

Thanks krstcs.

Can you give me an example of how you are using an SQL server to dynamically bind data to a test case? Are you using a SQLDateaConnector? Are you getting your data from a query and then calling C# methods instead of an entire test case?

I don't think I need to make SQL queries because I can already generate the dynamic data. My issue is trying to figure out what to do with the data to kick off an iterative test case and have it properly reported.

tvu
Posts: 195
Joined: Tue Apr 07, 2015 10:47 pm

Re: Best practice to bind data at runtime

Post by tvu » Wed Jun 15, 2016 7:10 pm

Thanks krstcs.

Can you give me an example of how you are using an SQL server to dynamically bind data to a test case? Are you using a SQLDateaConnector? Are you getting your data from a query and then calling C# methods instead of an entire test case?

I don't think I need to make SQL queries because I can already generate the dynamic data. My issue is trying to figure out what to do with the data to kick off an iterative test case and have it properly reported.

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

Re: Best practice to bind data at runtime

Post by krstcs » Wed Jun 15, 2016 8:24 pm

Yes, I use SQL Data connectors.

I do use SQL Queries (which is required with SQL and most other databases...)

I use C# only to set the data connector's new query string with whatever parameter values are needed.

If you already have dynamic data, I'm not sure what you are needing. Can you explain more about what you are trying to accomplish and why your current approach isn't working?
Shortcuts usually aren't...

tvu
Posts: 195
Joined: Tue Apr 07, 2015 10:47 pm

Re: Best practice to bind data at runtime

Post by tvu » Fri Jun 24, 2016 9:36 pm

Thanks krstcs,

I data bind my CSV to the test case via Studio for ease of maintenance. What I am trying to do is bind a CSV Data Connector to a test case, but that CSV would have no data and will be populate at run time.

I finally got around to setting this up and my first idea worked.

Thanks again.

tvu
Posts: 195
Joined: Tue Apr 07, 2015 10:47 pm

Re: Best practice to bind data at runtime

Post by tvu » Fri Oct 07, 2016 7:47 pm

This message is for younes.fh.

For whatever reason, my private message I sent you have been sitting in the outbox for ages.


This is my setup. I have a CSV that has one line containing only the headers. I have a data connector for it in "Manage Data Sources".

Content of CSV:
header1,header2,header3

Now, I have a test case with two sub test case:
1. Parent Test Case
1a. First Sub test case that will write to the CSV.
1b. Second test case that does "the stuff".

I data bound the CSV to 1b. It runs like any other test case that you bind with test data. All the work with dynamically generating data is done in 1a.

Here are the steps I took to write to the CSV in 1a.
  • create an instance of a data connector.
  • dataConnector = new Ranorex.Core.Data.CsvData.CsvDataConnector.CsvDataConnector(name, fileName, withHeaders) where "name" is the data connector name and "fileName" is the path to the CSV file. "withHeader" is a bool with a value of true.
  • dataConnector.SeparatorChar = ','
  • dataConnector.LoadData(out columns, out rows)
  • I use this CSV multiple times so I always delete the data after initializing it by doing the following: rows.Clear();
  • You can add data to the CSV by doing the following: rows.Add(). In this example with the three headers, it would be something like this: rows.Add(new string[3] {"header1Value", "header2Value", "header3Value"})
  • After adding the necessary data then I save it to the CSV file with the following: dataConnector.StoreData(columns, rows)
I don't do anything with the GetTestCase() or tc.DataContectReloadData().