Je suis à travailler sur une intégration avec PayPal sur un projet en Ruby on Rails. Pour ce faire j’ai donc téléchargé le Gem PayPal développé par ELC Technologies. Les vérifications préliminaires sont prometteuses, le Gem se comporte tel que souhaité et fidèle à la philosophie de Rails il se concentre sur le résultat faisant fi de la configuration
au profit de la normalisation. Au moment d’entamer le code qui vas assurer la modification du profil des utilisateurs en fonction de l’abonnement sélectionné j’arrive au point épineux des tests. Je ne vais certainement pas écrire une portion si important du site sans m’assurer qu’elle se comporte adéquatement. Le problème est simple, le Gem sers précisément à interagir avec le site externe qu’est PayPal et je ne désire pas dépendre de la présence de leur serveur pour exécuter mes tests fonctionnels. Après quelque recherches dans la base de code du Gem lui même j’ai trouvé ma réponse… et je dois admettre que la solution de Mr Luetke au problème est très… ingénieuse.
Dans les tests du Gem, on trouve un fichier nommé « method_mock.rb » qui est utilisé dans les tests unitaires du Gem. Après plusieurs lectures et un merveilleux mal de tête j’ai finalement accroché sur la première ligne du fichier… « class Module ». Une révélation, un de ces « Ah Moment » dont je vous parlais l’autre jour. Le code du fichier sers à remplacer temporairement le code de n’importe quelle méthode de n’importe quel module (et donc par extension classe) du langage… par exemple, le code nécessaire pour se connecter à un serveur distant. Mon problème est résolu… pas le même moyen qu’à utilisé Mr Luetke pour tester son Gem. La solution est élégante et permet beaucoup d’autre utilisations, comme par exemple fournir un fichier de la suite de test en remplacement d’un fichier externe. Bon, j’y retourne, les doigts me démangent d’avance encore un peu… un test à la fois (ou comme chanterais les américains: « Test by test… oh baby… gonna get software that will works! »)
