Developing The Common Repository Logger
The Common Repository Logger was created to solve logging issues when it came to grammar and regular expression issues within our scripts. Creating a framework to do this will allow us to standardize logging across all products and improve the quality of our code for it’s purpose: ATC Development. Take the below code for example (Modified):
Onto the Good Stuff
(Edited code to enhance logging errors)
There are a few logging errors wrong with this sample code:
- The error message in VerifyGridColumnExists is too generic.
- Unusual capitalization in the Log.Message in VerifyGridColumnExists
- If Column was provided as a regular expression, the Log.Message would return the regular expression.
Now using the Common Repository Logger, the modified code is shown below:
(Code using the CR Logger)
Let’s look at each of the CR.Logger calls as if we were calling VerifyGridColumnExists:
- Upon running, there is a binding call to CR.Logger that is performed, CR.Logger.Initialize() This call happens when the binding takes place, to give the log message the appropriate “Control” (Grid/Tree/Etc.)
- CR.Logger.SetAction(“exists”, “column”) lets the logger know which type of validation/action is being performed, and on what kind of item.
- CR.Logger.AddPrimaryLog(c.__getHeader().OleValue) tells the logger this is the primary value that we are looking to validate (there can be more than one). Note that this is the actual value that was found, not the supplied parameter.
- CR.Logger.Finalize() tells the Logger that the function has completed and to generate the log message based on what was added to the Logger Object.
- CR.Logger.SuccessOutput/ErrorOutput represent the generated Log messages based on the Logger object.
Here is the log that was generated:
The CR.Logger automatically generated the appropriate grammar and format for the developer and displayed the found value, rather than the input value. Whether a regular expression or not, it would be helpful to see found values over parameters, to ensure that the function is finding the right values. This allows us to keep the separation of function purposes as is standard for our code (A function that returns boolean, and one that logs the result from it.)
The CR.Logger also features a debug mode, where a developer can use 2 methods to log each item their script is finding.
- CR.Logger.AddDebugLog(Item, Value)
- This method will add a special log object to the logger than can be used for reference purposes.
- This method can be called at any time to create a Log Folder containing any Debug Log objects created. Note that Debug Logs will only be showed if this method is called, and would not be in the original output.
Keeping in Mind
- CR.Logger is built off of the “log grammar” that I created in this document: https://docs.google.com/document/d/1XeL-TvjTXheXdDJeQGLMsbxdI4xRcKZDZyLVgfRYQSw/edit?usp=sharing
- This means that it will support using “optional blocks” for more complex validations/actions
- CR.Logger Full documentation of it’s methods and ability can be found here:
- As with any framework, the needs and ability of this framework will need to be enhance. The source code for this framework is documented well, and clear to follow. While the logger is set up in an Object Oriented way, static methods are located at the beginning of the file so that Test Complete can recognize the different available functions and provide auto complete features for developers.
- CR.Logger can be used as a runtime object, or as a separate unit file that can be linked to in our existing files. If used as a USEUNIT, then the calls to the logger would just be Logger.<Method Call>