Je suis d'accord avec toi sur le fait que ton test permet de voir si les erreurs sont envoyés ou non mais ça ne dit pas si l’erreur est affichée ou non. Les tests peuvent très bien passer mais ne pas afficher un message d'erreur à cause d'une erreur javascript ou, tout simplement, que je n'ai pas mis le code pour afficher. C'est vrai qu'un test manuel peut faire aussi bien rapidement mais ça n'assure pas que l'erreur ne se produit pas par la suite et donc qu'il y a une régression.
Le 2 mai 2012 10:48, Florian Dutey <[email protected]> a écrit : > Je ne suis pas d'accord avec toi. > Quand ton test d'intégration vérifie que si tu laisses un champ vide de > ton formulaire et que tu le soumets, alors le controller ne redirige pas > mais rend une vue QUI contient un champ erreur a coté de ton input avec la > bonne classe et / ou le bon id et qu'il y a bien le bon message dedans, ca > peut être testé d'une autre manière: > > #model > > describe Model do > it { should validates_presence_of(:field) } > end > > #controller > > describe ModelsController do > describe "POST create" do > describe "with invalid params" do > it "should not redirect on error" do > Model.any_instance.stub(:save).and_return(false) > > post :create, :model => {} > > assigns(:model).should be_a_new(Model) > assigns(:model).should_not be_persisted > end > > it "should render new template" do > Model.any_instance.stub(:save).and_return(false) > > post :create, :model => {} > > response.should render_template(:new) > end > end > end > > Si tu as utilises des helpers dans ta vue, teste directement les helpers > (de la même manière). > > Si tu regardes, refaire un test d'intégration la dessus reviendrait à > retester le controller et le modèle, ce qui est inutile. > Ton test d'intégration ne te servira plus qu'a valider que l'utilisation > de toutes ces parties qui fonctionnent déjà est correcte. Il valide que > *l'intégration > *de code valide est faite correctement, ce qui colle à ta définition. > > Tu gagneras en rapidité de tests d'une part, en maintenabilité > (responsabilités mieux séparées) et tu pourras plus facilement réutiliser > ton code. > > Cordialement. > > > Le 2 mai 2012 16:28, Guirec Corbel <[email protected]> a écrit : > > Je ne vois pas les tests d’intégrations comme des tests d'ui ou des tests >> de vues. Je vois ça comme une fonctionnalité que l'on veut passer. Si ces >> tests marchent, mes objectifs sont atteints. >> >> Je sais bien que ça sera lent, de toute façon. Je pense que le fait >> d'optimiser chacun de mes tests va suffire pour atteindre une vitesse >> raisonnable. Je vais également utiliser plus souvent les tests des >> controllers, helpers, mailers, etc... pour diminuer le nombre de fois ou >> j'utilise les tests d'intégrations. >> >> Je vais aussi utiliser https://github.com/grosser/rspec-instafail pour >> ne pas avoir a attendre la fin des tests pour avoir un message d'erreur. >> >> Je vais également penser à Travis. >> >> Merci pour votre aide. >> >> Le 2 mai 2012 10:10, thierry henrio <[email protected]> a écrit : >> >> 2012/5/2 Florian Dutey <[email protected]> >>> >>>> >>>> L'idéal, c'est de limiter au minimum tes tests de vue en reportant le >>>> plus possible de choses sur les controllers et les helpers >>> >>> >>> Guirec, Ca me fait penser à "comment tu testes" :) >>> >>> Ecrire un test pour l'ui avant d'écrire l'ui, ne m'aide pas à la >>> conception de l'ui : je préfère faire un dessin ou juste la faire >>> (ça c'est mon opinion) >>> >>> Et il y a un effet de bord à tous ces tests d'intégration : tu attends, >>> parce que les test d'intégration, c'est plus lent qu'un test avec "moins de >>> choses dedans" >>> >>> Thierry >>> >>> >>> -- >>> 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 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 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 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]
