BEHAT 3 et MINK avec Symfony2

Lorsque nous développons un site internet, il est plus que conseillé de faire de la BDD, à défaut des tests fonctionnels après avoir développé la fonctionnalité du site.

La raison en est simple: un site internet évolue si rapidement que vérifier toutes les régressions possibles est une perte de temps considérable, et surtout, les tests pouvant être lancés via un outil tel que jenkins, les régressions sont immédiatement détectées. De quoi « soulager » les inquiétudes du chef de projet et des dev sur l’assurance que rien n’a été cassé.

Tout commence par le composer.json

C’est parti, on doit rapatrier un certain nombre de librairies pour que tout fonctionne: BEHAT, pour écrire des scénarios, et MINK, pour pouvoir naviguer dans l’HTML et accéder à un certain nombre de méthodes déjà existantes.

Dans le require-dev, vous devriez donc avoir ceci:

Bien évidemment, phpunit n’est pas utile ici, mais c’est parce que je fais toujours des tests unitaires et fonctionnels dans mes projets.

Le driver selenium2 va être très important pour lancer le navigateur.

Rien à faire côté appKernel (ça aurait été différent si nous avions fait appel au mink-bundle qui peut s’utiliser sans Behat et qui fournit une interface pour naviguer dans HTML)

Création d’un fichier behat.yml dans le répertoire config à la racine du site

Il n’est pas obligatoire de le placer ici (il peut être mis directement à la racine du site sans être mis dans un fichier config), mais c’est une pratique que je trouve bonne, car on y met aussi des config de capistrano par exemple.

Voici comment il est composé:

  • On indique que les features appelées sont dans src
  • On appelle les extensions Behat de Symfony2 et de Mink, en spécifiant l’url local et comme session selenium2
  • On définit ce qu’on appelle des suites, c’est à dire les bundles qui vont être testés
  • Dans ces suites, on peut définir un context qui va pouvoir être utilisé partout (plutôt que de dupliquer les fonctions qui seront utiles dans chaque context)
  • On définit des profils d’environnement: default, dev, preprod, prod avec la bonne url à chaque fois. Vous allez rapidement comprendre pourquoi l’on fait cela.

Création des features et scénarios dans un bundle

Votre bundle est créé, mais vous voulez écrire des tests fonctionnels dedans. Pour cela, rien de plus simple. Rendez-vous dans votre console et tapez la ligne suivante:

Ici, votreSuite peut être bo, ou bo_user, ou encore blog.

Exécuter cette ligne va afficher ceci:

Attention, si vous avez déclaré un context comme le CoreContext dans « contexts », le répertoire Features sera créé dans votre bundle mais pas le fichier FeatureContext.php, et vous devrez alors le créer à la main

Que le fichier FeatureContext.php ait été généré ou non, voici la tête qu’il doit avoir:

Il va falloir le modifier, car aujourd’hui, si vous tapez la commande

et que vous n’avez défini aucun context (comme le CoreContext que j’ai mis en place) eh bien vous n’aurez rien. En effet, il n’y a aucune définition possible. Et c’est là que Mink rentre en jeu.

Modification du fichier FeatureContext.php

Mais quel est donc ce fichier Behat\MinkExtension\Context\MinkContext? Eh bien il étend des classes qui, arrivé presque au plus haut niveau de l’arborescence, implémente Behat\Behat\Context\Context.

Mais surtout, il comporte un grand nombre de méthodes qui vont pouvoir nous servir sur nos scénarios! En effet, si vous retapez à présent votre ligne de commande

vous verrez cela:

Là, ça devient plus qu’intéressant, car on a déjà un paquet d’expressions que l’on peut utiliser. Si vous préférez la version anglaise, il suffit que vous tapiez  bin/behat --suite=votreSuite -dl --lang=en

et ceci apparaîtra:

Dans le CoreContext, vous pouvez placer des fonctions comme:

Ainsi, à chaque fois que, dans le fichier de configuration behat, vous mettrez

cette fonction sera accessible de partout.

Mise en place des premiers scénarios

Passons aux choses sérieuses. On se place dans le bundle pour lequel le fichier Features/Context/FeatureContext.php a été généré, et on crée un répertoire appelé « Scénarios » dans le dossier « Features ». Dans ce répertoire, on crée un fichier de la page que l’on veut tester, par exemple home.feature (le .feature est extrêmement important)

Ce fichier va se découper en plusieurs parties:

  • Feature
  • Background (pas obligatoire)
  • Scenario (obligatoire)
Ici, j’indique que ma feature traite de la homepage, j’indique un background qui va s’exécuter pour tous les tests, et je décris mon scénario.

Dans Mink, ce qui est particulier, c’est que lorsqu’on a cliqué sur un lien, pour accéder à la page suivante, il faut écrire « And I move forward one page ».

Lancer le test

Pour lancer le test, il faut faire deux choses:

  • télécharger le fichier selenium server qui se trouve ici: http://www.seleniumhq.org/download/ (cliquez sur le fichier de téléchargement dans la section « Selenium Standalone Server »
  • Le lancer dans une fenêtre shell en tapant  java -jar selenium-server-standalone-2.47.1.jar
  • Lancer la commande  bin/behat --suite=votreSuite --append-snippets

La console nous dit:

Et une fonction est apparue dans notre fichier FeatureContext du bundle BlogBundle:

Behat nous dit qu’il ne sait comment gérer ça. C’est là qu’il faut alors écrire le code qui gère cette action, comme:

Si jamais cette fonction existe dans le CoreContext, bien sûr, Behat ne va pas vous demander de la réécrire ici, mais j’ai fait comme s’il n’y avait pas de CoreContext, ou qu’il était vide.

Mais je me dis que vous vous demandez peut-être, depuis tout à l’heure, pourquoi nous avons mis –append-snippets. Eh bien, en fait, cette option vous permet de demander à Behat d’écrire justement le bout de code

Sans cela, voici ce que vous auriez eu dans la console:

Futé, le bison, n’est-ce pas?

Les profils

Une toute dernière chose. Vous vous demandez peut-être comment Behat sait sur quelle url il doit aller lorsqu’on écrit « When I am on homepage ».

Eh bien, c’est très simple. Si l’on regarde en détail le code, on voit ceci:

On retrouve ce fameux base_url que l’on a défini dans notre fichier behat.yml !

Et comment faire si l’on veut que l’on appelle l’url de preprod? Tout simplement en rajoutant à la fin de l’appel, dans le shell:   --profile=preprod

Rappelez-vous, nous avons défini quatre profils: default, dev, preprod et prod.

En appelant celui de preprod, vous allez taper sur l’url http://mon-url.preprod

A présent, vous êtes armés pour démarrer vos tests fonctionnels sur vos applications Symfony2!

Rédigé par

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *