Ask Reuben

Testing Tools

What testings tools can I use with Genero ? 

Why is this testing tool not working with Genero ?

What is Genero Ghost Client ?

Is testing tool ??? supported / compatible with Genero ?

On the support desk, we get asked questions about testing tools.  Taking Selenium as an example, that question might be “Is Selenium supported by Genero?”.  The word “support” is being misused here,  we support our products.  The better wording might be ‘Is Selenium compatible with Genero”, or “Does Genero work with Selenium?”.

Genero works with a number of testing tools but you should understand how they work and where they fit in around our architecture.


Genero Ghost Client

The Genero Ghost Client (GGC) is the name of the testing tool designed to work with Genero applications.  In an earlier Ask Reuben I gave a guide as to how to start out with GGC.

The key point to understand with Ghost Client is the architecture,  how it tests and what it means for the result of your tests.  Within our architecture, the Ghost Client acts as the front-end, in lieu of the Desktop or Browser client.  It can be used to test that the nodes in the AUI Tree have particular attributes and values, as well as sending actions and data entry to the back end. For example, it can tell us that for the field named “foo”, the value attribute has value “bar” and that the style attribute has value “important”.  It does not tell us that “bar” is displayed in red at pixel 100×200 with a font size of 10px.

For the most part testing the AUI Tree like the Ghost Client does is sufficient.  It allows you to simulate an end user and run Genero applications and capture the  results of the business logic.

Other testing tools put their capture point closer to what is displayed to the screen.


Testing Native Genero Desktop Client (GDC) Applications

As you are hopefully aware, Native GDC applications use something called the Qt libraries.  The way that applications written using the Qt libraries are rendered to screen, often means that conventional desktop application testing tools can not interrogate these windows.    As a result, in order  to test Qt applications, a number of testing tools designed to work with Qt applications entered the market.  One of these was Squish  which was eventually acquired by Qt and is now found on Qt sites.

These testing tools inspect the Qt library calls and test what these calls are writing to the screen.


Testing Web Genero Browser Client (GBC) Applications

The Genero Browser Client uses a mix of html, css, js like any other web application.   In principal any testing tool that is designed for web applications can be used to test Genero Browser Client applications running in a browser.  A popular choice is Selenium that we also use internally.

There are two things that catch testers out and it mainly arises from the fact that the testers are not developers themselves…

Genero web applications are single page applications.  The URLs that are on the form /ua/sua are not distinct web pages but are requests from the front-end that submit what the user is doing.  The /ua/sua URL seen will have additional detail such as  /ua/sua/SESSIONID?…=&appId=APPID&pageId=PAGEID.   The SESSIOND is a 32 digit hexadecimal number that is unique per session and is randomly generated.  APPID is a number that increments for each application in the session.  PAGEID is a number that increments with each interaction from the front-end.   None of these will be the same from the run of one application to the next.  It is wrong to link this URL to a particular web page.

The id attribute of individual  HTML elements should not be used to uniquely identify a data value that you maybe testing.  The id attribute is used for internal purposes by the Genero Browser Client and is not guaranteed to stay  constant.  A better technique is to use the data-aui-name attribute as that has the name given to the field by the 4gl developer.  In this snippet below, you will see that id=”w_493″ whilst data-aui-name=”formonly.r1″…


<div class="mt-field gbc_dataContentPlaceholder gbc_WidgetBase gbc_EditWidget w_493 g_measureable gbc_WidgetBase_standalone gbc_staticMeasure aui__89 gbc_Focus" __widgetbase="" __editwidget="" id="w_493" data-aui-id="89" data-aui-name="formonly.r1" aria-selected="true">
  <input type="text" class="gbc-label-text-container" autocomplete="new-password" __widgetbase="" __editwidget="" size="25" inputmode="numeric" maxlength="26">
...

… the formonly.r1 is the name given to the field by the 4gl developer, this will only change if the developer changes the names of the field.  The id=”w_493″, and also the data-aui-id=”89″ attribute values may change if the developer makes changes elsewhere i.e adding or removing a field from the form, adding or removing a style attrihute from the .4st etc, and cannot be relied upto to be preserved.

When using web based testing tools, it pays to have a 4gl developer working closely with the person using the testing tool.


Screen Based Testing Tools

There are or used to be testing tools that took screenshots of the screen and undertook pixel by pixel comparisons.  You want to stay away from these.  There are not very robust,  take for example a widget that has SIZEPOLICY=DYNAMIC that stretches, anything that makes the widget stretch will invalidate the tests.  These tools have their place but it is not testing that the results of business logic are unchanged.


Tool Independent Questions

No matter what testing tool is in use, I like to pose the following questions to make you think…

What is the state of the data in the test database for any given test? 

If you keep using the same customer and product to test sales, are you going to run out of stock for that product?, is the customer going to run out of credit?  How will the program respond then?

Are you testing absolute or relative values? 

Do you write your test to expect a balance of $100 at the end of the test, or do you write your test to have a closing balance $20 less than the opening balance ?  The second type of test allows you to be more flexible with the state of the database at the beginning of the test

Do you test against the database or against an application?

Do you test the closing balance by executing a SQL against the database? or do you run the application that shows balances and look at the value displayed in the application ?

Have you disabled functionality you don’t need or want executing in tests ?

An example I like to give is automated emails or printing.  Chances are you don’t want these to occur as you run a test, so what precautions do you have in place to prevent that?

How often do you run each test?

It makes sense to test important programs more often.    So what you may end up with is a suite of tests where some are run daily overnight, but others are run once a week or once a month.