Mon apprentissage de Ruby et Rails

[Sephi-Chan]

La liste des nations disponibles n'a-t-elle pas plutôt sa place en base de données ?

A priori c'est une liste qui ne changera pas. On sait jamais m'enfin ^^

L'utilisation d'une constante paraît donc appropriée.

Autre question toujours sur le DRY. J'ai des constantes qui reprennent les pattern de certaines regex (email par exemple), ça vaut la peine de créer un module "Regex" (plutôt qu'une classe vu que j'aurai pas de méthode dedans à priori) ?

Si vraiment il y a des regexp que tu utilises fréquemment, c'est une possibilité. Pour les emails, tu peux aussi utiliser une gem (à moins qu'un test simple mais inexact suffise, comme dans bien des cas).

Autre question sur l'inclusion des classes (modèles, controlleurs et helpers), tout est inclus sur chaque page ou bien l'inclusion se fait de façon sélective (exemple : inclusion que de la classe controleur appelée par le routeur) ? Comme y a beaucoup de "magic" dans Rails, c'est pas évident de deviner ce type de comportement et j'ai encore rien trouvé sur le sujet

Dans Rails, l'ensemble de l'environnement est chargé dans le processus (que ce soit Passenger ou des workers FCGI) au lancement de ce dernier (c'est pour ça qu'il faut relancer les workers lors d'un nouveau déploiement).

Pour Rails, je suis un peu dubitatif sur le développement dirigé par les tests. J'ai l'impression que pour certaines choses simples c'est une perte de temps et que ça ajoute encore une couche de code à maintenir pour pas grand chose. Fin, je vois pas trop la pertinence du processus en fait.

Il est clair qu'écrire et maintenir une suite de test est coûteux en temps, mais je pense que ça vaut le coup. Déjà parce qu'il est possible de développer une application (même riche en Javascript) sans jamais lancer le serveur Web, et aussi parce que ça permet d'exécuter des choses potentiellement longue en quelques instants.

Par exemple, on peut simuler des fragments de parties (en établissant un contexte initial) pour s'assurer qu'elle se déroule comme prévu. Dans un navigateur, ce serait affreusement long (ouvrir plusieurs navigateurs avec des utilisateurs différentes, cliquer, revenir, supprimer certaines données, etc.) alors que via un test d'intégration, ça se fait en une poignée de secondes, et on peut même forcer le hasard (via des stubs de Rspec ou de Mocha), faire avancer le temps (avec des gems comme Timecop), etc.

En somme, une suite de tests (unitaires et d'intégration) est très vite rentabilisée.

J'essaye d'être pragmatique et j'écris seulement les classes/méthodes importantes en TDD. Celles de moindre importance sont généralement testées après (pour documenter une fonctionnalité ou un bug, par exemple) et il m'arrive de ne pas tester. Je ne cours pas après le 100% de couverture de test.

Sinon, quelle Gem utilisez-vous pour vos tests, celle de base de Rails ou Rspec (ou autre ?) ?

J'utilise souvent Test::Unit mais je sais aussi utiliser Minitest (qui est intégré à Ruby) et Rspec. Je les ai tous utilisé plusieurs fois et les apprécie tous.

Pour mettre en place mes conditions de tests, je n'utilise pas les fixtures (bien trop pénibles à maintenir dans une application un peu complexe) mais Factory Girl.

J'utilise Capybara pour mes tests d'intégration (avec Capybara Webkit pour tester du Javascript).

Je m'efforce d'être pragmatique dans l'exécution des tests : une exécution un peu lente à cause des nombreux objets créés en base ne me dérange pas, je préfère ça que d'utiliser des mock à tour de bras (que je ne rechigne pas à utiliser quand je trouve ça pertinent). Tant qu'on reste dans la poignée de secondes, ça me va.

Sinon, j'ai pas encore lu grand chose sur la façon de documenter son code en Ruby. Des infos à ce sujet ?

RDoc est intégré au langage. C'est ce qui est utilisé pour générer la documentation de l'API de Ruby on Rails. Jette un oeil au code de Rails, tu verras à quoi ça ressemble. Il y en a d'autres (Yard, notamment) mais je n'en utilise aucun.

Désolé de vous bombarder de questions mais je me dis que vous aurez toujours de meilleures réponses à me donner qu'un moteur de recherche, surtout que les ressources sur Rails sont éparses et pas toujours actualisées.

Ce genre de sujet est fait pour ça. En plus de pouvoir répondre à tes questions, ça permet également d'intéresser les curieux.