Qu'est-ce qu'un bon test fonctionnel browser/server ? Améliorer les tests unitaires ?
Discuté avec @flothoni et @duez : que ce soit watir ou cypress, que doit être un bon test fonctionnel pour ne pas être juste du "clique-bouton" + "parse" ?
Marc: "les choses intelligentes devraient être surtout dans les tests unitaires, le test fonctionnel pourrait juste vérifier que les choses sont au bonne endroit. Vouloir avoir trop de scénarios complexe ne couvre pas de toute façon"
Mathieu: "Ok en général, mais par contre les scénarios type tutorial/doc sont intéressants à être testés"
Marc: "Oui, le scénarion utilisé 90% du temps doit être testé. Mais pas le scénario ultra-bizarre de composition de deux fonctionnalités, tester plutôt au plus près de la fonctionnalité en cause, et donc unitaire."
Florian: "Autre perspective: qu'a-t-on envie avoir comme test échoués ? Le but d'un test est qu'il échoue quand il le faut pour nous aider. Et dans le passé, a-t-on eu beaucoup de tests ainsi ?"
Marc: "On devrait faire plus de chose en tests unitaires (et pas de parse à faire). Typique fonction de reset, loading. Et d'ailleurs quand un test QUnit échoue, je sais que c'est problème majeur"
Florian: "Absolument !"
Discussion sur un cas particulier: bug sur clone de distribution #4789. Marc: "Un bon réflexe est de faire des tests... mais si on le fait fonctionnel, c'est trop loin, on s'intéresse à une interaction trop particulière sur des millions de combinaisons. Rajouter plutôt un test unitaire au bon endroit sur le comportement fautif." Point très intéressant à creuser.
Si vous voyez des liens/posts là-dessus, n'hésitez pas à les mettre.