Functional tests

[mazda91]

Problème : les tests fonctionnels sont censés être indépendants les uns des autres. Cependant, pour cette application, ne pas connaître parfaitement la base de données et l'enchaînement des tests rend l'application difficile à tester.

Exemple : Tester le changement de mot de passe requiert que l'utilisateur ait une carte de sécurité valide, donc ayant été préalablement générée et validée. Ainsi, si on ne passe pas par tout le scénario de tests, on ne peut pas accéder à la page de modification de mot de passe.

2 options : soit on crée, à partir de la liste des utilisateurs à générer, une base de données avec le plus de diversité possible, soit on suit à la lettre le scénario de tests

[mazda91]

Update : Dans l'état actuel, les tests seront impossibles à maintenir par quelqu'un d'autre que par moi (et même moi je galère). En effet, la suite de tests est en fait un "scénario complet" à effectuer dans un ordre précis, avec des utilisateurs connus et dont l'état doit être exactement celui attendu à un instant T. Autrement dit : des tests super-dépendants les uns des autres et, si une erreur survient, c'est toute la suite de tests qu'il faut relancer.
Exemple : tester le changement de mot de passe
Un utilisateur veut changer son mot de passe. Il s'agit d'une action dite "sensible" nécessitant une carte de sécurité validée. Si l'utilisateur n'a pas validé sa carte, il faut le lui faire faire avant, et si en fait cet utilisateur n a pas de carte, il faut qu'elle soit générée par un référent avant, et si cet utilisateur n a pas de référent, il faut en créer un et l'assigner à cet utilisateur, etc... etc... etc... Bref, impossible d'envisager tous les cas de figure possibles pour chaque test.

**Solution actuelle ** : scénario de tests complet partant de l'installation de l'administrateur de départ
Inconvénient : tests pas du tout isolés. Très compliqué à maintenir si on ne maîtrise pas l'état de la base de données après chaque test.

Solution 2 : passer par une image Docker qui contiendrait le contenu d'une BDD (Cyclos + Symfony) pré-établie aussi variée que possible de sorte à pouvoir tester le plus de cas possibles, rendant moins dépendant chaque test de ceux qui l'ont précédés.
Inconvénient : je ne maîtrise pas Docker même si j'en comprends certains principes. Il faudrait créer une image Docker correspondant à l'environnement de production pour plus d'efficacité, mais le serveur de prod' n'est pas décidé, avec ses paramètres, son OS et sa config.

Le temps imparti étant court avant la soirée tests, je reste sur la solution actuelle, mais ça ne doit pas durer longtemps

[mazda91]

Note : une fois Docker bien installé, utiliser des "mocks" dans PHPUnit pour ne pas "réellement" modifier la BDD pour une meilleure isolation des tests

[mazda91]

Après avoir essayé plusieurs méthodes et outils de tests, j'ai finalement trouvé ce qu'il fallait pour isoler au maximum les tests. Le processus global est le suivant :
_ supprimer la BDD MySQL et la récréer avant de lancer la suite de tests
_générer, à l'aide d'un script python, l'ensemble des pros côté Cyclos à coût de requêtes POST
_utiliser un fichier bootstrap.php qui appelle les commandes initiales à exécuter avant de lancer PHPUnit :

• créer l'administrateur de départ côté MySQL
• créer les pros côté MySQL et mettre en place des données différentes selon les utilisateurs pour tester un maximum de cas
• lancer la suite de test

Les 3 méthodes testées ont été les suivantes :

1. avoir un scénario de test complet du test1 au test N (voir commentaires ci-dessus). Pas d'isolation de code du tout
2. utiliser DbUnit, qui après chaque test compare la base de données avec un fichier au format Yml (ou Xml par exemple), supprime le contenu de la BDD et le remet dans l'état tel que décrit dans le fichier. Premièrement, j'ai découvert hier que cet outil n'est plus maintenu, et en plus avait le défaut d'être assez lourd à exécuter
3. le bundle doctrine-test-bundle qui, à l'aide d'un listener, exécute un "rollback" des différentes transactions réalisées après chaque test, de sorte à maintenir la BDD dans un état stable. Les tests sont donc complètement isolés et on peut les relancer autant de fois que nécessaire de façon individuelle.

La méthode 3 est celle actuellement utilisée.
Travaux à réaliser maintenant :

• compléter la BDD de référence
• modifier les tests en conséquence
• automatiser la configuration de Cyclos
• utiliser le client Mink (qui réalise des vraies requêtes HTTP) plutôt que BrowserKit(fourni en interne par Symfony simulant les requêtes HTTP ) pour tester le code JS en +