eyrolles_tests.tex

\subsection{Écriture de tests}
\label{section:eyrolles_tests}

Le projet \aey\ n'échappe pas à la règle : comme ses pairs, il est lui aussi soumis, via \asismo, au processus d'intégration continue décrit dans la partie~\ref{section:sismo}.

Le \afm\ \asf\ supporte deux types de tests complémentaires : les tests unitaires et les tests fonctionnels.


\subsubsection{Tests unitaires}

\begin{quote}
Le test unitaire est un procédé permettant de s'assurer du fonctionnement correct d'une partie déterminée d'un logiciel ou d'une portion d'un programme.~\cite{unit}
\end{quote}

Avec \asf, la bonne pratique consiste à tester les méthodes des classes de modèle et des classes utilitaires, indépendamment du reste de l'application. En effet, si à un moment ou un autre un des développeurs modifie le comportement de l'une des méthodes clés testées, les tests unitaires concernés deviendront potentiellement invalides.

Deux cas sont alors possibles : soit le nouveau comportement est désiré, soit au contraire c'est une erreur. Dans le premier cas, les tests unitaires ainsi que les parties de l'application qui utilisent leurs spécifications doivent être modifiés en conséquence. Dans le second, le comportement doit revenir dans son état précédent alors que les tests restent intacts. Dans chaque situation, le but est de ramener la suite de tests vers son état valide. Ainsi, l'écriture de tests unitaires est une bonne façon de s'assurer que toute modification de code testé sera suivie d'une vérification.

Une façon de tester unitairement une méthode consiste à l'appeler plusieurs fois, avec des paramètres ou un contexte différent. On vérifie alors si les valeurs retournées sont bien celles attendues, si une exception est propagée, si le contexte est dans le bon état, etc.

Dans \asf, les tests unitaires sont effectués à l'aide du \afm\ de test unitaire \alime. Sur le projet \aey, ils ont été écrits tout au long du cycle de développement. Par souci de pragmatisme, seules les méthodes relativement importantes sont testées : il s'agit de ne pas perdre de temps avec les méthodes évidentes, ce qui reviendrait à tester les fonctionnalités de \asf, elles-mêmes déjà unitairement testées de leur côté.

Au-delà de prévenir les régressions sur le projet, l'écriture de tests unitaires a permis de mettre à l'épreuve rapidement des classes à la logique poussée, et ce dès leur création. Cette démarche se rapproche de la méthode connue sous le nom de \emph{développement piloté par les tests}, qui préconise d'écrire les tests unitaires avant même d'écrire le code correspondant. Rapprocher les deux phases d'écriture a l'avantage de garantir un résultat cohérent avec les spécifications initiales. En effet, le développeur peut tester tous les cas limites de la méthode immédiatement après son écriture, car il peut lancer rapidement son script de tests unitaires. Les erreurs potentielles sont alors détectées et corrigées très tôt.


\subsubsection{Tests fonctionnels}

Les tests fonctionnels diffèrent des tests unitaires du point de vue qu'ils vérifient les fonctionnalités de l'application. Leur portée s'éloigne ainsi du code et devient globale à l'application. Au niveau d'un site web, un test fonctionnel consiste à naviguer à l'intérieur, en cliquant sur des liens, en remplissant des formulaires, ou encore en vérifiant si divers éléments d'une page sont bien présents.

Grâce au \afm\ \asf, il est possible d'automatiser ces tâches. En effet, il existe une classe \texttt{sfBrowser} qui simule la visite des pages du site de la même façon qu'un navigateur web. Celle-ci est instanciable et contrôlable dans un script \aphp, rendant ainsi possible l'exécution automatique du test fonctionnel via \asismo.

Ce type de test prend tout son intérêt quand il s'agit de tester un cas d'utilisation typique de l'application web par le client. En reproduisant un ensemble significatif des scénarios utilisateurs sous forme de tests fonctionnels, on peut alors s'assurer du bon fonctionnement global du site, quels que soient les changement de code entrepris.

Dans le cas du projet \aey, un test fonctionnel simple a été écrit pour chaque page de l'\aintranet : il vérifie si elle s'affiche correctement, sans retourner de code d'erreur. De la même manière, les formulaires de l'application sont remplis avec des valeurs valides ou non, sont soumis, et le contenu de la page renvoyée est vérifié. Enfin, durant la phase de recette, un test fonctionnel est écrit pour chaque \abug\ de type \og défaut \fg\ corrigé : ce test qualifié de test de non-régression permet de s'assurer que le client ne rencontrera pas à plusieurs reprises un même problème.