avec du single page application, tu simplifies masse les test cote serveur deja.
modeles, routes et controllers. pour ma part, jestime que les tests du contenu json, c inutile (dans le monde reel quoi). cote js, jasmine ne teste que les modeles, en mockant les appels ajax (un peu relou, surtout quand on change les vues json cote server, vivent les helpers). on fait du backbone, donc leur mix hybride View qui est aussi un controller est relou a tester. du coup tu fous un petit coup de tests dintegration, dans les grandes lignes (parce que c super chiant a ecrire et a maintenir), ca teste deja la majorite de tes templates, et ca verifie que lappli fait le taff. c bien ce qui compte. cdlt Le mardi 4 mars 2014, Guirec Corbel <[email protected]> a écrit : > Merci pour les avis. Je vais tester poltergeist et améliorer mes tests d'intégration pour du javascript. Personnellement, moins il y a de Javascript, mieux je me porte. J'essai de l'éviter quand c'est possible. > > Le 4 mars 2014 04:18, Olivier El Mekki <[email protected]> a écrit : >> >> Hello, >> >> Je faisais des tests unitaires js il y a 5 ans, en utilisant jasmine >> (j'utilisais mootools à l'époque, ce qui rendait les choses plus faciles >> étant donné qu'il encourageait l'OO). >> >> J'ai fini par arrêter pour raisons de productivité. Il y a un moment où >> l'obsession du code coverage devient une boulimie. >> >> Aujourd'hui, mon js est uniquement testé au niveau des tests >> d'intégration. C'était d'abord un problème à l'époque de selenium parce >> qu'il était trop lent, puis avec capybara-webkit à cause de ses erreurs >> random incompréhensibles. Aujourd'hui, j'utilise poltergeist et ça me >> convient parfaitement. >> >> Idéalement, unit tester son js serait un mieux, ne serait-ce que parce >> que tu peux écrire ton js en tdd et que ça tend à faire du code mieux >> architecturé. Mais si tu veux faire cela, tu as plutôt intérêt à avoir >> une équipe de dév conséquente avec toi et/ou être sur un projet sur >> lequel tu n'as pas trop de pression de la part des non-dévs (comprendre >> : un projet perso). Ça peut rester justifiable si js represente la plus >> grosse partie de l'app, comme sur un projet angular ou toute app >> majoritairement client side. >> >> Pour le reste, des tests d'intégration exécutant le js (et qui teste >> spécifiquement les features js) et des avertissements en cas d'erreur js >> (en utilisant `window.onerror` et en le faisant rentrer dans le système >> des exceptions server side) me suffisent. >> >> >> On Monday, March 3, 2014 9:35:32 PM UTC+1, Guirec Corbel wrote: >>> >>> Bonjour, >>> Pour une application rails, j'ai certains formulaires avec du Javascript. J'aimerais savoir, selon vous, quel est la bonne façon de faire ce genre de tests. Pour être clair, je vais prendre un exemple : >>> Un entrepreneur doit pouvoir ajouter plusieurs succursales. Il y a un bouton qui permet d'ajouter une ligne où on peut choisir une adresse. Dans l'adresse, il y a le pays et la province/état. Selon le pays que l'on choisi, les provinces/états changent. Il y a donc deux parties Javascript : l'ajout d'un succursale et le choix d'une province. >>> Pour le moment, je fais des tests d'intégration et des tests manuel. Le problème c'est que c'est long à exécuté et pas toujours fiable. La seconde solution serait de tester avec un outil comme Jasmine mais je crois que c'est difficile à isoler étant donné que ça touche au DOM et ça fait de l'Ajax (avec JQuery). De plus, j'image que c'est difficile de faire des tests d'intégration avec Jasmine. >>> Pour votre part, comment faites vous? >>> Bonne soirée, >>> Guirec. >> >> -- >> -- >> Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. >> Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] >> Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] >> --- >> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. >> Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. >> Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out . > > -- > -- > Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. > Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] > --- > Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Railsfrance". > Pour vous désabonner de ce groupe et ne plus en recevoir les messages, envoyez un e-mail à l'adresse [email protected]. > Pour obtenir davantage d'options, consultez la page https://groups.google.com/groups/opt_out. > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
