Le pattern AAA, qu'est-ce que c'est ?

Le pattern AAA a pour but d'améliorer la structure des tests unitaires pour les rendre plus lisibles et augmenter leur maintenabilité, tout en poussant les developpeurs à écrire des tests plus concis.

De plus, ce pattern est une application des principe de responsabilité unique (Single-responsibility protocol) et FIRST (Fast Independant Repetable Self-validating, Timely) sur la partie testing.

En effet, si l'on respecte le pattern AAA, on aura une grande quantité de petits tests rapides a executer, chacun ayant pour but de vérifier un cas de test précis, plutôt que d'avoir des tests vérifiant plusieurs cas en même temps.

Concrètement, comment ça marche ?

Lorsque l'on utilise ce pattern, on va découper chacun de nos cas de test en 3 parties.

Arrange

C'est la phase d'initialisation de notre cas de test. Dans cette section, on va faire le rendu de notre DOM, créer et initialiser les variables qui seront utilisées pendant le deroulé du test, mettre en place nos mocks... Il ne faut pas confondre cette phase avec la phase d'intialisation concernant tout un jeu de test, réalisée par exemple avec la méthode beforeEach. En effet, cette méthode vient en amont du pattern AAA, car elle vient faire une initialisation générale pour tout notre jeu de test, contrairement à la phase Arrange, dont le but est de faire l'initialisation pour un seul cas de test.

Act

C'est la phase d'action de notre cas de test. Dans cette phase, on va effectuer les instructions dont on cherche à valider le comportement. Si l'on prend l'exemple d'un formulaire de connexion, on va utiliser des instructions permettant de remplir le nom d'utilisateur et le mot de passe, puis de cliquer sur le bouton "Se connecter", pour tenter de valider le cas de test où le nom d'utilisateur et le mot de passe sont bons et l'utilisateur réussi à se connecter.

Assert

C'est la phase de vérification de notre cas de test. Dans cette partie, on va effectuer des vérifications permettant de s'assurer que les actions effectuées a la phase précédente ont bien eu l'impact escompté. Si je reprends l'exemple du formulaire de connexion, si le nom d'utilisateur et le mot de passe sont incorrects, je m'attends à avoir un message d'erreur et au contraire si le nom d'utilisateur et le mot de passe sont bons, alors je m'attends à être redirigé vers la page d'accueil. Je peux donc tester l'apparition d'un message d'erreur, ou bien le fait d'être redirigé vers la page d'accueil, selon le cas que je souhaite tester.

Lorsque l'on utilise le pattern AAA pendant l'écriture d'un test, l'objectif est de faire en sorte que chacune de ces 3 parties n'apparaisse qu'une fois, dans l'ordre des 3 sections ci-dessus (Arrange, Act puis Assert). Cela pousse la personne développant le test à faire preuve d'une plus grande rigueur lors de l'écriture pour respecter ce pattern.

Concrètement, ça sert à quoi ?

C'est un pattern très léger mais qui a beaucoup d'avantages :

• Limiter le nombre de gros tests : pour respecter AAA, on va être obligé de découper nos gros tests en plusieurs petits tests
• Augmenter le nombre de petits tests
• Augmenter fortement la lisibilité des tests : on distingue très facilement et rapidement les 3 différentes sections en parcourant un fichier de test
• Améliorer la maintenabilité des tests : grâce à l'amélioration de l'organisation des tests

Exemple d'implémentation

it("should return 'Incorrect password.' when password is empty", async () => {//Arrangeconst { container, getByPlaceholderText } = render(ConnexionForm);const usernameField = getByPlaceholderText('Enter your username')const loginButton = getByText('Connect');//ActuserEvent.type(usernameField, 'myUsername')userEvent.click(loginButton)//Assertawait waitFor(() => {    expect(getByText('No password provided.').toBeInTheDocument();})expect(getByText('No password provided.').toBeVisible();}

Ce test a été réalisé en utilisant les framework de test Jest et Testing Library

Dans la section Arrange, on commence par faire le rendu de notre formulaire de connexion.

On récupère ensuite le champ username en se basant sur le placeholder du champ, et on récupère le bouton de connexion à l'aide du texte présent sur le bouton.

On va ensuite utiliser la librairie user event de Testing Library, qui permet de facilement interagir avec notre page, comme si les interactions étaient realisées par un utilisateur.

Dans la section Act, utilise la fonction type de userEvent pour saisir 'myUsername' dans le champ usernameField (comme si un utilisateur entrait lui même cette valeur) puis on clique sur le bouton de connexion.

Pour finir cet exemple, dans la section Assert, on va s'assurer que le résultat de notre test correspond a ce qui est attendu en vérifiant que le texte "incorrect password." est bien affiché dans le document (et est également bien visible, car il peut être dans le document tout en étant caché)

En conclusion, le pattern AAA, en plus d’être très léger, est un moyen simple de mettre un pied dans les bonnes pratiques préconisées par Clean Code. Mettre en place le pattern AAA dès le début des développements est assez simple, cependant, réadapter tous les tests d'une application pour respecter ce pattern peut êtrechronophage. En effet, une partie des tests existants risquent de devoir être scindés en plusieurs tests, ce qui obligera une repasse sur chacun de ces cas de test.