A How To Guide on Readable Test Logs using TestComplete

A few months ago, I responded to a message about how to make the TestComplete Log readable. I gave a brief explanation of what I do on my projects to make it so that the output is readable. From that simple explanation, I received a significant number of replies requesting additional information and more detail of what it is that I do to make the log readable. I decided that it would be a good idea to write this up as a Guest blog post to share with the SmartBear community.

This methodology that I am about to explain is not for everyone, and not for every test. However, I feel that if you write most of your tests this way as often as possible, then your code base will be much more maintainable and cost you much less time over the long run. So… if your tests are going to be around for a long time, this methodology is great. If you are writing tests that will last only a short while, then this might not be how you should do it.

For the demo today, I decided to do a simple demo, using the calculator. The code I will be showing is JScript. However, this method will work regardless of your chosen scripting language.

To start, create a new project and add Calc (c:windowssystem32calc.exe) as a Tested App. Create a new script unit, and call it Unit1. Open the Calculator. Now, click Record Script (not Record Keyword Test). While recording, click on the calc buttons “2”, “x”, “5”, and “=”, then stop recording. Your test code will look like this:

function Test1()

{

var page32770;

page32770 = Aliases.calc.wndCalculator.CalcFrame.page32770;

page32770.btn.ClickButton();

page32770.btn1.ClickButton();

page32770.btn2.ClickButton();

page32770.btn3.ClickButton();

}

Now, let’s play this code back and look at the log, and see what it looks like. Let’s see if we can tell what is happening based on the log. So, right click the method and say Run Current Routine. This is what you get:

From this log, I can tell that a button was clicked. And that there was a click performed four times. I don’t know which button was clicked, and I don’t know if only one button was clicked, or if it was four different buttons. I can only see low lever OS indicators about clicking and buttons. Now, for me, this log is worthless. I can’t tell what is happening. If I were to get a failure here, I wouldn’t understand what the failure was on. What I want to do is explain a simple way to make this test log readable. This method will have a few perks to it:

  1. First, you will also be able to set the message in the TestComplete indicator (the little bubble that appears during play back) so that anyone watching the tests execute will also be able to read what is happening.
  2. Second, you will be forced to encapsulate your code. Encapsulation is a very important piece of coding. Encapsulation is what will allow you to increase the maintainability of your code. What is encapsulation? It is writing small, short methods that perform a small number of actions. Preferably only one. For my demo here, my methods will each only be performing one action, as opposed to having one method perform many actions (like when you do a simple record and play back).

Before we can write our new clicking methods that will replace our current method that we just created, I need to write a few new methods. So, let’s create a new unit, and call it MyLog. Inside MyLog, create the following two methods:

function begin(stepDescription){

Log.AppendFolder(stepDescription);

Indicator.PushText(stepDescription);

}

function end(){

Indicator.PopText();

Log.PopLogFolder();

}

Additionally, add the following line of code to the top of your Unit1:

//USEUNIT MyLog

These two methods are our custom logging methods. We will call MyLog.begin() at the beginning of each of our methods, and MyLog.end() at the end of each of our methods. You can see that MyLog.begin() needs to be passed a variable. This variable needs to be a String (a sentence that begins and ends with quotes). This String is what you will see in the log. This may not make sense right now, so let’s move onto the next step so that you can see it in action.

Now, in our Unit1, let’s create four new methods: one for each of the buttons in our simple equation.

  • Record, then click 2, then stop recording.
  • Record, then click *, then stop recording.
  • Record, then click 5, then stop recording.
  • Record, then click =, then stop recording.

You will have the following methods in your Unit1:

function Test2()

{

Aliases.calc.wndCalculator.CalcFrame.page32770.btn.ClickButton();

}

function Test3()

{

Aliases.calc.wndCalculator.CalcFrame.page32770.btn1.ClickButton();

}

function Test4()

{

Aliases.calc.wndCalculator.CalcFrame.page32770.btn2.ClickButton();

}

function Test5()

{

Aliases.calc.wndCalculator.CalcFrame.page32770.btn3.ClickButton();

}

I am going to rename the methods and add our customer loggers. Now the above four methods will look like this:

function click2()

{

MyLog.begin("Clicking 2");

Aliases.calc.wndCalculator.CalcFrame.page32770.btn.ClickButton();

MyLog.end();

}

function clickMultiply()

{

MyLog.begin("Clicking *");

Aliases.calc.wndCalculator.CalcFrame.page32770.btn1.ClickButton();

MyLog.end();

}

function click5()

{

MyLog.begin("Clicking 5");

Aliases.calc.wndCalculator.CalcFrame.page32770.btn2.ClickButton();

MyLog.end();

}

function clickEquals()

{

MyLog.begin("Clicking =");

Aliases.calc.wndCalculator.CalcFrame.page32770.btn3.ClickButton();

MyLog.end();

}

What I have done is begin and end each method with our logging methods. While this may seem tedious, I do this on all of my tests. The log is very readable, the code is very maintainable. If I ever need to click the number “2” again, I don’t need to record that again. You already have a method to do it for you. If you are encapsulating all of your functions this way, so that they are short scripts that only perform one action, then you will have highly maintainable code.

Now, let’s modify our Test1() function that we created at the beginning, and make it use our new methods to perform the same equation with the calc. It should look like this:

function Test1()

{

TestedApps.calc.Run();

click2();

clickMultiply();

click5();

clickEquals();

}

Now run that new Test1 and look at the log. It is readable. If you had an error in there, the error would appear inside your custom log, and you would know the exact step that had the error.

For me, this is a clean log. It is something that you can read, and if you need to click on the Plus sign next to one of the log entries, you can see the raw log message there.

For the most effective use of this methodology, you should separate your units into two different kinds of units: Library units, that only contain functions that perform actions, and Test units, that don’t perform any actions in themselves, but call all of the different library methods that DO perform the functions. I will write this up in a separate blog post, as it is a separate topic all together.


Close

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox

By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading