Right now, the way I handle it is creating a local data grid in the parent test, and using a single row with multiple columns to send the proper data to a Test as Step (usually no more than 5-10 columns), which inherits the parents data source.
Example: There is an individual parent test for individual data tables (lets say I have 10 tables, and 10 parent tests), which will export the data to an MDB file. Test as Step will be used to handle the actual export functionality which requires a file path and table name. It should get these values from the parent test, as this will be used in a bunch of different tests.
I'd like to avoid using coded steps (in each parent) or an external code file because if I need to change an element reference for any reason, it takes forever to update them all.
I know I could also create a single coded step in each parent and use a handful of SetExtractedValue(); and get those from the Test as Steps, instead of using the local data grid.
Any other solutions that I'm overlooking?
2 Answers, 1 is accepted
Once the coded step and handle the data with code is not a desired option I think you got the other approaches to this problem. To inherit the data-source from the parent seems to be the most natural way to transfer data in the test hierarchy.
Regards,
Nikolay Petrov
Telerik by Progress
Rank 1
Thanks! I ended up opting for the single coded-step and using Gets/Sets to set data in the parent, and get in the Test as Step.
Using that data grid was making the test list results and result logs a lot more work to go through, and in the end I think this will probably be a cleaner solution.