Start speaking your own language (GUI automation III)

Introduction

At this point we KNOW HOW TO AUTOMATE and we know HOW TO AUTOMATE TESTING. Still although the way the tests are created seems to be very flexible, their content remains unclear especially for non developers. They look more like a code and they may require extra documentation to clear them out. What should we do to make it easy to understand for every party in the project, and speed up writing the tests at the same time? The advantage is at this point we have a custom framework so we can improve it any way we wish. Let’s move towards behaviour driven development then.

Behaviour driven development

You can read more about it HERE. In general it means focusing on behaviour of the system by describing it with help of domain specific language (dsl) that is a language which is on one hand easy to understand for everyone because of its similiarity to English and on the other hand is tightly related to the application itself. The main advantages in practice are: improved overall communication (we don’t have to ask what business analyst had on his mind, nor what is the specific test doing), automation speed up (the behaviour described in domain specific language can be directly executable, which means just after it is created it can be run by QA engineer or tester), documentation improvement (we do not have to create aditional documentation as the described behaviour of the system becomes documentation itself).
As you can read in Wikipedia the popular template for the dsl are GIVEN, WHEN, THEN words. Thinking about it from a perspective of automation engineer one can say GIVEN may be considered as a setup, WHEN is a body of a test and THEN is a assertion. Let’s use it in practice!

Notepad specific language

For interacting with Notepad we need specific language. There is no such a language yet so let’s create Notepad Specific Language – NSL.
We need words which are related to Notepad GUI entities like document, tab, bookmark and actions like open, write, close. Let’s look at the example below:

So if we follow the pattern from Wikipedia, we can say:

It looks much better now, doesn’t it ?

Test report can also speak NSL

After the test is run we need to review results. Often happens we need to know what actions were taken at specific point in time. Let’s look at the test ouput we get when appropriate DSL logging is present.

As we can see not only the testcase itself becomes very clear but also the logging done in NSL level when analyzed with application logs allows mapping each action done on system test level to the sequence of events which take place on single service and class levels (component level) at the given point in time. Of course this is easy now to do the reverse thing and tweak logging a little bit to allow copy paste of log output to allow instant replay of the logged actions. So if we just change the logging messages a bit so that all of them are Java methods, we will be able to copy paste them and execute instantly. Consider this:

 

More about test report

This is nice thing we can see the test run log in NSL, but this is even better to have the screenshots. This is good test proof and very good way to see what went wrong in case test produce error instead of pass or fail, especially when it is hard to tell from application logs what is the reason. We are using custom framework so we can have screenshots anyway we like. Let’s do it then.

In this example screenshot is made in BDD layer of THEN class just before hamcrest based assertion is made. Screenshot information is added to the log messages. Screenshot itself is made by Sikuli method capture which is using java.awt.Robot under the hood. The class is one of the 3 main mechanisms which drive Sikuli as you can learn HERE.

As you can see in the example, there is parameter passed to the method which allows for capturing not only the full screen but also any region which is used by Sikuli. As for previous posts I share the code I was telling you about HERE under GUI_automation_part3 branch.

The movie goes here:

Summary

There are new nice things I presented you here. BDD aproach constitutes efficient solution for quality control. However, we can do more, we can do better. As usual… I will cover this in my next part about GUI automation.

Leave a Reply

Your email address will not be published. Required fields are marked *

*