pourquoi est-ce que l'on est passé au framework rspec2 ?
C'était une autre époque. Aujourd'hui, le choix entre rspec et le framework de tests officiel de Rails est principalement une question de goûts (la syntaxe n'est pas la même), mais les deux sont très complets et ont copié de l'autre tout ce qu'il y avait d'intéressant.
si je recommence de zéro, on pourrait à nouveau utiliser le framework de rails ?
Oui, pas de soucis.
est-ce que les tests qui étaient dans le dossier spec étaient vraiment trop cassé ? est-ce que je devrais recommencer de zéro ? étaient-ils utiles ?
Les tests n'étaient pas très cassés, j'aurais pu les corriger en moins d'une heure. Par contre, ils n'étaient pas vraiment utiles. Je ne pense pas qu'ils n'aient jamais trouvé le moindre bug. La couverture de tests était vraiment très faible et c'était surtout les mêmes pages que je regardais quand je développais des nouvelles fonctionnalités. Si la page d'accueil casse, je m'en rendais compte très très rapidement, sans avoir besoin de tests automatisés pour ça.
Mais, sans aucun tests, il est impossible de prendre la décision de fusionner les merge request.
Pour info, même avec des tests, je pense que ça reste compliqué de prendre la décision. Il faut avoir une bonne couverture de tests pour que ça aide et, pour ça, il faut y passer beaucoup de temps à écrire des tests, temps qui serait probablement plus utile ailleurs. Et il faut aussi faire très attention à la version de Ruby : on a une version de Ruby assez ancienne en prod et j'ai plusieurs fois dû faire des reverts à cause de ça.
[^] # Re: Comment débuter ?
Posté par Bruno Michel (site web personnel) . En réponse à l’entrée du suivi Pouvoir tester les mises à jour de maintenance. Évalué à 4 (+0/-0).
C'était une autre époque. Aujourd'hui, le choix entre rspec et le framework de tests officiel de Rails est principalement une question de goûts (la syntaxe n'est pas la même), mais les deux sont très complets et ont copié de l'autre tout ce qu'il y avait d'intéressant.
Oui, pas de soucis.
Les tests n'étaient pas très cassés, j'aurais pu les corriger en moins d'une heure. Par contre, ils n'étaient pas vraiment utiles. Je ne pense pas qu'ils n'aient jamais trouvé le moindre bug. La couverture de tests était vraiment très faible et c'était surtout les mêmes pages que je regardais quand je développais des nouvelles fonctionnalités. Si la page d'accueil casse, je m'en rendais compte très très rapidement, sans avoir besoin de tests automatisés pour ça.
Pour info, même avec des tests, je pense que ça reste compliqué de prendre la décision. Il faut avoir une bonne couverture de tests pour que ça aide et, pour ça, il faut y passer beaucoup de temps à écrire des tests, temps qui serait probablement plus utile ailleurs. Et il faut aussi faire très attention à la version de Ruby : on a une version de Ruby assez ancienne en prod et j'ai plusieurs fois dû faire des reverts à cause de ça.