I have test data in Excel, but because of current limitations of TC in Data driven testing, I need to use Data Table Variables.
When using copy / paste to copy the data out of Excel into the Table Variable, all selected data is pasted as one long string in one cel.
Obvious this is not what I want. I want the rows to be maintained.
See attached screenshot for clarification.
What limitation did you find in DDT?
The limitation is, that when using Excel files (or other external data files, CSV, etc), you cannot iterate just one 1 row in each test run. This limitation is best described using an example. I use Keyword testing by the way.
Here is an example of what I mean:
testdata (for example, in Excel file):
row 1: testdatastring1
row 2: testdatastring2
row 3: testdatastring3
etc.
In a keywordtest I have a command:
keys (data from testdata file (Excel file);
(to put the testdatastring1 in an input field in some application.)
This works fine in a Dataloop, but it has following limitations:
you can only iterate to the end of the file, or a number records (start / end row);
HOWEVER, I want to achieve following:
In each test run, the next row should be picked out of the Excel file.
Starting on row 1. Next execution row 2, next 3. etc.
But not in a continious mode (like datadriven).
When the second test run is executed, TestComplete is closed/ , and next day TestComplete / same test is started again, then when same test is run, the next row (3 in this case) is picked from the Excel file.
As far as I can see, This is currently only possible when using Data Table Variable, in combination with using a persistent variable as a row index. But, because you cannot define the row index when using external data files (Excel, CSV), the above scenario is not possible when using Excel files.
Hope this is clear what I mean....
It definitely would be good to have this built in some way.
What we did as a workaround was to put an index column in the Excel sheet, then iterate through that. If the index variable = index value in Excel row, then execute the test, otherwise skip it.
If you like the feature request, then please vote for it ;)
Using your workaround, it sounds workable but do you have read the whole Excel sheet in each run untill the index variable = index value? If so that would result in a lot of Excel searching right? And a lot of coding to create/maintain?
Yes, it would read the whole sheet every time but that's actually relatively quick.
Not a lot of coding, just a loop to manage the index. The rest of the test is the same as it would be otherwise.
We also use it when we want to group data. Say we have a list of parts that for most tests we want to use the whole list but sometimes we want to just run it for the parts that are a certain color. Then we would use a parameter to look for the rows that have that color and do the test. That's still a sort of index but it would find more than one row in that case.
Ok, sounds like an interesting approach.
However, I do hope you vote for my feature request :)
