Mapping data source values to JSON

Best practices, code snippets for common functionality, examples, and guidelines.
Vaughan.Douglas
Posts: 254
Joined: Tue Mar 24, 2015 5:05 pm
Location: Des Moines, Iowa, USA

Mapping data source values to JSON

Post by Vaughan.Douglas » Thu Jul 06, 2017 7:28 pm

I'm working with a guy that is loading data into his AUT via a JSON file loader. He's then verifying the output data on the other end of his workflow process. Today he's using an Excel data connector to validate the data, so row 1 contains the expected and row 2 contains the actual. Why/how the "actual" data winds up as row two in his data source and is not being validated directly from the AUT is something I'm still trying to work through myself...

The nut of my challenge is that if the test data needs to change (and it does) it needs to be changed in both the JSON file and in the Excel data source. I'd like to remedy that so that all data resides in a single point of contact. Either I validate directly from the JSON file or a JSON file is created based on an Excel data source.

We'd like to keep the custom coding to a minimum, so if there's some nuget repositories or other approaches folks could recommend I'd appreciate it.
Doug Vaughan

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 7470
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Mapping data source values to JSON

Post by odklizec » Fri Jul 07, 2017 8:28 am

Hi,

If I were you, I would replace Excel with CSV data connector and then use some kind of JSON2CSV conversion, as discussed for example here:
https://www.codeproject.com/Tips/565920 ... -in-Csharp
https://stackoverflow.com/questions/404 ... in-c-sharp
I'm afraid, you will have to put together some code. There is probably no way around.
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

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

Re: Mapping data source values to JSON

Post by Vaughan.Douglas » Fri Jul 07, 2017 12:10 pm

odklizec wrote:Hi,

If I were you, I would replace Excel with CSV data connector and then use some kind of JSON2CSV conversion, as discussed for example here:
https://www.codeproject.com/Tips/565920 ... -in-Csharp
https://stackoverflow.com/questions/404 ... in-c-sharp
I'm afraid, you will have to put together some code. There is probably no way around.
They guys I'm working with are new to Ranorex and seem to have some pretty strange ideas of what is an is not a good idea. They've decided they don't want an external data file (Excel or CSV) Do you suppose a similar approach could be accomplished through the internal data table? I have some vague ideas of how I might go about it.

I'm not familiar enough with their tests to start dictating changes in approach... yet.
Doug Vaughan

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 7470
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: Mapping data source values to JSON

Post by odklizec » Fri Jul 07, 2017 1:57 pm

Using internal data table is, in my humble opinion, a very bad idea from the long term perspective. It may look easiest to create internal data table directly in Ranorex Studio. But it will definite blow the rxtst file during the time. Although I don't have any hard data, I would worry about the speed of solution loading. But even if not, using internal data tables will make the data connectors very hard to compare! And I bet that at some point in time, someone will like to compare the data connectors. This is for example why I stopped using Excel data connectors in favor of CSV files. CSV files are pretty easy to compare, fast to load, independent from Excel and could be edited directly in Ranorex Studio! And the best of all, because Ranorex supports writing to CSV data connector via code, I can easily switch my tests from "validation" to "data generation" mode. So when dev. guys change this or that aspect of AUT (usually add or remove some settings), I can easily generate new ref. data.

All in all, using internal data table only because someone don't want to use "external data", is a very weak argument. What's the problem with external data, if everything is in source control? The only problem could be if someone is not using source control and distributes files manually. But this is a very silly idea anyway ;)
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

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

Re: Mapping data source values to JSON

Post by Vaughan.Douglas » Fri Jul 07, 2017 2:54 pm

odklizec wrote:Using internal data table is, in my humble opinion, a very bad idea from the long term perspective. It may look easiest to create internal data table directly in Ranorex Studio. But it will definite blow the rxtst file during the time. Although I don't have any hard data, I would worry about the speed of solution loading. But even if not, using internal data tables will make the data connectors very hard to compare! And I bet that at some point in time, someone will like to compare the data connectors. This is for example why I stopped using Excel data connectors in favor of CSV files. CSV files are pretty easy to compare, fast to load, independent from Excel and could be edited directly in Ranorex Studio! And the best of all, because Ranorex supports writing to CSV data connector via code, I can easily switch my tests from "validation" to "data generation" mode. So when dev. guys change this or that aspect of AUT (usually add or remove some settings), I can easily generate new ref. data.

All in all, using internal data table only because someone don't want to use "external data", is a very weak argument. What's the problem with external data, if everything is in source control? The only problem could be if someone is not using source control and distributes files manually. But this is a very silly idea anyway ;)

Like I said, I'm just now getting involved with this project. You'd cry if you only knew... Thank you for the suggestions. I will propose we use a CSV file, I don't think they know what they mean by "external data" anyway since it's going to be incorporated with the solution.

Do you have a bit more information on how you're using the CSV data connector to generate data? Is it truly bidirectional meaning I can write a value to the CSV and use it later in the same execution without restarting/reloading? Is it as easy as grabbing an attribute value and binding it to a data column, because that would be sweet.
Doug Vaughan