On a beaucoup écrit sur le développement des moteurs et sur l'utilisation d'une application fictive pour les tests.
Dans notre cas, nous développons un moteur qui n'est pas une entité autonome, mais qui dépend d'une véritable application Rails 3. Nous voulons toujours que ce code vive dans un moteur, et ne devienne pas une partie de l'application, parce que le travail du moteur est d'importer des données d'un ancien système qui a ses propres tables et mappages de modèles, et nous voulons éventuellement le supprimer à nouveau.
Les correspondances de données entre les anciennes tables et le nouveau schéma sont complexes, et nous voulons TDD (à l'aide de rspec) le moteur.
- J'ai suivi Le livre de Jose Valim "Crafting Rails Appliations" (en anglais) et j'utilise le enginex gem .
- J'ai remplacé
/spec/dummy_app
avec un sous-module git pointant vers une véritable application Rails 3. - J'ai du mal à charger les modèles depuis le moteur (erreurs de symboles non définis), car le fichier Gemfile de l'application réelle ne pointe pas vers le moteur, et je ne peux pas non plus modifier le fichier Gemfile de l'application réelle.
config/application.rb
pour exiger le moteur (c'est ce que fait l'application factice, comme expliqué aux pages 15 et 16 du livre). - J'inclus le moteur
lib
dans le chemin de chargement$:
enspec_helper
et les chemins sont disponibles. - La mise en place de la
require
enspec_helper.rb
n'a pas résolu le problème. - Je me demande s'il existe une API interne à Rails (ou un patch intelligent) pour s'accrocher à la séquence de démarrage de l'application réelle et demander le moteur, sans avoir à modifier le code de l'application réelle (puisqu'il se trouve dans un sous-module).
- Un autre problème dont je ne suis pas totalement sûr est que j'ai 2 Gemfiles (une dans le moteur et une dans l'application), et quand le moteur est actif, elles devraient toutes les deux être utilisées.
Réflexions ?