I think I understand what you're saying with the first option, and that could make a lot of sense and be relatively easy to implement. Unfortuntely option 2 may not be a viable option, as converting test cases I have already scripted to keyword tests might be an issue, I also do not know if all my functions/checks would carry over nicely to keyword testing.
Do you have a reliable way to search the mds files and change the correct values you need to enable/disable a script to run? Looking at the mds file itself a lot of identifiers are re-used throughout the file, and finding the enabled value for a certain script seems unreliable with normal finds.
I am also attempting to load the mds file with c# code and display the information in an easy to read tree view, but that too has been proving difficult.
Unfortunately I don't have anything for editing the .mds file reliably, I gave up on that option and went with option 2.
You don't have to use keyword tests at all, I was just saying that you could. All you have to do is launch TestExecute with it pointing at a specific script routine/function. Then have that script routine/function call the script routines/functions that have your test code.
I think I get what you're saying I'll play around with that today and see how it works thanks!
If command line is an option, you may consider this: https://support.smartbear.com/viewarticle/54655/
I'm afraid command line is not an ideal solution, as the syntax/execution of it might be a little much for my other team members who will be using TestExecute.
I did create my own solution using the suggestions earlier in the thread, and although its not super pretty, it does exactly what I want it to do.
I started by creating a text file that lives in the project folder of my testcomplete project. This file contains a list of scripts that can be run for the project and an "Enabled" or "Disabled" label at the end of each test name.
I then created an executable in C# which would read this file, and display a checkbox window similar to the one within testcomplete, but much more bare bones and I did not implement a tree view. Here the user can check or uncheck which tests they want and click a save button, which then replaces the Enabled or Disabled string in the text file accordingly.
Lastly I created a script for the automation project which reads in this test file, and checks for the enabled substring for each test, and based on if the test has that enabled substring, it calls the associated script function for performing the automated tests.
I plan to make this solution more modular and user friendly as time goes on, as I feel it will be ideal for allowing other team members not exactly familiar with the testcomplete/testexecute tools to run useful automation with little confusion/setup time.
Big thanks for Ghuff for the suggestions which lead me to this solution.
