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