Tests fonctionnels sur un serveur
Discuté hier: #2323 est débattu, par contre il y a consensus sur la nécessité de faire des tests de la chaîne d'un bout à l'autre, y compris de fonctionnalités serveur, en visant par exemple dev. Un scénario possible (mais peut-être faut-il être plus modulaire et casser cela en plusieurs bouts indépendants) :
- se logguer
- créer un patient (en utilisant par exemple le sha1 du commit)
- créer un run
- uploader un sample, en le mettant dans le patient
- éditer le sample, le mettre aussi dans le run
- lancer une analyse sur une certaine config
- regarder le résultat COMPLETED, voir la stdout du job
- ouvrir dans le client le résultat
- changer quelque chose, vérifier l'URL et s'en souvenir
- modifier quelque chose et faire un save analysis
- refaire un chargement du client sur l'URL et vérifier que l'API a fonctionné
- revenir sur la db, aller dans le run
- ouvrir dans le client le résultat, vérifier que c'est bien le fichier fusé
- revenir sur la db, faire un compare sample, vérifier
- revenir sur la db, vérifier que l'analysis sauvé se récupère lorsqu'on charge dans le client
- supprimer patient/run/sample, vérifier que c'est bien supprimé ou pas #2163 (ou ne pas supprimer, cela fait un artefact/trace intéressante)
- se délogguer
Même sur dev, de tels tests auraient permis de détecter #2849 (closed), #2323 (comment 25712), et potentiellement d'autres choses. D'autres tests pourraient concerner les server-pre-process, les server-auth et server-groups, les server-config, la recherche, les tags...
Même si des tests utilisant les controlleurs/API pourraient être possible, des tests complets fonctionnel dev-tests-watir pourraient être pertinents et testent la chaine d'un bout à l'autre. À voir si on arrivera à faire des tests déterministes qui marcheront quasi tout le temps :-)
cc @RyanHerb