Champion Level 2Hi,
> you CAN'T make a DDT loop over a series of variables unless it is a structured data type
Yes, correct for the built-in data loop operation.
Actual implementation may vary and some code sample might help to better understand your needs and idea.
For example (untested jscript pseudocode)
var test_url = ...;
var pod_url = ...;
var arr = [test_url, prod_url];
for each (var url in arr) { // DDT loop
...
}
P.S.
From initial message:
> Live and test on different URLs - both MUST URLs be stored as separate string vars (liveUrl, testUrl)
I do not see the reason to store these two URLs in a separate variables (unless both of them are used within one test), but probably due to the fact that I know almost nothing about your actual test.
Store them as separate data entries for DDT or just easy switching between tested environments - yes, but store them in a separate standalone variables (i.e. not array, table variable, etc.) - no.
AlexKaras, this is similar to the way I am making the DDT loop var.
Live and Test as separate vars
All programmatic tests can have the vars together as I know where and what they are called/
For creating new tests I would like to have the distinction of 2 uniquely named vars for visibility (make it easier for people to create tests
Champion Level 2Hi,
Well, your initial statement remains correct: In order to be used in a DDT or any other kind of a loop, all loop elements must be a part of some structure that can be iterated through (array, list, dictionary, file, etc.).
So it is not possible to iterate through two separate standalone variables. (At least this is not possible using regular means available to the regular developer/end-user.)
> make it easier for people to create tests
Again, unless the test depends on the target URL, I don't really see how the knowledge of the URL can simplify test creation. If the test is created for specific environment (test or prod) then the knowledge of exact URL value barely helps either - you are just creating test for the functionality that must exist on test or prod and explicitly state that this given test is not expected to be executed on any but this specific test environment.
But these are regular generic considerations and you definitely know better what is required and who are your users for this given case.
So the initial statement remains unchanged and everything else is just exchange of opinions. 🙂
the test is not made for a specific environment
The 'main test' part of the test is generic and I am trying to get a drag a drop approach for creating tests for my colleagues
