S’il est un domaine oublié des développeurs, c’est bien celui des tests. Pourtant ce domaine est lourdement outillé. Mais comme il se situe en aval du développement et que les développeurs n’ont plus le temps, il est régulièrement oublié. Le résultat est que ce sera l’utilisateur qui découvrira les erreurs et se retrouvera bloqué.
Une erreur n’est pas nécessairement un logiciel qui ne fonctionne pas. Cela peut aussi être une faille exploité par un délinquant dans le but de dérober des informations monnayables (adresses électroniques, identités, coordonnées bancaires, …). Donc, oui, notre application doit être testée correctement.
Tester chaque objet ?
Le premier des tests est ce qu’on appelle le test unitaire. Une application est un ensemble d’objets. Un objet propose des interfaces et des fonctions. L’idée est donc d’écrire un programme qui va valider chaque interface en fonction de ce qui a été décrit initialement. Ce programme sera exécuté à chaque changement de notre objet. Mais cela est long à (d)écrire.
C’est comme réécrire entièrement notre application. Et je n’ai pas trouvé comment en automatiser cela. L’intérêt est certain pour une application professionnelle où interviennent des dizaines de développeurs, mais dans notre cas, c’est beaucoup trop.
Tester les fonctionnalités !
La solution que je vous propose est de vous mettre à la place de l’utilisateur. On parle alors de tests d’intégration. L’idée est de lister toutes les fonctionnalités de notre application (voir nos notes et le DCU) et de regarder qu’elles sont réalisables. Chaque fonctionnalité validée est barrée de la check-list.
Dans notre cas, il s’agit donc de se mettre à la place du créateur qui définit un nouveau questionnaire, ses questions et ses réponses. Si vous arrivez à faire cela sans que le programme ne renvoie d’erreurs. C’est bon signe. De même, en se mettant du côté du joueur, il s’agit de vérifier qu’on puisse participer à un questionnaire jusqu’au bout sans anomalie.
Symfony aide à tester. Un barre noire apparaît en bas de votre application. Cette barre liste les caractéristiques de votre application. Si une caractéristique apparaît, sur fond rouge, c’est qu’il y a une erreur. Celle-ci n’est pas forcément bloquante mais il faut la corriger. Merci Symfony.
La faiblesse des tests d’intégration est qu’ils restent dans un environnement spécifique. Nous sommes encore sous l’environnement de développement. Au final, notre application sera déployée sur un environnement de Production qui ressemble peu à notre environnement actuel. En principe, Symfony permet de masquer ces différences.
Dès l’environnement de développement, il est possible de simuler un comportement de Production. Pour cela, dans le fichier ‘.env’, il faut modifier la variable APP_ENV et remplacer la valeur dev par prod. En plus de faire disparaître la barre de débogage, cela active les règles de sécurité que nous avons défini. Un joueur ne peut se déplacer que de question en question sur un questionnaire. Toutes les autres fonctionnalités du site lui sont interdites …
Une deuxième étape à réaliser sera des tests de validation (environnement similaire à la production avec des données fictives) ou de recette (données réelles). En pratique, pour une application web personnelle, autant de tests est inutile. Les erreurs de codage et de sécurité apparaîtront dès l’intégration.
La volumétrie
Il y a un type de test que je conseille quand même. C’est ce qu’on appelle le test de volumétrie. Il permet de se rendre compte des limites d’une application. Vous pensez qu’un questionnaire ne présente pas de risque sur une plateforme. Je vous renvoie vers cette vidéo. On sous-estime les risques de volumétrie.
Pour effectuer des tests de volumétrie, il faut écrire un programme pour remplir sa base de données. Sous Symfony, il existe un mécanisme nommé Fixtures et une bibliothèque nommée faker. Je vous recommande l’article officiel sur le site de Symfony et la vidéo de Lior Chamla à partir de ‘22:15’.
Pour un peu de code écrit, nous pouvons alimenter notre base avec des milliers de questionnaires et des dizaines de milliers de questions/réponses. Avec cela, nous pouvons vérifier que l’application est bien écrite et ne ralentit pas à cause d’un trop grand nombre de questionnaires.
Un autre aspect de la volumétrie est le nombre d’utilisateurs auxquels peut répondre notre application en simultané. Il existe des outils et des automates pour cela, mais c’est une tâche supplémentaire. Une autre solution est de regarder le temps nécessaire au serveur pour répondre.
En mode ‘dev’, cette information est directement affichée. Avec l’option F12 des navigateurs, vous pouvez aussi voir le temps nécessaire à la réponse. C’est moins fiable parce qu’il faut retrancher les coûts réseaux mais cela reste réaliste. Avec une règle de 3, il est possible de connaître les limites de notre application sur le serveur.
4 ms pour retourner une page. Il peut donc répondre à 250 joueurs par seconde. C’est correct. En cas de besoin, il est possible de passer sur un serveur plus puissant, ou de déporter l’accès des images sur un autre serveur.
Conclusion
Bien qu’il ne s’agisse pas d’une application professionnelle, notre questionnaire se doit de ne pas ‘planter’. C’est pour cela que les tests sont indispensables. Il n’y a rien de plus désagréable pour l’utilisateur que de se retrouver bloqué. Bad Buzz. Et puis, une erreur détectée en Production fait perdre beaucoup plus de temps que si elle est détectée dès le développement.
En conclusion, il faut toujours prendre un peu de temps pour tester les fonctionnalités et s’assurer que notre application est bien optimisée. Cela ne nécessite pas des outils extraordinaires mais simplement du bon sens.