suite de Paris On Rails 2008 première partie

Tests d’interface Web avec Rails par Jean Michel Garnier

Jean Michel a commencé par une présentation de RSpec, et a enchaîné sur le TDD JavaScript : Screw Unit pour tester son JavaScript.
Ensuite il a continué sur les tests fonctionnels (plus de la moitié des erreurs apparaissent dans les spécifications fonctionnelles), en présentant Cucumber (ou Rspect Story Runner), framework de tests fonctionnels pour Ruby On Rails (qui va être intégré dans RSpec) , mais peut être utilisable en Java ou .Net via JRuby ou IronRuby.
Cucumber permet un formalisme à la RSpec, aussi bien que FIT (tableaux exécutables).
Pour les tests d’acceptance Web, WebRat (Ruby Acceptance Testing), basé sur HTMLUnit (Java), s’utilise via JRuby, et propose une interface pour plusieurs types de session; dont Webrat::SeleniumSession, une des plus avancées.

Enfin, sont évoqués les serveurs d’intégration continus pour Ruby, comme CruiseControl.rb et Hudson, via JRuby.

Ce qui nous amène à la seconde présentation orientée tests fonctionnels du jour (Gilles t’aurais du venir ! )

Tests d’acceptance Web à forte valeur ajoutée (par Philippe Hanrigou , de ThoughtWorks)

Les tests d’acceptance Web avec Selenium ou Watir sont compliqués à maintenir, ou sont trop longs à exécuter.
Fit est parfait pour tester le backend, tests du code métier, mais pas pour IHM.
Philippe nous décrit la difficulté de maintenir des tests d’acceptance, et insiste sur le fait que l’ensemble des développeurs de l’équipe doivent prendre en compte la difficulté à maintenir et écrire des tests d’acceptance web, pas juste les nouveaux venus sur le projet !

Pour faciliter le travail, l’outil qu’il utilise est Selenium Rspec Report, qui ajoute des fonctionnalités à RSpec : un maximum d’informations sont remontées : l’état du DOM lorsque le test a planté, un screenshot, les logs Selenium, pour pouvoir mieux suivre les tests d’acceptance et pourquoi ils ont échoué.
Pour accélérer ces tests,q ui peuvent être longs, on peut utiliser Selenium Grid pour paralléliser l’exécution des tests.

Philippe a aussi expliqué que les fixtures rails n’étaient pas la meilleure solution pour initialiser l’état lors des tests fonctionnels.
Pour pouvoir initialiserle domaine métier, pas juste le modèle, il a introduit Object Mother : design pattern pour tests d’acceptance implémenté par Object Daddy et Factory Girls, opposé aux Mocks car contient tout le domaine métier, pas juste un objet !
En conclusion, les tests d’acceptance Web sont difficiles, mais pas insurmontables : il faut paralléliser (avec Deep Test ?), isoler, être le plus précis possible.

Rails Performance par Michael Koriaski, membre de l’équipe core rails

Tout d’abord, a t on besoin d’optimiser ?Si oui, se concentrer sur quels axes d’amélioration ?

A priori, monter en puissance avec l’achat de nouveau matériel est ce qui coûterait le moins cher (sauf si on s’appelle Google ou Microsoft!)

Pour savoir ce qu’il faut optimiser, il faut se baser sur la performance perçue par l’utilisateur, et on se rend compte que le temps de chargement d’une page html représente 0.5% du temps que l’utilisateur attend; les images, les javascript, les CSS, etc… pèsent beaucoup plus lourd dans la balance !

Ainsi, on doit se concentrer sur sur le serveur front qui sert les fichiers statiques !

Enfin, on peut se poser des questions sur son appli rails :

• Qu’est ce qui est lent ? (on utilise des outils de benchmarks pour le savoir, avec éventuellement un Ruby instrumenté comme Ruby ENterprise Edition pour connaître les allocations des objets)
• Pourquoi est ce lent ? (essayer d’optimiser les allers retours sur le réseau en se servant des entêtes HTTP, et les Entity tags ce que Rails 2.2 peut faire, on dit au navigateur : “cest bon, t’as déjà la bonne version en cache !”
• Rendre plus rapide (contrer le syndrome des N+1 requêtes en remaniant ses boucles et relations, régler le Garbage Collector de Ruby (augmenter sa tailel de départ par exemple) , etc…

Interview de David Heinemeier Hansson à Chicago, créateur de Ruby on Rails, via Ichat

Rails 2.2 a de meilleures performances par rapport aux versions précédentes, en particulier l’équipe de développement s’est concentrée sur HTTP (Etag, MemCache, etc..)
Rails 2.2 est compatible avec JRuby et Ruby 1.9, l’équipe essaie de faire fonctionner Rails sur le maximum de serveurs Web (via Rack).
Beaucoup de ménage a été fait, toute le code déprécié a été enlevé.

Liquid : moteur de templates en Ruby par Didier Lafforgue

Inspiré de smarty (issu de la communauté PHP)
Présentation des drops, filtres
S’installe en Gem ou en plugin.
Didier a évoqué un service qui a l’air excellent : hébergement (+git) et déploiement Rails : Heroku.com

La fin

Enfin Thomas Lissajou a amené un débat de clotûre sur le thème : “Agile Web Development with Rails, et vous ?”

Et bien, on découvre qu’il y a 2 groupes dans la communauté Rails : ceux qui en font et en sont convaincus (TDD, tests d’acceptance) et ceux qui considèrent que c’est réservé aux autres projets, car ils n’ont pas le temps ni les moyens; il y a beaucoup à parier que ces personnes, au fil de leur carrière ne tarderont pas à en être convaincu !

J’ai été ravi d’assister pour la 1ère fois à ParisOnRails, vivement l’an prochain !

Tags: Agile Programming, Ajax, ria, ruby

This entry was posted on Monday, December 1st, 2008 at 11:21 pm and is filed under Agile. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.