Forum Discussion

MulgraveTester's avatar
MulgraveTester
Frequent Contributor
14 years ago

FEATURE REQUEST - Preserve TestComplete Log Files

During development and debug of test scripts it is helpful to have the "Number of recent logs to keep" parameter in the Tools\Options\Engines\Log set to a low number so that the number of visible logs is managable. Setting this value causes TestComplete to delete any older logs than the number specified here.



Occassionally it is important to preserve a test log (because of a significant build, particular test environment or parameters, complete or partial execution etc.).



If the log file is copied elsewhere in order to preserve it then there does not appear to be a way to open it with TestComplete.



The only way that I have found to preserve a test log is to export it to an mht file. My log files are so large that they fail to execute as mht files when loaded into IE and do not have the filter features of a true log within TestComplete.



I would like to request that it would be possible to flag log files for preservation so that they are not automatically deleted and not included in the count of "Number of recent logs to keep".



Alternatively, a way to open stand-alone copies of logs, would also be useful. I particularly would like to be able to click on a particular log entry and be taken to the script line being executed in the code (as can be done for existing log files).



Thanks,



Michael
  • Hi Michael,



    I have registered your request as a suggestion in our DB. Thank you. Currently, you can remove the log files from TestComplete project and copy them to another location. Later, when you need to view them, you can add them back to the project via right-clicking the logs folder in Project Explorer and selecting the "Add | Existing Log File..." context menu item.
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    I've also found it useful to create a quick routine to export the log file at the end of every test to a location to be archived.  I usually use the MHT file format (using Log.SaveResultsAs).  This allows me to share the logs with other non-TestComplete users.
  • MulgraveTester's avatar
    MulgraveTester
    Frequent Contributor
    Hi Allen and Martin, Thank you both for your feedback.



    I have written heaps of code to validate every field of a large windows app and have just started test execution. Sorry to gripe but I am finding the log file management very labour intensive. I am running TestComplete on my XP machine and TestExecute on a Win7 PC which I have to connect to using Remote Desktop (as it is not on our domain).



    1) Creating the log file only at the completion of testing has caused me issues. Hours into test execution the script crashed the PC. As there was no log file created it was not clear which part of the code caused the crash.



    2) As the log file is created at the end of testing, I don't see Martin's point of writing a script to auto archive the log at the end of testing.



    3) My logging is verbose so that the log files are so large that they cannot be opened in IE.



    4) Due to (1) & (3) I have broken my test down to test one form at a time. Ther are over 120 forms so I manually have to edit my DDT to select just one form then execute the test. Some runs are performed multiple times, so that I end up will a collection of log files - some valid, some junk. The log files only have a date stamp for a name and I have no idea which is which. So I have to copy the files from the remote PC to my PC, import them into TestComplete. Sort the wheat from the chaff, delete the chaff and give the good logs a meaningful name within the TestComplete log. However, this does not rename the files  which are still anonomous. The files cannot be renamed (now that we know which is which) because this breaks the log file displayed within Test Complete.



    I am sure that there must be an easier way to do all this. I just thought that I would give you some feedback, in the hope that this can all be simplified.
  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor
    1)  There is an auto-save feature of the log file that, every so many minutes, it is saved to disk.  Now, if your PC crashes, that saved log won't be linked to the project, but it is not "lost".  Using Allen's suggestion, you can navigate to the default log location for your project and re-add it into your project for evaluation.



    2)  You can also use an "OnStopTest" event handler to write your log file out when a test item is completed or, even, write it out OnLogError or OnLogWarning.  This will allow you to dump your log out for particular problems to allow you to recapture that state at some point in time.



    3)  You might want to consider reducing how much is in the content of your log file.   Are all the messages strictly necessary?  All the screenshots?  Etc.  Do you really need to know each time the test goes to a particular form and writes something out... or do you only need to know when it fails?  These are just a couple of questions I consistently ask myself when building a project for this exact reason.  Log files can get unwieldy if too much unnecessary "noise" is logged to them.  I'm not saying you don't have some necessary logging, but it may be that you can reduce some of the "noise" to only those essential things you need for a regular run.



    4) My solutions for 1 and 3 may be helpful to make your efforts for 4 unnecessary.  However, the use of Log.SaveResultsAs may be helpful in your solution for #4 as you can name the log files as you want them to be named by passing in values and such to give the files a unique name.  MHT is only one of the methods you can use.  If you use the XML format, I THINK (but I'm not sure) that this is the "raw" format that is generated by default by TestComplete that you can then re-add back to a project.



    Hopefully my suggestions can give you some direction to be better able to manage your logs.
  • MulgraveTester's avatar
    MulgraveTester
    Frequent Contributor
    Thanks Robert for your detailed feedback. I'll give some of your suggestions a go.



    Cheers



    Michael