Select Page

Component tests, automatic and applying BDD

Ensuring the quality of the components of a software product are big words. We tell you in this article how we have solved this challenge with the Component Tests, executing everything automatically, starting from the continuous integration of the process and including the control of the third-party software involved.

The first questions that may arise reading the title I imagine they will be ...BDD? And because? We will start the journey here, though If you are already familiar with BDD, you can advance to the section in which we break down how we approach the Component Tests.

BDD we said. Well, you see, they are the acronyms of "Behavior Driven Development"That is, behavior-directed development, which is an evolution of TDD or" Test Driven Development”, Of which we have already spoken to you on some occasion, as in 5 basic questions in automatic tests.

Possibly with the name you have stayed as at the beginning, so I am going to tell you some more details: BDD was born from the hand of Dan North thanks to its need to test 'behaviors' through the tests he did. Let's say that the concept of "test" fell short, and you found that if you described the behaviors you wanted to reproduce with the tests, it was much clearer for future developers what you were trying to check and what happened in the event that something went wrong. .

BDD is an agile methodology, which applies to the entire software development process. The tests become 'scenarios' or 'behaviors', described in a natural language that can be easily interpreted by everyone, from the business side to the developers.

The language most used by most frameworks (“frameworks" how jBehave, Cucumber, Behave…) From BDD is Gherkin , which establishes a series of keywords (mainly, Screenwriting to describe the behavior to be tested, Given where the context is set, When to specify the event that triggers the behavior, and Then explaining the expected consequences) and format rules through which we can describe the scenarios.

The process to follow in BDD begins with the creation of a user story, which, as we already know, should be given by the format:

      • I [functionality]
      • As a [role]
      • For [benefit]

And that is where all the requirements to be met appear. Once we have it defined, it would be time to establish a series of criteria of acceptance through different scenarios using Gherkin. All these scenarios related to the same user story will be grouped in a file that we will call "feature". a very illustrative example would:

 

Component Tests

Now that we have an idea of ​​what BDD is for, let's tell a little what's that about component testing.

These types of tests are in charge of verifying the correct functioning of a software component, as for example it could be a Java process. For this, it would be our responsibility to address the following questions:

      1. Modify configuration files that the component reads at startup, adapting them to our needs and / or scenarios.
      2. Inject the precise data in the databases (Oracle, MongoDB, etc.).
      3. Prepare the "mocks" (simulators) that interact with the component in each scenario, to send and / or receive the necessary messages.
      4. Start and stop the process Java at will.

In addition to all this, we will also have to have installed in each machine the 3rd party that the process may need, and as icing on the cake, everything should run automatically, also ensuring continuous process integration.

Scheme of components involved - Component Tests

Scheme of components involved

In our case, to meet this demanding tangle of 'requirements', the technological solutions we opted for were:

behavior: It is the framework (“framework”) Of BDD that we use, it is programmed in Python and is in charge of managing all the mocks that we have developed, the clients for accessing the data of the 3rdparties, And of course, you have total control of the execution of all our tests.

openstack: It enables us an Infrastructure as a Service (IAAS) to create the necessary virtual machines to be able to launch component tests independent of each other. In this way, if we have 5 machines configured we can parallelize the execution of 5 Features different at the same time (one for each machine) with the consequent optimization of time. Also by using Openstack, we make sure that all our machines share the same software and operating system settings.

Docker: We bet on having “dockerized" each 3rd party that our component uses, as well as databases and the component itself. This solution is much more flexible for us than statically installing each of the 3rd party, and also allows us to reset the environment to a starting point, update components easily, and saves us time in configuring each one of them.

Jenkins: Well-known tool that simplifies continuous integration and makes life easier by allowing us to create "jobs"To launch each of the"Features”That we have designed. In this way, each feature (remember that they were 'spun' with user stories) can be run autonomously and independently.

In addition, Jenkins gives us the opportunity to automatically launch our tests with nocturnal and treacherousness, applying the following pattern:

      1. Build docker image of the component.
      2. Delete all docker images & containers from all Openstack machines.
      3. Create an image of the component to be tested from the GIT branch with the source code in question.
      4. Download the latest images from the 3rd parties (Oracle, MongoDB, Redis, etc ..).
      5. Run automatic tests.

We are going to finish with an example that illustrates all this that we have explained to you. To do this, based on the previous component scheme, if we wanted to test the Front End process we would have:

Scheme of components involved - Component Tests

Scheme for the automatic testing of the Front End Component

 

In short, the performance achieved with this test architecture based on Component Tests has been much higher than that corresponding to other more 'traditional' (and manual!) models. The times required to ensure software quality (QA) and the detection of incidents have been significantly improved, not only in new developments but also in regressive tests. By using BDD everyone involved, both business and technology, has expressed that it has improved their understanding of the scope of testing. And in particular, new test techs have proven productive in days versus weeks before introducing BDD.

If you are interested in more detail about the performance obtained, the main barriers encountered or how we manage to keep the process up to date, we encourage you to send us your questions in the comments of the article.

 

Fernando Casal

Fernando Casal

Fernando Casal is a QA Engineer in Panel Sistemas. You can visit his profile at Analysis, or contact him via e-mail at this address.

Leave us your comment

1 Comment

  1. Michael Angel Nicolao

    Intresting job! !! Congratulations!!
    Since you insist ... I accept the invitation:
    Can you tell us more about the barriers encountered?

    Thanks Fernando?

    Reply

Send a comment

Your email address will not be published. Required fields are marked with *

Share This