Creating your own DSL with XText (Part III - meta layer)

In this part we'll deal with the meta layer (HTML strucure) of the project.

We'll start with defining the structure of the HTML elements we want to use. The reasoning behind this that I want to keep the structure dynamic rather than compiling it into the plugin. The model must be able to derive whatever it needs to identify the element in the DOM tree from the meta layer.

It is easier to start at the bottom of the XText file, and work our way up.  
HTML has a couple of different input fields, for the sake of shortness I'll only model textfield , option and checkbox (enum FieldType). I could have added buttons but they are not data entry fields so they get their own rule. In HTML, you have a couple of ways to get to an element. Again, I only model what I am gonna use (enum ElementType).
So, in order to describe how an element will be identified the rule 'ElementDefintion' will take any string, followed by a colon and an ElementType (e.g. "loginElement" : ID).
Then we have two rules, one for data entry fields (Field) and buttons (Button).
As we might have different environments where we need to execute our tests we define a LoginUrl (name will be the placeholder for the actual url), which is used in the rule Login.
A Form is a container that groups of set of fields and button. Kindly note that buttons have to be modelled first if so, followed by the data entry fields. 
Last but not least we then model the Menu, which may contain nested menues. That leaves three top elements, menues, forms and logins (to be precise menues OR forms) OR logins).

In the next part we'll model the actual test DSL, referencing this meta model. But you can already test this DSL. Just hover over the project, right-click and select "Run as" -> Eclipse application. In the new Eclipse instance, create a new project and when you are finished, create a new file with the relevant extension (in my case .define). This will activate the DSL editor with code completion.

<< PART II

Creating your own DSL with XText (Part II - project structure)

In part II we'll now have a look at the project structure. Here it goes:

There are three main sections.

Features the bundles you'll need for Eclipse

Plugins the actual code, XText-structured. I'll be using two DSL's, one for modelling the application strcuture, such as menus, forms/pages and page content such as fields, select boxes, check boxes etc. The second DSL models the actual test actions, such as login, enter "text" in field ABC etc. 
The plugins also includes the shared dependencies. Since Eclipse runs in an OSGi container (Equinox) all dependencies need to be packaged as OSGi bundles. So a word of advice: try to minimize your dependencies as the maintenance of the MANIFEST for the dependencies can become quite hectic otherwise.

Releases the p2 Eclipse structure that you'll need to use the Eclipse update manager

The project will have a parent pom that defines the skeleton structure, the dependencies, plugins, repositories etc.

As the DSL is to be used with Selenium we can pick any web application. Let's have a look at the Vaadin QuickTickets application. It has a login page and some forms/pages, good enough for our purpose.

In the next post we'll dive into the structure model and the test model.

<< Part I                                               PART III >>                     

Creating your own DSL with XText (Part I - Intro and tools)

Hi,

Since a lot of people have been asking me how to use your XText DSL project to publish your artefacts to be used via the Eclipse update manager I decided to outline the structure of the project in a couple of posts. 

I am not gonna explain how XText works, nor will I give an in-depth explanation of any of the other tools used. You should be somewhat familiar with the frameworks mentioned. In addition, for the packaging you should be familiar with the concepts of OSGi, as the final result will be assembled as "bundles".

A word about me: My name is Sebastian, I am a professional software developer living in Cape Town, South Africa. I was born and raised in Germany, decided to move to this side of the world 5 years ago.

So, what tools do we need? 

1) First and foremost you need Eclipse as an IDE.

2) XText. You can either install XText as an update in your existing Eclipse or download a fully integrated version (-> http://www.eclipse.org/Xtext/download.html)

3) Maven, with a couple of plugins...later more. The tycho plugin allows to package the artefacts so they can be installed via the Eclipse update manager.

Those are the basics, the non-negotiables...everything below are tools I like to use but those can easily be replaced or even removed.

4) Since the purpose of my DSL was to browser-test a third-party application which we are configuring for our clients, Selenium. Selenium is fantastic to do cross-browser testing, it provides an IDE which is in fact a plugin into Firefox; it also allows you to connect several clients to Selenium-Grid to load-test and multi-browser test your application.

The CI server we use, Jenkins, has a Selenium grid plugin so your CI server also acts a Selenium-Grid server...but that's not part of this blog.

5) Scala and Scalatest. I cannot imagine developing software without Scala anymore, and Scalatest already provides a simplified DSL to interact with Selenium.

6) TestNG. I personally prefer TestNG to JUnit, due to various reasons - in this project however I simply chose TestNG because of the nice reports one can produce in combination with ReportNG.

Thats's about it...we are ready to start. Needless to say all of the frameworks mentioned above nicely integrate with Eclipse and are open-source!

  

The project - what do we want to achieve

The objective of my project was to allow a non-technical person (in my case testers) to write tests that can be executed automatically, without the person having to know any of the tools mentioned above. A prospective tool had to be easy to use, the setup as simple as possible. Thus XText, packaged as an Eclipse plugin was the obvious choice with Eclipse's support of code completion, on-the-fly validation and mouse-hover support to show pop-ups with help/documentation. The hover support turned out to be the most difficult part of the exercise as I wanted hover support for the keywords and not only for the modeled variables. 

A test should ideally look something like this:

Login with "<username>", "<password>" into <URL>  

Click menu-item "<Open Form ABC>"

Enter "<1980-05-12>" in DateOfBirth  

Enter "<Smith>" in Lastname

Tick  NewContact

In the above sample the words in dark purple indicate code-completion; i.e. the user simply has to press <Ctrl><Space> in Eclipse and can then select from a list. There is not much to type, is there? In addition, I modelled my DSL so you have to start with login, put in a little regex to show a warning if an incorrect date is entered, and show an error when you try to enter text/strings in a date field. So, that's the objective. In the next post I start with the skeleton maven project.

 

 >> Part II - project structure >>