Web Event Lille #1

By Guilhem Lebon , on29/10/09

0 comments

Vous connaissez certainement Sarah Hans , alias la Geekette . Et bien vous connaissez du coup la personne qui a eue la bonne idée d'organiser le premier Web Event Lille (oui parce qu'il devrait y en avoir plusieurs).

Le Web Event Lille, c'est :

  • Un barcamp sur les métiers du web
  • Des discussions plus générales autour d'un verre
  • Un restaurant pour terminer la journée

Les horaires annoncés sont compris entre 14h et 18h, restaurant non compris. Il n'y a pas encore d'indication quant au lieu exact (pas plus que sur le nom du restaurant).

Vous pourrez rester informés sur la page Facebook de l'évènement ou sur le site du Web Event Lille .

Plage.fr premier prix technique des Ecommerce Stars

By Quentin Tousart , on15/10/09

1 comment

Mercredi 14 octobre, au salon de la VAD à Lille, se sont tenues les e-commerce stars , afin de récompenser les plus belles réalisations internet d'entreprise du Grand Lille et de l'euro Région.

Deux critères ont été retenus: celui de la technique et celui du contenu.

Et surprise! le vainqueur dans la catégorie technique est... : plage.fr , un site de décoration d'intérieur utilisant d'ores et déjà la solution open source forgeos commerce !

Alors si vous aussi, vous désirez remporter les e-commerce stars, faite confiance à Webpulser ;)

Forgeos Commerce - Salon E-commerce - A8.0 - Autoroute de l'innovation

By Quentin Tousart , on02/10/09

3 comments

Bonjour à tous,

Nous revenons du salon e-commerce . Cette édition fut l'occasion de présenter Forgeos Commerce .

Nous avons réalisé de nombreuses démonstrations tout au long de ces 3 journées. Nous avons reçu un accueil très favorable ainsi que de nombreuses félicitations. L'interface simple et intuitive de Forgeos Commerce a d'ailleurs été largement plébiscitée.

Nous remercions tous les visiteurs qui sont passés nous voir ainsi que nos partenaires du stand de l'Autoroute de l'innovation .

Cet entouthiasme à l'égard de Forgeos Commerce nous encourage donc à mettre les bouchées doubles pour continuer dans cette voie de l'innovation.

Une bêta privée de Forgeos Commerce sera disponible sur demande dans quelques jours. Si vous êtes intéressés n'hésitez pas à nous demander une invitation .

La roadmap des prochains mois et les dates de sortie de la première release suivront bientôt.

Lancement d'activité : Coaching e-commerce

By Guilhem Lebon , on07/09/09

0 comments

Webpulser et toute son équipe sont heureux de vous annoncer l'ouverture d'une nouvelle activité au sein de l'agence : le coaching e-commerce.

Internet ne cesse d'évoluer et ses pratiques aussi. Les sites ont longtemps étés la focalisation première de toutes les sociétés. Un site internet, aussi puissant soit-il est désormais relégué au second plan. Il ne s'agit plus que d'un outil permettant d'accroître l'efficacité commerciale et l'image de marque des entreprises en soutenant une stratégie marketing. En créant ces outils techniques et avec l'avènement de Forgeos Commerce, Webpulser poursuit sa démarche d'ouverture en vous donnant accès à ses compétences et à son savoir-faire.

Vous accompagner dans toutes vos démarches est l'aboutissement de notre volonté de toujours mieux vous permettre de vous implanter et de profiter des nombreuses opportunités d'internet.

 

Nouvelle offre de mini-sites

Jusqu'à présent, Webpulser concentrait son activité sur des sites complexes, le plus souvent réalisés sur-mesure. Pour les besoins des services de communication, une nouvelle offre a été développée : Les sites événementiels. Ces sites ont une courte durée de vie et ne contiennent que quelques pages. Ils sont idéaux pour supporter des mini-jeux et pour récolter des adresses email.

 

Forgeos Commerce et le référencement naturel

La solution e-commerce Forgeos Commerce a été développée en répondant aux besoins des professionnels du référencement. En offrant des fonctionnalités qui permettent de faciliter le travail des consultants marketing, Webpulser réduit les tarifs du référencement sur les sites conçus avec Forgeos Commerce !

Découvrez rapidement nos services et nos missions et n'hésitez pas à nous contacter pour plus d'informations.

Développement par les tests avec Ruby on Rails - Partie 2 : Introduction à RSpec

By Romain Endelin , on19/06/09

0 comments

Dans l'article précédent vous avez appris à rédiger et à tester des spécifications fonctionnelles grâce à Cucumber, nous allons maintenant nous interesser à l'outil RSpec, grâce auquel vous pouvez tester des parties de code isolément les unes des autres.

RSpec n'est pas spécifique à Rails, il s'agit d'un outil de Ruby. Cependant il existe le plugin RSpec on Rails pour l'adapter parfaitement à la structure MVC de Rails. Pour ceux qui auraient oublié le tutorial précédent, je vous rappelle que dans le BDD les tests doivent être rédigés avant le développement du code, et lui servir de support. C'est donc ce que vous allez procéder avec RSpec.

Développer en Outside-In

Beaucoup de développeurs Ruby on Rails sont habitués à développer le modèle, puis le/les contrôleur(s) associé(s), et finir par les vues. Cette approche est plus sûre car elle permet de s'assurer rapidement que le modèle fonctionne, puis d'avoir le support du contrôleur pour développer et tester les vues. Cependant, c'est souvent en développant les vues que l'on se fait une idée du comportement de l'application, et donc de ce que le contrôleur doit fournir, et sur le même principe c'est en développant le contrôleur que l'on découvre le rôle du modèle. Si l'on décidait de ne pas tester l'application avec notre navigateur durant le développement, cette approche semble bien plus efficace et proche des besoins du client. Je sais ce que vous allez me dire : "il est suicidaire de développer une application sans la tester !", et ce n'est pas moi qui vais vous contredire. Mais je n'ai jamais parlé de ne pas la tester en cour de développement, simplement ces tests ne se feront pas avec votre navigateur et vos tests cucumber (qui attendront la fin d'un scénario), mais avec RSpec !

Anéfé, RSpec apporte la solution car il va nous permettre de tester isolément les uns des autres Vue, Contrôleur et Modèle.

Utiliser RSpec

Première étape, vous allez installer RSpec et RSpec on Rails. Pas forcément le plus intéressant je sais, mais c'est un passage obligatoire.

Vous devrez commencer par installer les Gems :

    * [sudo] gem install rspec

    * [sudo] gem install rspec-rails

    * [sudo] gem install webrat

Eh oui, ici aussi webrat va nous être utile, vous n'allez pas tarder à le découvrir.

Une fois ces Gems installés, générez une application (ou reprenez le blog du premier exemple) et placez vous à sa racine.

Tapez ensuite la commande :

./script/generate rspec

Un répertoire spec a été généré à la racine du projet. Ce répertoire reprend la structure de app/ : des répertoires views, models et controllers. Les tests se font par fichier, Pour tester un fichier vous reprendrez la même arborescence que ce fichier depuis le répertoire spec, et vous ajouterez _spec.rb au nom du fichier d'origine. Par exemple le test de app/views/articles/index.html.erb sera le fichier spec/views/articles/index.html.erb_spec.rb, app/controllers/articles_controller.rb donnera spec/controllers/articles_controller_spec.rb, et app/models/article.rb donnera spec/models/article_spec.rb

Pour lancer vos tests, vous pouvez lancer une de ces commandes :

    * rake spec #lance tous les tests

    * rake spec:views #tous les tests des vues

    * rake spec:controllers #tous les tests des contrôleurs

    * rake spec:models #tous les tests des modèles

    * ./scrip/spec --color --format=<specdoc, html ou progress> <path vers le test>

Pour la dernière commande, la lecture des fichiers de test sera récursive : si vous passez spec vous aurez tous les tests, spec/views seulement les vues, spec/views/article/index.html.erb_spec.rb ne lancera que les tests de l'index...

Configuration

Pour utiliser RSpec vous devrez configurer un fichier très important : spec/spec_helper.rb. Il s'agit du fichier de configuration de RSpec.

Chacun de vos fichiers de test devra commencé par la ligne require File.expand_path(File.dirname(__FILE__) + '/../spec_helper'). Evidemment le nombre de ../ est à adapter selon le répertoire où se trouve votre test, pour arriver à la racine de spec/ où se trouve le fichier.

Voici à quoi doit ressembler spec_helper.rb

# This file is copied to ~/spec when you run 'ruby script/generate rspec'

# from the project root directory.

ENV["RAILS_ENV"] ||= 'test'

require File.dirname(__FILE__) + "/../config/environment" unless defined?(RAILS_ROOT)

require 'spec/autorun'

require 'spec/rails'

 

require 'webrat'

require 'webrat/core/matchers/have_tag'

 

Spec::Runner.configure do |config|

    config.use_transactional_fixtures = true

    config.use_instantiated_fixtures  = false

    config.fixture_path = RAILS_ROOT + '/spec/fixtures/'

end

Développer son application avec RSpec

La structure d'un test

Les tests de la vue, du contrôleur et du modèle sont assez différents, mais ont une syntaxe commune (je vous rappelle d'ailleurs RSpec existe aussi pour Ruby, indépendamment de Ruby on Rails).

Commençons par définir un test. Un test a à peu près la même structure qu'une méthode en Ruby ou qu'une définition d'étape dans Cucumber. Il se décrit ainsi :

it ”should...” do

# mon test, il peut contenir à la fois des méthodes spécifique et du code Ruby

end

Lors du lancement des tests, tous les tests sont effectués les uns après les autres (les données sont réinitialisées entre chaque test), donc contrairement à des méthodes vous ne pourrez pas appeler un test depuis un autre. De toute manière vous n'en avez pas besoin.

Cependant, vous aurez sans doute besoin d'initialiser des données identiques avant chaque test, par exemple si vous voulez tester les méthodes d'un client dans un test de modèle, vous devrez d'abord créer ce client. Il existe alors une méthode simple pour éviter toutes ces redondances : le before(:each) :

before(:each) do

#initialisation des données, vous ne testez rien ici

end

Le code de before(:each) sera appelé avant chaque test (il existe aussi before(:all), after(:each) et after(:all) mais ils ont rarement un intérêt concret).

Un test se fait par la méthode should, par exemple my_object.name.should == “my name“. Comme dans cucumber, de nombreuses méthodes existent déjà pour faciliter les tests, par exemple response sera utilisé dans les tests des vues pour désigner la page, et Cucumber vous proposera ensuite des « matchers » plus puissants que le ==, par exemple response.should contain(”Hello World”) signifie que le html devrait contenir Hello World quelque part.

Il s'agit là des éléments communs à tous les tests. Bien sûr la rédaction de test ne se résume pas à des before(:each) et à la définition de tests non implémentés, le reste vous sera présenté dans la suite de ce tutorial.

Les tests des vues

Lorsque vous rédigerez le test de la vue, vous préciserez "ma vue devrait lister tous les articles", "ma vue devrait fournir un lien pour créer un article"... Et lui fournirez toutes les valeurs qui vous sont nécessaires, sans passer par le contrôleur.

Par exemple, si vous voulez lister tous les articles, vous aurez besoin d'une variable @articles, en temps normal initialisée par le contrôleur. RSpec vous permettra de simuler le contrôleur pour assigner une valeur à @articles en utilisant assigns[<variable_utilisee_dans_la_vue>] = <variable_declaree_dans_le_test>. Un exemple sera plus clair :

describe "articles/index.html.erb" do

    before(:each) do

        @articles_test = [] #attention vous devez bien dissocier la vue de son test : @articles_test est déclarée dans ce test

        #la vue est un autre fichier et ne connait donc pas les variables utilisées dans le test

        assigns[:articles]=@articles_test #en revanche, assigns[:articles] initialisera @articles dans la vue

    end

end

Un problème se pose : vous voulez tester un tableau d'articles, pas un tableau vide. Nous allons donc utiliser des mock_model pour remplir le tableau.

Les tests de vue les plus fréquents

En testant une vue, vous serez amenés à tester que la page html générée contiendra un contenu spécifié.
Vous utiliserez donc des tests tels que :

  • response.should contain('test')
  • response.should_not contain('test')
  • response.should have_selector('form') do |form|
        form.should have_selector('input[type=text]', :name => 'my_field')
    end

Conclusion

Je vous ai expliqué la logique de base de RSpec, mais vous n'êtes pas encore en mesure de développer en TDD avec RSpec. La suite de cet article s'attardera sur des fonctionnalités plus avancées et vous permettra de réaliser des tests sur les contrôleurs et modèles.