In the practice of QA, regression and automation are a very strong practice to guarantee quality in a product. Usually automation (We are just talking about web automation by the moment) is done by a QA with scripts written in some language, using automation frameworks like Selenium, JUnit, NUnit, TestNG, etc.

DSL Test is an automation tool designed for QA and QA&V. DSL Test is a specific language designed to allow any QA person to write automated Test Suites with Test Cases.

DSL Test runs with a custom core based on Selenium that I built to automate web testing in a high level language, closest to the most readable, clean and easy to understand and write for any person.

Main point of DSL Test

DSL Test’s point is to push a natural language usage over testing practice. This natural language is also pushed to make usage of techniques like DRY and DAMP…
Do it DRY and DAMP!

Tests should be codeless and completely descriptive.
DRY stands for: «Don’t Repeat Yourself» with the idea of avoiding repeating code. Repeating code should be reusable code.
DAMP stands for: Descriptive And Meaningful Phrases with the idea that code should be constructed with very descriptive declarations and syntax.

DSL Test main point is to mix them both in a natural language to create descriptive code that really appears to not be code…

Structure of DSL Test

The structure of a DSL Test script is conformed by 3 elements:

• Test: This is the main test suite source. It is written in a .test file.
• Variables: Variables reference web elements and abstract them to a very readable and easy to use object. It is written in a .testv file.
• Methods: Methods are a human readable function that indicates what to do. It is written ins a .testm file

Let’s explain the DSL Test syntax.

Your syntax is built the next way:

HEADER
 PROPERTIES
 TEST SUITE

In the HEADER section we have the next useful lines:

• Engine: Sets the suite engine to use. By default is set to ‘Firefox’ if you don’t specify it. It can be one of the next options: { Edge, Chrome, Firefox, Safari, Opera, IE }. Syntax is:

  Engine IE

• Load from: This tells the suite where to find variables and methods for the context. Strictly files have to be .testv or .testm extension ended files. You can have as many of them as you wish. Syntax is:

  Load from <file>.[testv | testm]

 

In the PROPERTIES section by the moment just one instruction exists. It can be written INSIDE, BEFORE or at the END of the HEADER section. Properties are global and are set after the HEADER runs.

Timeout: This sets the default timeout for timerized and waitable functions of the test. It can be written anywhere before, after or inside the header section. Syntax is Timeout <MILLISECONDS>:

Timeout 3000

 

In the TEST SUITE section we write tests. We only have a one instruction for the TEST SUITE. You can have as many Tests as you which.

• Test: Here the tests are written. Syntax of tests is:

  Test NAME OR DESCRIPTION OF TEST
     Test Body
  EndTest
  
  Test ANOTHER TEST NAME OR DESCRIPTION
     Test Body
  EndTest

 

Let’s see and example:

*HackMTY Facebook Demo*
Engine Chrome
Timeout 4000
load from fb_variables.testv
Load from fb_methods.testm

#Test Facebook page loads correctly
 Goto Facebook homepage
 Assert Title has Facebook
EndTest

#Test User can login to Facebook
 Requires Facebook page loads correctly
 Do Facebook Login
 Do Assertion user logged in to Facebook
EndTest

#Test User log in and views home and profile
 Requires User can login to Facebook
 Do Assertion facebook home loads correctly
 Goto User profile
 Do Assertion user profile loads correctly
EndTest

Test User can post in wall
 Requires User log in and views home and profile
 Do Post in wall
 Do Check post was succesfully published in wall 
 SaveScreenshot C:\FacebookTest\Screenshots\profile_published.png
EndTest

Test User can delete a post
 Do Open post menu options
 SaveScreenshot C:\FacebookTest\Screenshots\profile_deleted.png
EndTest

*This section is code comments*
*This is an alternative to the above procedure*
*All depends on methodology and QA development*
*Test may have previous requirements which are other tests*
*But it can also be a single test that does all this in multiple steps*
*Test User can post a picture in wall*
 *Goto Facebook homepage*
 *Do Facebook login* 
*EndTest*

 

Noticed the ‘#’ symbol in some test?
# defines a test to be ‘Required’. As you read in the comments in the above script, requirements vary according to methodologies and QA development. Some test may need to execute a previous requirement before executing the main test.

Now, how does DSL Test know how to ‘Goto Facebook homepage’?
Simple: It’s a descriptive method. Let’s take a look at the script header:

Engine Chrome 
Timeout 4000 
load from fb_variables.testv 
Load from fb_methods.testm

Guess you figured it out: ‘Load from fb_methods.testm’ and ‘Load from fb_variables.testv’.
Let’s take a look at these files:

fb_methods.testm:

Facebook homepage
{
 Browse http://wwww.facebook.com
}

Facebook Login
{
 Type hackmty.dsl@gmail.com in FacebookUserTextBox
 Type hackmty2017 in FacebookPasswordTextBox
 LeftClick FacebookLogInButton
 Wait
 LeftClick FacebookNotificationsPopup
 Wait
}

Assertion user logged in to Facebook
{
 LeftClick FacebookHomeButton
 Assert FacebookHomeButton.Text has 0
}

Assertion facebook home loads correctly
{
 Wait
 Assert FacebookHomePostDefaultText.Title has Qué estás pensando
}

User profile
{
 LeftClick FacebookProfileButton
}

Assertion user profile loads correctly
{
 Wait
 Assert FacebookEditProfileButton.Text has Editar perfil
}

Post in wall
{
 *LeftClick FacebookStatusBox*
 *Wait*
 *FACEBOOK I HATE U!*
 *UR SO DYNAMIC!!!*
 *U MADE OUR NIGHT A NIGHTMARE*

Type #HackMTY2017 ;) in FacebookStatusBox
 LeftClick FacebookKittyColor
 Wait 2000
 LeftClick FacebookPostInWallButton
 Wait
}

Check post was succesfully published in wall
{ 
 Assert Page has HackMTY2017
 Wait
}

Open post menu options
{
 LeftClick PostMenu
 Wait
 LeftClick PostDeleteOption
 Wait
 LeftClick PostDeleteButtonConfirm
 Wait
}

As you can see, methods are defined as a descriptive definition of instructions. Even inside instructions of a method are fully descriptive… But you may have noticed another thing… How does DSL Test know how to execute this: ‘Type hackmty.dsl@gmail.com in FacebookUserTextBox’? Well, let’s take a look at the next file.

fb_variables.testv:

FacebookUserTextBox id: email
FacebookPasswordTextBox id: pass
FacebookLogInButton xpath: //input[@type='submit' and @data-testid='royal_login_button']

FacebookNotificationsPopup xpath: //a[@role='button' and @action='cancel']

FacebookHomeButton id: u_0_c
FacebookHomePostDefaultText name: xhpc_message
FacebookProfileButton xpath: //a[@title='Perfil']
FacebookEditProfileButton xpath: //a[@ajaxify='/profile/edit/public/show/']

FacebookProfilePostDefaultText name: xhpc_message_text

FacebookStatusBox xpath: //textarea[contains(@placeholder, 'Qué estás pensando')]
FacebookPostInWallButton xpath: //button[@class='_1mf7 _4jy0 _4jy3 _4jy1 _51sy selected _42ft' and @value='1' and @type='submit']
FacebookKittyColor xpath: //td[@class='_51m-'][7]

PostMenu xpath: //a[@data-testid='post_chevron_button' and @aria-label='Opciones de la historia']
PostDeleteOption xpath: //span[@class='_54nh' and contains(., 'Eliminar')]
PostDeleteButtonConfirm xpath: //button[@class='_42ft _4jy0 layerConfirm uiOverlayButton _4jy3 _4jy1 selected _51sy']

This is how DSL Test structure works…

In conclusion, the only thing you need to know for making a Test Suite automate itself is: Know how to find HTML/DOM elements… Simple because you find them by something that ‘defines’, ‘describes’ them… It can be by:

• id: htmlElementID
• name: htmlElementName
• link: htmlTagAText (For example, <a>Text</a> is found by ‘link: Text’)
• css: htmlCssSelector (For example, by css class derivation: css: .classA .classB .classC)
• class: htmlClassAttriute
• plink: htmlTagAPartialText (For example, <a>Link Text A</a> is found by ‘link: Link Te’)
• xpath: xmlXpathExpression (Any xpath expression that describes this element)

I think DSL Test is well designed to describe web elements, functions and declaration. What you think? Is the above test a very descriptive Test Case with Test Steps? Is it human readable? A Natural Language?

<<This document was updated at [12:16]-24/07/2018>>