Bonjour,
J’essaye de mettre en place les tests pour mon projet et j’aimerai
savoir s’il est possible d’avoir plusieurs jeux d’essais différents
(stockés dans des fichiers yml différents).
Je pose cette question car par exemple j’ai une fonction qui fait une
recherche assez compliquée sur pas mal de critères. J’ai donc
construit mes fixtures avec pas mal de données pour tester les
différents cas en vérifiant le nombre d’enregistrements retournés pour
chacun des cas. Mon problème est que en avançant sur mon projet (et
sur les tests) je vais sans doute avoir besoin de rajouter des
fixtures pour être complet et que ces fixtures vont “perturber” mes
tests déjà valides. D’ou ma questions sur la possibilité de gérer des
jeux d’essai différents en fonction de ma phase de test.
Merci
Nicolas
Le 5 juillet 2008 15:31, Tranquiliste a écrit :
J’essaye de mettre en place les tests pour mon projet et j’aimerai
savoir s’il est possible d’avoir plusieurs jeux d’essais différents
(stockés dans des fichiers yml différents).
Faut regarder du côté des fixtures scenarios, quelques pistes :
http://code.google.com/p/fixture-scenarios/
http://blog.inquirylabs.com/2008/05/26/simplifying-rails-fixtures-with-contexts/
– Jean-François.
–
http://twitter.com/underflow_
Sinon, faut peut-être adapter les tests…
++
yk
Le 5 juillet 2008 17:10, Jean-François Trân [email protected] a écrit :
Meric jean François, ce plugin a l’air de répondre à mon problème
Yann le problème de modifier les tests c’est que tu introduis un
risque d’erreur.
Nicolas
J’aimerais comprendre en quoi modifier des tests peut introduire des
erreurs.
Je comprends que cela puisse paraître ennuyeux de “réécrire des tests”
mais si tu modifies la finalité d’une méthode, techniquement, les
tests la concernant ne sont plus valables. C’est pourquoi on parle de
“refactorisation” et cela se pratique aussi sur des suites de tests.
Le risque d’erreur serait de ne surtout rien changer.
Mathieu
PS : Si tu n’es pas Anglophobe, je te conseille la lecture suivante
(Continuous Integration)
Je comprends tout à fait le problème que tu avais, et je comprends
aussi que les fixtures produites dans un premier temps puisse entrer
en conflits avec celles nécessaires aux nouveaux tests : j’avoue avoir
le même genre de problèmes dans une situation assez proche. Nous avons
choisi de gérer le problème avec une approche analogue dans un premier
temps, tout en restant conscients que nous avons un travail de
rénovation à faire concernant notre environnement de tests (je parle
des données nécessaires). En clair, j’étais surpris qu’on puisse dire
que modifier des tests peut introduire des erreurs. Avec ton éclairage
j’ai mieux compris. Et je maintiens que ce genre de contournement
s’apparente à du “Bad Smell” dans le sens où les tests tiennent tout
autant du développement logiciel que l’application testée : ce qui est
vrai pour celle-ci reste vrai pour sa suite de tests. Du coup je
trouvais l’idée de Yann pas si bête !
Voilà, maintenant, je ne tiens pas à polémiquer, et suis
trèsintéressé par les liens proposés plus hauts.
Tongman, le problème que j’exposais c’est que modifier mes fixtures
(en rajoutant des donnnées) pour effectuer un nouveau test risque de
modifier les résultats de mes autres tests servant à vérifier des
méthodes que je n’ai pas modifiées.
Bonjour, juste pour vous dire que je suis en train de mettre en place
la solution décrite ici :
http://blog.inquirylabs.com/2008/05/26/simplifying-rails-fixtures-with-contexts/