Any limitation to Simple Data Table usage?

Ranorex Spy, Recorder, and Studio.
gilbar16
Posts: 109
Joined: Wed Mar 26, 2014 6:23 pm

Any limitation to Simple Data Table usage?

Post by gilbar16 » Sat Nov 14, 2015 12:45 am

When do you use Simple Data Table vs Excel or CVS file?
Any limitation on total number of rows you can have in a Simple Data Table? If so, what is the maximum?

Please share your thoughts on Advantages/Disadvantages of using Simple Data Table as compared to using Excel.

Thanks.
Gilbert

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

Re: Any limitation to Simple Data Table usage?

Post by krstcs » Mon Nov 16, 2015 3:19 pm

Here's my 2 cents:

I do not use Excel for test data. If you want something LIKE Excel, use CSV files, which can be edited in Excel, if needed. Since they are flat text files, they can be read/edited anywhere without having to have Excel installed. CSV are also faster and require less overhead. The ONLY benefit you might get from Excel is formulas, but formulas should usually not be part of your test data anyway as test data should be fairly static information. Any data manipulation should really be done in code (or in a DB if you are using one).

So, with that out of the way:

95% of my tests are dynamic so I use a database for storing data. The test cases are the same every time, but which test cases get run in each scenario is based on the data from the database.


The other 5% are static tests and I use the simple data tables for any data that is needed here.

I have found no practical limit to the size of the tables, but they are stored in the *.rxtst file (which is an XML file) with the rest of your suite, so making them really large could slow down the test suite. However, this does mean the data and any changes are also automatically saved in your version control system when you commit changes. (Excel/CSV files will also do this if you add them to the solution and your VCS, but you still have to edit them separately from the test suite.)

There are only two drawbacks I've found with the simple data tables. First is just that they are a flat data source. But compared to Excel, that isn't really an issue, since Excel is also flat. Second, you basically have to use Ranorex Studio to edit them. You could do it in a text editor, but the XML is not as easy to deal with as the editor in RX-Studio. If you make a mistake editing the XML directly you can compromise your whole test suite.
Shortcuts usually aren't...

gilbar16
Posts: 109
Joined: Wed Mar 26, 2014 6:23 pm

Re: Any limitation to Simple Data Table usage?

Post by gilbar16 » Tue Nov 17, 2015 7:07 pm

krstcs,

Thank you so much for the info/tips.
Very good points. We do have some people who prefer to use Excel macros to generate data automatically and hide them in our QTP/UFT Test Suites. The macros are not even documented so when something is failing, it takes awhile to figure out the solution.

I thought someone here would recommend something like:
If your test scripts require only 1 or 2 columns of data, a simple data table should be good enough to use.

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

Re: Any limitation to Simple Data Table usage?

Post by krstcs » Tue Nov 17, 2015 7:59 pm

I use simple data tables because any "flat" tests that I create generally have either very simple data requirements or are specific enough that they wouldn't be used by another test.

I don't have a real preference between simple data tables or CSV.

I much prefer a database though. 95% of my data is stored relationally in a SQL Server database. I use Stored Procedures for manipulation/collation of the data, and have some very specialized test modules that manipulate the data connector's SQL statement at runtime to make the test dynamic. This couldn't really be done with a flat data structure like CSV or the simple tables.


Excel is forbidden in my test automation. We do all reporting through the DB and a front-end web page.
Shortcuts usually aren't...