Test Meta Model of MGT

Part of series about my thesis project MGT.

This post is about to explain the meta-model upon which the test language is based. I will explain the different parts and the reasons for this design. The model is based upon the concept of keyword-driven testing.
It should be said, that I know that nothing of this is perfect. At the end of the post I’ll mention the most critical problems.

Let’s start with a image of the meta-model. The meta-model can be split into 3 parts. Classes of the upper left part describe the structure of tests. In the upper right part classes for test actions are located. And the lower part has classes to describe test data.

The first part is pretty simple. I took a common approach to structure tests. Starting point of any model in MGT is a TestSuite. It has a name and two other properties, which are used to state which system should be tested and which adapter is used. TestSuites may contain TestCases and Sequences, which both have a name as property and can contain several (Abstract-) TestSteps. Of course TestCases are exectuable Tests. Sequences can be used to group common TestSteps that occur more than once in the suite (e.g a login procedure).

The next part describes the different TestSteps (actions) that can be used. There are three classes that extend the AbstractTestStep. The first one, SequentialStep is used to call a Sequence. This can be seen as an import of the TestSteps that are stated in the Sequence. To perform an action in the system under test Keywords must be used. To keep the metamodel light and flexible the abstract concept of keyword-driven testing is used. The degree of abstraction is left to the user. You can hide a simple click or a complex workflow behind a keyword. Keywords can reference different test data, which are described below.
The last possible TestStep is an Assertion. This one should be known too. It always references a keyword, which represents the actual part upon which the assertion is called and it may have a second argument that represents the expected state.

The last part left is about TestData. As the image above shows there are two kinds of test data. The UIElementLocator should be used to access GUIElements in an abstract way. You just state the ID of the element you want to work with. How exactly the ID looks like depends on the Adapters again. It can be used to access an ObjectMap or be the exact ID of an Android UI element.
Other TestData objects are encapsulated behind the abstract class TestData. Its subclasses are just simple data types as integer, boolean or string.

So this already was everything. The meta-model is pretty simple and therefore lightweight. The problem about hiding keywords, IDs, and others is that the user may not know them. But as the Adapters provide those data, they can be provided by the tooling. Another post about the frameworks architecture will describe this in more detail. Another problem I see, is the lacking support of more complex data types. As I said Keywords can be used to execute complex workflows. But those may also have more complex data types as the provided ones. One way to solve this problem would be to provide a concept of DataProviders. I also opened a task a Github for this, but it has no priority for now.

Finally it’s left to say that anyone reading this is invited to discuss about my work. Questions and criticism are welcome.

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>