Bon, j'ai gagné deux minutes sur 5 en optimisant mon code. Ce qui m'a
fait gagner le plus de temps etait de faire attentions aux XPath. J'ai
également utilisé les options run_server et app_host de Capybara qui me
fait gagner 7/8 secondes à chaque lancement.
J'ai encore des tests long car le chemin à parcourir peut être long et
joignable uniquement en JavaScript.
La dernière chose qui prend du temps est lors du premier lancement de
capybara webkit. Avez vous une solution pour lancer le navigateur lors
du prefork de Spork?
Bonne soirée à tous!
Le 2012-05-02 11:41, Guirec Corbel a écrit :
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]
<mailto:[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]
<mailto:[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]
<mailto:[email protected]>> a écrit :
2012/5/2 Florian Dutey <[email protected]
<mailto:[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]
<mailto:[email protected]>
Pour résilier votre abonnement envoyez un e-mail à
l'adresse [email protected]
<mailto:[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]
<mailto:[email protected]>
Pour résilier votre abonnement envoyez un e-mail à l'adresse
[email protected]
<mailto:[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]
<mailto:[email protected]>
Pour résilier votre abonnement envoyez un e-mail à l'adresse
[email protected]
<mailto:[email protected]>
--
Guirec Corbel
Conception Korrigan
418-409-5194
http://www.conception-korrigan.com
--
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]
