Tag / DSL

by Grzegorz

Groovy – universal scripting tool

I recently had a need of create some script in Windows environment. I knew about Groovy for some time so I decided to try it. In my opinion this is very strong alternative for Python and for Perl. Because of the fact it uses Java virtual machine, it can be easily launched on every platform where Java is supported. It may also be merged with Java classes so any code you have there somewhere can be used in Groovy script. But this is not all. The very interesting features I would like to show in this post are: ability to create nice domain specific language, handling of XML files (and other form of storing the data) and handling GUI interfaces via Swing library.

Domain specific language

I have already spoke few words about DSL HERE. Groovy has a nice ability to easily create your own language.

This application does… well I do not have to describe what it does – it is self explanatory:

The output of this application is:

It is not only the domain language we can construct but also short code inside. There are 4 files there and let me just show you filtering functionality for files:

You can see the full code HERE.

 

XML handling

This is the best and easiest way to process XML I have seen so far. I extend the functionality of the previous application so that it opens config.model.xml file (which is part of Notepad++ distribution) and then displays GUIconfig element’s attributes. Take a look, we have DSL part:

The output:

And the internals:

 

And that’s it. Finally there is an easy way of processing XML files. This is very frequent task to deal with such a format data is stored…

In line 8 file is parsed into variable which has the name as the root node of the XML document. Then, in line 10, one uses child element’s names to build a path. After iterating with “each” keyword we assert @name attribute and if it matches we iterate over attributes. Short, simple and clear.

It is important to mention,
there is the same way of working with JSON

(and that was a short poetry, did you notice?)

The full code is HERE.

And XML file I was using looks like this:

 

GUI

This is also easy to create simple GUI interface to have more rich tool by your hand. In this example I create a small application which will show the values for given elements and all its attributes. This also have auto completion/suggestion feature for more friendly user interface. The default behaviour is to open config.model.xml file and find all attributes of GUIConfigs.GUIConfig element with specific “name” attribute. File path, element path and attribute name are customizable.

The whole application is only in 1 file, so if you copy paste you could run it immediately:

The first part is the logic:

  • buildNodePath builds a node path out of user input; this shows how to navigate through xml document when user is to provide node names during runtime
  • quickList displays the attributes which match string entered by user (“App” will show //GUIConfigs/GUIConfig[@name=”AppPosition”] is available and when confirmed it will display the value and all the attributes of //GUIConfigs/GUIConfig element)
  • autoComplete populates dropdown
  • getAttributeSummaryOfElement displays all attributes and the value of the given element

The second part is the layout done by Swing in Groovy. There is very clear way of positioning items on the screen by using html like trs and tds.

You can view the code HERE.

The screenshot of the application (wordpad on the right side):

XML_explorer

The movie which shows the runtime:

Nice tool

This is nice tool worth reading about it more. There are small drawbacks from my point of view especially when mixing things with Java code. I often find myself writing some Javish Groovy or Groovish Java… still this is clearly an advantage as you can append existing Java code to your script. I think I like XML/JSON processing most, this is extremly useful. I also am impressed by details like this one:

It gives “c” in the output. Isn’t the simplicity impressing in Groovy ?

 

by Grzegorz

Statewise testing (GUI automation part IV)

Introduction

You must have heard about state transition tables. This is great test design technique to let us achieve the right coverage when testing with GUI application. We analyze the application from its states perspective to be able to adjust the coverage we can achieve according to resources we have available. In this part about GUI automation I will show how easy we can adapt the testing framework to use it.

Details

We have a framework at this point available which has a DSL layer and it looks very nice (as shown HERE). What we can test at this point (from test design technique point of view) is actually one test case decision table like this:

action TC 1
GIVEN().tab().isOpened(). X
WHEN().tab().isWritten(text). text = “text1”
AND().tab().contentIsCopied(). X
THEN().clipboardContent().shouldBe(equalTo(text)); X

However we need to be able to look on the application from state transition point of view, to be able to act basing on the state transition diagram. We would like to have an automation which can execute state transition diagram by walking the paths we choose.

Let’s look at the example of one – it focuses on the feature LTR/RTL which is text direction left to right and vice versa in Notepad++.

text direction feature in Notepad

text direction feature in Notepad

State transition diagram with text direction focus

State transition diagram with text direction focus

As you can see there is one main state which is one tab selection in Notepad++ (there is always some tab selected). There are also 2 substates which indicate if RTL or LTR is used. So it means when we start using the application we always start with 1 tab selected and LTR text direction.  Then, we can change the text direction or do any other transitions like createNewTab, selectTab or deleteTab. I do not want to write here all the state transition diagram details (I hope to create separate post on test design techniques some day) – let’s only say the basic coverage for this technique should be to execute each state and each transition at least once.
We would like to be able to transform this diagram into Java code and introduce one extra layer on top of we already have in the Sikuli testing framework and then run it.

Let’s do it!

Every of 3 states will be represented as separate class in Java:

Now we can navigate through the state transition diagram using IntelliJ suggestions and we can make any path we wish. As the result we can adjust the coverage to our needs.
The example test case based on the state transition diagram looks like this:

What we test here is we navigate through all the states and transitions at least once and at some point we execute assertTabIsWritable. By doing so, we test if the tab currently selected in the test flow is writable or not. Under the hood we use here Sikuli based testing framework which is described in previous posts.

As you can see we are using the existing framework to check if tab is writable. We are focusing only on this feature. We of course could be checking much more: like when executing createNewTab we could be checking if extra tab was created etc. but I skipped it for simplicity sake.

The video goes here:

You may also view the source code which is
HERE under GUI_automation_part4 branch.

Summary

This is just an example of the automation of tests which are basing on state transition diagram. The power of this approach is related to this test design technique. Firstly, if a requirement is described in this way we are ready for automatic testing. Secondly, in my opinion when such a diagrams which decribe specific funcionality exist in the project, it is possible to use them for example for purpose of retesting. If there is a new feature F1 in functionality A1 it is possible to have automated test for the A1 functionality by executing its state transition diagrams to check if nothing is spoiled there by F1.

The great GUI automation summary

So this would be all I wanted to present about GUI automation. This framework in my opinion is extremely flexible. This could be used for any application – not only GUI. This is just a matter of substitution of Sikuli with other thing like some web service self made framework for testing web service application. One could simplify it from programmatic point of view, one could add tests which would be testing framework itself (unit tests), or else improve the DSL layer. Still even such simple version is usable and shows the potential.
I hope that now the tank comparison from the 1. part (HERE) is more clear 🙂

by Grzegorz

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.