Ubiquitous Language

Description

The notion of "ubiquitous language" is the same language found everywhere. It is presented in the description of "Domain Driven Design" [Vernon 2016] [Moustier 2020]. It corresponds to the same language that is shared by all the actors in the same context at the level of :

• business
• technical
• testing

‍

‍

This unity in terms and expressions allows communication between all the actors in the context, a bit like the people of the same country called "Bounded Context" in DDD jargon.

Thus, this Domain Specific Language (DSL).

Application to test maturity

The ubiquitous language enables unity and communication between the business and the technical side, which brings the technical side even closer to the business side.

Furthermore, when tests are consistent with the ubiquitous language, everyone can understand them and participate in involving everyone in the quality of the product.

A direct application of the ubiquitous language is Behaviour-Driven Development (BDD), which can be found in the description of User Stories (US) and the related acceptance criteria:

●       US:

        ○       AS a customer

        ○       I NEED to be able to fill my shopping cart

       ○       IN ORDER TO make purchases

●    Scenario 1:

        ○    GIVEN the customer is "Albert".

        ○    WHEN "Albert" adds the item "Carambar" to the basket

        ○    AND the "quantity" is "3

        ○    THEN the cart contains "3" "Carambar".

●    Scenario 2:

        ○    GIVEN the customer is "Albert".

        ○    WHEN "Albert" adds the item "Carambar" to the basket

        ○    AND the "quantity" is "3

        ○    AND "4" "Carambar" are deleted from the cart

        ○    THEN the error message "You cannot delete more than 3 Carambars" is displayed

        ○    AND the basket is empty

Expressions such as the Gherkin language [Wynne 2012] and the business actions and terms used in this example must be retrievable from the US, the tests (which can be interpreted by the Cucumber tool) but also in the architecture and the code in order to facilitate :

• the understanding the need
• the recognition of the technical parts
• the purpose of the test
  ‍

by all the stakeholders in the field and thus facilitate the "T-Shape" state of mind.

Agilitest's position on this practice

In order to reflect the DSL in test scripts, scenarios can be broken down according to domain expressions. Thus, when the Gherkin language is used to materialise the BDD, it is good practice to split the test case by creating GIVEN, WHEN and THEN blocks as the Cucumber compiler does, creating three functions named after the text following the GIVEN/WHEN/THEN keywords. Thus, based on the example of scenario 1 shown above, one could create three sub-scripts named :

• the_client_is_Albert
• Albert_add_the_article_Carambar_to_the_basket_and_that_the_quantity_is_3
• the_basket_contains_3_Carambar

‍

To discover the whole set of practices, click here.

‍