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]
