What you have is, actually, aside from using CrossBrowserTesting, the best way of doing what you want to do.
So does that mean that adding a Project.TestItems.CurrentIteration would be a very nice property to have? Since we already have a CurrentItem...
Or even better, add a supported browsers variable to test items and have a checkbox 'repeat for each browser'.
Honestly, I don't see the need to go that route. You're running the loop through all your supported browsers and executing all your tests. Doing anything else I think just muddies the waters, IMO.
What do you intend to "improve" by making such changes? Perhaps with an understanding of that goal, I'll understand better what you are looking to do.
Well, we have dozens of test cases and every test case now has to be put in a loop.
Our project contains a test item called ''FrontEndTests' , which in turn contains subfolders containing all the testcases sorted by functionality.
If there was a way to simply repeat that single test item for various browsers, that would be much cleaner.
I could of course collect the various test cases in a function and only have that function contain the loop, but we don't have that test item page for nothing. It's lacking as it is (no way to execute a single test item in the list by using parameters in test execute for example. You either test the entire batch or you execute a single function somewhere in a script).
Any improvement would be welcome. Such as the current iteration for example, which would allow you to set variables for each iteration).
Take this example:
- you can't choose to only run 'Tenants_Backend' or 'Members' inside the AccessControl_Backend. You either have to run everything or -for example- that single script POST_Members - API_POST_Members .
And each and every test has to contain the browser loop. Unnecessary extra for statements imho.
Why not improve it and make it more powerful? That tiny little currentIteration variable already gives a great amount of power to each repeating test because it enables you to set a different set of parameters for each and every iteration.
And TestComplete already knows this information otherwise it wouldn't know if it reached its number of iterations.
I'm not a SmartBear staffer... but here's my thinking as to why TestComplete is designed as it is, including the TestItems page...
The Test Items page is there provide an interface to organize test cases for someone who is not necessarily skilled in writing more complicated loops, conditional statements, etc. To allow someone to add test cases that can execute multiple times, organize them in related groups, etc., such a feature is necessary.
But you've already demonstrated that your abilities are already beyond that point. This is where a more complex framework comes into play. I'd suggest leaning in the direction of something where your test code is modularized and generalized and is driven by external data, including which test cases, specifically, to execute. In that type of scenario, TestComplete is the IDE that is used for developing the framework, but structuring a test run ("I want to run test cases 1, 3, 4, 7, and 11 against browsers a, b, c") is all handled in the data source. Some use Excel, some use CSV, some use SQL.
That's actually where I would send you in your development if you want to get "smarter". Design some sort of framework where you could basically build a set of data that, when you push "Play" in TestComplete would execute exactly what you want (test cases 1,3,4,7, 11 against browsers a, b, c). I know it sounds simple and on one level it is... but it is a more complicated effort... you wanted to go "smarter" though... that's as smart as it gets.
