Forum Discussion
- tristaanogreEsteemed ContributorYou just did. :-)
Or, you can go to their support page and open a ticket that you can submit as a feature enhancement.
A question: what is the need for this? Can you achieve the same result using an implementation of Log.SaveResultsAs? - alinderContributorI think if you are still trying to figure this out you should look more at the suggested Log.SaveResultsAs method. There should be no more trouble calling it at the end of execution to archive the log than you would have calling something at the beginning of execution to change the location.
Exported logs are less convenient to debug than TestComplete's logs, but debugging is probably not a primary activity when you are at the stage to run for record. - irina_lukinaSuper Contributor
Hi Harlan,
In my environment, I feel this feature would be beneficial. How do I let SmartBear know I would like this added to TestComplete?
Could you please clarify why this feature is so important for you? Why do you need to change the log location programmatically? Also, why can't you use the approach suggested by Andrew?Thanks.
- ray_mosleyFrequent ContributorThanks for the responses. I will submit this to Support as an Enhancement Request.
I have other forum & support questions ongoing, especially dealing with using TestComplete with a source control system. We have noticed that as we debug scripts, the number of log files grows and causes issues with merging essentially unwritten log (created while debugging scripts) to the source control system. Yes, you can reduce the number of log files kept, but you are still creating your log file in the project tree by default.
Similarly, using the Log.SaveResults method simply saves a copy of the existing log file somewhere. The exising log file will still be put inot source control unless the script developer remembers to delete the log files.
Yes, you can set the location of the log files to be outside the tree, and that is better than nothing. What I would prefer is to have my script default to a temprary location (for example, C:\temp\projectName\date\script_time) while I am debugging. WHen the script is completely developed and ready to be part of my regression suite, I can change the path to a permanent archive location (for example, \\Server\projectName\date\script_time).
Doing this provides several advantage:
1) I can blow away the C:\temp directory at will without affecting my script or the source control system.
2) using a permanent archive location also does not affect the contents of the source control system.
3) If continued modifications of the script are needed, I can still toggle the "run for the record" permanent archive location and the C:\temp location as needed, and do it in a single place using a boolean variable or even external sentinal file. - irina_lukinaSuper Contributor
Hi Harlan,
Thanks for the responses. I will submit this to Support as an Enhancement Request.
I've found your request in our DB. Thanks for your feedback.We have noticed that as we debug scripts, the number of log files grows and causes issues with merging essentially unwritten log (created while debugging scripts) to the source control system.
Actually, we don't recommend that you keep log files in a source control system. By default, TestComplete doesn't add these files to the source control system as the test results node may contain a large number of log files (as in your situation). For more information on the files that are added by TestComplete, see the List of Files Added to Source Code Control help topic. So, if you add the project files to the source control system manually, we recommend that you add only those files that are listed in the topic mentioned above.What I would prefer is to have my script default to a temprary location (for example, C:\temp\projectName\date\script_time) while I am debugging. WHen the script is completely developed and ready to be part of my regression suite, I can change the path to a permanent archive location (for example, \\Server\projectName\date\script_time).
As Jared has said, the requested functionality is registered in our DB as a suggestion. As for now, I have only one workaround: you can try opening your project in a shared mode when you debug your tests. To learn how to do this, see the Sharing Projects and Project Suites Among Several Testers help topic. When you open your project in shared mode for the first time, change the log location to the needed path, for instance C:\temp\, and save the changes. TestComplete will save the specified setting only for the project opened in shared mode. So, when you open the same project in normal mode, the log location setting will contain the default value. That's how you can make TestComplete store several values of the mentioned setting.I hope this information helps :)