Un bref rappel de la pyramide des tests

La pyramide des tests

La pyramide des tests a été définie par Mike Cohn en 2009 dans son ouvrage “Succeeding with Agile”, dont voici un rappel (très) rapide :

• Les tests unitaires (TU) permettent de tester un élément individuel de l’application (classe, fonction…).

• Les tests d’intégration vérifient que les différentes parties de votre application fonctionnent bien une fois intégrées ensemble.

• Les tests end-to-end (E2E) permettent de tester l'ensemble de l'application pour s'assurer qu’elle fonctionne comme prévu. Ils simulent des scénarios proches des cas d’utilisation réels.

Les tests à la base de la pyramide sont rapides, faciles à exécuter, stables et rentables, alors que ceux au sommet sont lents, chers à implémenter et difficiles à maintenir.

L’objectif des tests End-To-End (E2E)

L’objectif des tests E2E (aussi appelés tests fonctionnels) est de vérifier que l’application est bien en conformité avec les exigences fonctionnelles exprimées par le client.

Ces tests permettent donc de s’assurer que, dans un contexte d’utilisation réelle, le comportement fonctionnel obtenu est bien celui attendu. Par exemple : tester qu'un utilisateur peut bien s'inscrire, se connecter, se déconnecter…

S’ils représentent une étape essentielle de la validation d’une application, ils n’ont pas besoin de connaître le détail de l’implémentation. Ce sont des tests dit "boîte noire".

Comment écrire des tests end to end ?

Chaque outil propose son propre framework, langage pour écrire des tests.
Par exemple, avec l’outil Nightwatch :

browser
.navigateTo(http://localhost:3000/login)
.waitForElementVisible('body', 100)
.setValue('input[name=email]', "test@test.com")
.setValue('input[name=password]', "password1234")
.click("#login")
.waitForElementVisible("div.logged", 500)
.assert.textContains("div.logged", Bienvenue test@test.fr)

Autre exemple avec l’outil Cypress :

describe('Test Login', () => {
it('Login correct', () => {
cy.visit('http://localhost:3000/login')
cy.get('input[name=email]').type('test@test.com')
cy.get('input[name=password]').type('password1234')
cy.get('#login').click()
cy.get('div.logged').should('have.text', 'Bienvenue test@test.fr')
})
})

On le voit sur ces deux exemples, le langage est très différent entre les outils.

Gherkin, des tests compréhensibles de tous

De plus, les tests écrits ainsi sont très techniques et compréhensibles uniquement par le développeur. Gherkin apporte une réponse sur ce point. Issu de la pratique du Behaviour Driven Development, le langage Gherkin permet de décrire avec un langage dit ”naturel” les scénarios de test.

Grâce à cette syntaxe simple et intelligible, le test est compréhensible par un public beaucoup plus large.

Le même exemple rédigé en Gherkin :

Scenario: L'utilisateur fournit les bons identifiants
Given Je suis sur la page "Login"
When J'entre mon email "test@test.com"
And J'entre mon mot de passe "password1234"
And Je clique sur le bouton "Me connecter"
Then J'ai un message de bienvenue

Cette sur-couche est particulièrement intéressante car elle permet de s’assurer de la bonne compréhension de ce qui est attendu par le développeur.

Beaucoup de solutions proposent des plugins permettant d’écrire des tests avec Gherkins. Le plus connu étant Cucumber.