Langages/Ruby/Rails/Tests/Strategies

Un article de Agora2ia.


Sommaire

Stratégies de test

En plus des trois couches MVC qui caractérisent Rails ils y en a d'autres :

  • routing
  • persistance
  • base de données

Avoir une stratégie de tests qui traverse toutes ces couches est donc très couteux (en temps) : c'est ce que l'on appelle le Direct Model Access (DMA). Une autre technique consiste à


DMA (Direct Model Access)

Les tests sont executés en manipulant directement les objets (comme par exemple la création) sans passer par les requêtes web. On gagne donc beaucoup de temps, mais cette extreme isolation ne donne aucune garantie sur le fonctionnement réel de l'application (comme par exemple la création d'un objet via le formulaire web)


In-Browser

A l'autre extrémité, des outils comme Selemium ou Watir, utilisent les navigateurs existants. Les tests sont réalisés en simulant les interactions des utilisateurs avec un navigateur web. Une fois que le comportement spécifié dans le test, un navigateur est ouvert et les assertions faites dedans.

Dans ce cas, un test qui passe confère de sérieuses garanties, par contre cela à un coût en terme de durée d'exécution.


Simulated Browser

C'est le cas de Webrat.

Cette stratégie repose sur l'utilisation des pages web vraiment générées par l'application mais une librairie externe (Nokogiri dans le cas de Webrat) interprète le code de la page web (au lieu des navigateurs).

Cela à l'avantage d'être indépendant du navigateur et plus rapide. Pour cela, on utilise l'API de framework pour faire les appels.

Dans le cas de Webrat, on utilise les méthodes suivantes :

visit user_path(@user)
click_link @company.name