Choses à faire » Développement

Easyb, Behavior Driven Development

Killian Ebel — Tue, 02 Mar 2010 10:13:22 +0000

Pour rappel, le concept de Behavior Driven Development propose de se focaliser sur le comportement attendu de l’application plutôt que sur les tests. Ces comportements peuvent être décrits soit sous la forme de spécifications, soit sous la forme d’histoires !

Installation d’Easyb

Easyb est un outil permettant d’implémenter le BDD dans un projet Java, bien que le code à écrire pour rédiger vos spécifications sera du Groovy, dont la syntaxe est plus légère (plus agile) que Java. Il est comparable à l’outil specs en Scala ou encore RSpec en Ruby.

Pour l’intégrer à votre projet, vous disposez de multiples possibilités : ligne de commande, Ant, Maven ou encore l’intégration avec les IDE IntelliJ et Eclipse.

Il m’a été impossible d’installer le plugin Eclipse, l’adresse du plugin donnée sur le site officiel n’ayant plus l’air d’exister ! Je me suis donc penché sur la solution Maven. Créons donc le projet :

mvn archetype:create -DgroupId=fr.chosesafaire -DartifactId=easyb -Dpackagename=fr.chosesafaire

Editons le fichier de projet pom.xml pour y inclure Easyb, qui sera appelée lors de la phase test :




    UTF-8


4.0.0
fr.chosesafaire
easyb
jar
easyb
0.0.1
Test de Easyb
http://www.chosesafaire.fr


    
        
            org.apache.maven.plugins
            maven-compiler-plugin
            
                1.5
                1.5
                UTF-8
            
        
        
            org.easyb
            maven-easyb-plugin
            0.9.6
            
                
                    
                        test
                    
                
            
        
    



    
        junit
        junit
        4.7
        test

Nous développerons dans cet exemple une classe HelloMachine, qui n’a pour but que de renvoyer « Hello » et de stocker le fait d’avoir été appelée. Voici le scenario, à placer le fichier src/test/easby/HelloMachineStory.groovy, répertoire qui peut être facilement paramétré depuis le fichier Maven :

import fr.chosesafaire.HelloMachine

/**
 * Calling the HelloMachine !
 */
scenario "calling the hellomachine", {
    given "an hellomachine", {
        machine = new HelloMachine()
        hello = "Hello"
    }

    when "sayHello is called", {
        sayHello = machine.sayHello()
    }

    then "hello should be returned", {
        sayHello.shouldBe hello
    }

    and "then the machine should have been called", {
        machine.isCalled().shouldBe true
    }
}

Et enfin notre classe métier :

package fr.chosesafaire;

public class HelloMachine {
    private Boolean called = Boolean.FALSE;

    public String sayHello() {
        called = Boolean.TRUE;
        return "Hello";
    }

    public Boolean isCalled() {
        return called;
    }
}

Il ne reste qu’à lancer la compilation et les tests :

mvn compile test

Si vous n’avez pas Groovy d’installé, Maven le fera pour vous, car c’est une dépendance d’Easyb. Le résultat dans la console devrait être le suivant (bien qu’il soit possible de générer des rapports HTML !) :

[java] Running hello machine story (HelloMachineStory.groovy)
[java] Scenarios run: 1, Failures: 0, Pending: 0, Time Elapsed: 0.313 sec
[java] 1 behavior run with no failures

Ceci n’est qu’une brève introduction, j’espère que vous comprendrez l’intérêt d’un tel outil en étudiant plus en détail les fonctionnalités ! Voici une liste de liens utiles :

Articles liés :

cachedLoad(), un plugin de cache pour jQuery

Pierre Quillery — Tue, 26 Jan 2010 14:00:17 +0000

Aujourd’hui, pour changer un peu de notre habituel programme sur Ruby on Rails, je me propose de revenir sur un article que j’ai publié il y a quelques mois qui parlait des propriétés window.sessionStorage et window.localStorage présentes dans la spécification HTML 5. Nous allons exploiter la première pour améliorer de façon transparente les performances d’un site dans les navigateurs compatibles (webkit / gecko pour l’instant).

L’idée est donc de créer un plugin pour jQuery qui va se substituer au chargement Ajax classique et stocker dans la mémoire du navigateur un bout de page pendant la durée de la session. Le site que j’ai équipé de ce système charge de cette façon 3 ou 4 éléments sur chaque page visitée (le pied de page, un bloc de connexion, un moteur de recherche, etc.). À l’instar des cookies, ce cache n’est accessible que sur un seul vhost.

Bien sûr, les navigateurs qui ne supportent pas cette propriété utiliseront un chargement classique, de la même façon qu’ils le faisaient auparavant. Concrètement, il suffit généralement de remplacer votre appel à la méthode ajax de jQuery pour bénéficier du cache.

Ainsi $('#element').ajax('http://www.google.fr'); va devenir $('#element').cachedLoad('http://www.google.fr');. Vous pouvez également passer les paramètres habituels de la fonction load().

Enfin, pour supprimer volontairement le cache associé à un div, il vous suffit d’appeler la méthode cachedLoad() sans aucun paramètre.

Voilà, j’espère que ce petit plugin vous sera utile !

/**
	cachedLoad 1.0
	Pierre Quillery
    http://www.chosesafaire.fr/2010/01/cachedload-un-plugin-de-cache-pour-jquery/
 
	@param url string 
		Url à charger
	@param data object
		Paramètres à passer à la requête
	@param callback function 
		Fonction de callback à appeler éventuellement après le chargement
	
	Ce plugin permet d'utiliser la fonctionnalité html5 sessionStorage disponible 
	dans les navigateurs récents et ainsi éviter de multiplier les requêtes inutiles
	sur le serveur pour les bouts de page statiques (pied de page, formulaires de
	connexion etc.).
	
	*Si aucun paramètre n'est passé*, cela a pour effet de supprimer le cache
	associé à l'élément visé par le sélecteur.
	
	Voici la documentation "mozilla" :
	https://developer.mozilla.org/en/DOM/Storage#sessionStorage
	
	Pour les navigateurs n'implémentant pas cette fonctionnalité, on fait un 
	chargement classique.
	
	L'utilisation est calquée sur la méthode "load()" de jQuery
	(http://api.jquery.com/load/) : 
	
	$('#mon_div').cachedLoad('http://www.google.fr', function() { 
		alert('ok!'); 
	});
	
	$('#mon_div').cachedLoad('http://www.google.fr', {data:"data"}, function() { 
		alert('ok avec des paramètres!'); 
	});
	
	// Pour supprimer le cache
	$('#mon_div').cachedLoad();
	
	
	ATTENTION 
	==============================================================================
	Il est nécessaire que l'attribut ID du conteneur soit défini, car il est 
	utilisé pour définir une clé unique dans le tableau du sessionStorage. S'il 
	n'est pas	défini, on fera un appel Ajax classique et les données ne seront
	tout simplement pas mises en cache.
	==============================================================================
	
*/
jQuery.fn.cachedLoad = function(url, data, callback) {

	// Pour chaque appel du plugin ...
  return this.each(function() {
  	
  	// On récupère le contexte
		var self = $(this);
		var storage = window.sessionStorage; 

		// Est-ce qu'une URL a bien été passée en paramètre ?
		if(url) {
	
			// On autorise la syntaxe sans "data", comme jQuery
			if(typeof(data) == 'function') { callback = data; data = {}; }
			// Options par défaut
			data 			= data 			|| null;
			callback 	= callback 	|| function(){};
	
			// Si le sessionStorage est disponible et que l'élément a bien un id ...
			if(storage && self.attr('id') != '') {
		
				// On cherche le bout de page dans le cache
				var cache = storage['cachedLoad_' + self.attr('id')];

				// Le bout de page existait, on va l'afficher puis exécuter le callback
				if(cache) {
					self.html(cache);
					if(window.console && console.log) 
						console.log("cachedLoad : ", url);
					callback();
			
				// Le bout de page n'était pas en cache
				} else {
					// On le charge, on le met en cache, puis on appelle le callback
					self.load(url, data, function(r) {
						storage['cachedLoad_' + self.attr('id')] = r;
						callback();
					});
				}
	
			// Si le sessionStorage n'est pas disponible, on fait un appel classique
			// à la méthode load() de jQuery.
			} else {
				self.load(url, data, callback);
			}
		
		// Si aucune URL n'a été passée en paramètre, cela signifie que l'on
		// doit supprimer le cache
		} else {
		
			if(window.sessionStorage && self.attr('id') != '') {
				// On supprime l'entrée du cache pour forcer le futur rechargement
				delete storage['cachedLoad_' + self.attr('id')];
				if(window.console && console.log) 
					console.log("cachedLoad supprimé pour : ", self.attr('id'));
			}
			
		}
			
	});
};

Articles liés :

Mocks et Multithreading

Killian Ebel — Fri, 22 Jan 2010 12:45:09 +0000

Afin de compléter la série d’articles sur les tests logiciels, voici une méthode permettant de tester efficacement une application « concurrente ».

Java et Multithreading

Premièrement, il est important de comprendre le fonctionnement de l’interface Callable en Java ; une interface similaire à Runnable, à la différence près qu’un thread Callable renvoie une valeur lors de son exécution.

Ensuite, la classe utilitaire Executors, utile pour créer des pool de Threads, des pool de Threads périodique ou encore transformer un Runnable en Callable.

Enfin, l’interface Future, qui permet de stocker le futur résultat d’un appel asynchrone. Ce résultat peut être obtenu en appelant la méthode get() de votre objet, appel qui peut être bloquant si le résultat n’a pas encore été reçu. Il est possible de spécifier un timeout qui lèvera une exception si la durée de l’appel est supérieur.

Dans notre exemple, nous utiliserons un pool de taille fixe (nombre maximal de Threads défini), qui instanciera des Future stockant le résultat d’un calcul.

Mocking et Multithreading

C’est EasyMock qui sera utilisé, de par sa capacité à rendre l’exécution d’un Mock Threadsafe. Mockito permet aussi de créer des Mocks Threadsafe ; voici une brève comparaison entre EasyMock et Mockito, mais qui donne clairement l’avantage à Mockito du point de vue syntaxique !

Mise en pratique

Premièrement, la classe principale :

import java.util.concurrent.Callable;
import java.util.concurrent.ExecutionException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.TimeoutException;

public class CalculMultiThread {
    private static final int THREAD_TIME_OUT = 10;
    private static final int POOL_SIZE = 5;

    private ExecutorService pool = null;

    public CalculMultiThread() {
        pool = Executors.newFixedThreadPool(POOL_SIZE);
    }

    public void setPool(ExecutorService pool) {
        this.pool = pool;
    }

    public void calculsParalleles(Integer op1, Integer op2, Integer op3, Integer op4) {
        final AdditionCallable additionCallable = new AdditionCallable();
        additionCallable.setOperande1(op1);
        additionCallable.setOperande2(op2);

        final SoustractionCallable soustractionCallable = new SoustractionCallable();
        soustractionCallable.setOperande1(op3);
        soustractionCallable.setOperande2(op4);

        final Future additionFuture = pool.submit(additionCallable);
        final Future soustractionFuture = pool.submit(soustractionCallable);

        try {
            final Integer resultatAddition = additionFuture.get(THREAD_TIME_OUT, TimeUnit.SECONDS);
            final Integer resultatSoustraction = soustractionFuture.get(THREAD_TIME_OUT, TimeUnit.SECONDS);

            System.out.println(op1 + " + " + op2 + " = " + resultatAddition);
            System.out.println(op3 + " + " + op4 + " = "  + resultatSoustraction);

        } catch (InterruptedException e) {
            e.printStackTrace();
        } catch (ExecutionException e) {
            e.printStackTrace();
        } catch (TimeoutException e) {
            e.printStackTrace();
        } finally {
            pool.shutdown();
        }
    }

    public static void main(String[] args) {
        CalculMultiThread calculMultiThread = new CalculMultiThread();
        calculMultiThread.calculsParalleles(5, 6, 8, 3);
    }
}

abstract class CalculCallable implements Callable {
    private Integer operande1 = null;
    private Integer operande2 = null;

    public void setOperande1(Integer operande1) {
        this.operande1 = operande1;
    }

    public Integer getOperande1() {
        return this.operande1;
    }

    public void setOperande2(Integer operande2) {
        this.operande2 = operande2;
    }

    public Integer getOperande2() {
        return this.operande2;
    }
}

class AdditionCallable extends CalculCallable {
	public Integer call() throws Exception {
		return getOperande1() + getOperande2();
	}
}

class SoustractionCallable extends CalculCallable {
	public Integer call() throws Exception {
		return getOperande1() - getOperande2();
	}
}

Le résultat de l’opération :

5 + 6 = 11
8 - 3 = 5

Enfin, les tests :

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;
import org.easymock.EasyMock;
import org.junit.Before;
import org.junit.Test;

public class CalculMultiThreadTest {
    private ExecutorService executorServiceMock;
    private CalculMultiThread calculMultiThread;

    @Before
    public void setUp() throws Exception {
        executorServiceMock = EasyMock.createMock(ExecutorService.class);
        calculMultiThread = new CalculMultiThread();
        EasyMock.makeThreadSafe(executorServiceMock, true);
    }

    @SuppressWarnings("unchecked")
    @Test
    public void testCallTasksInParallel() throws Exception {
        calculMultiThread.setPool(executorServiceMock);

        Future additionFutureMock = (Future) EasyMock.createMock(Future.class);
        EasyMock.expect(additionFutureMock.get(EasyMock.anyLong(), EasyMock.isA(TimeUnit.class))).andReturn(11);
        EasyMock.replay(additionFutureMock);

        Future soustractionFutureMock = (Future) EasyMock.createMock(Future.class);
        EasyMock.expect(soustractionFutureMock.get(EasyMock.anyLong(), EasyMock.isA(TimeUnit.class))).andReturn(5);
        EasyMock.replay(soustractionFutureMock);

        EasyMock.expect(executorServiceMock.submit(EasyMock.isA(AdditionCallable.class))).andReturn(additionFutureMock);
        EasyMock.expect(executorServiceMock.submit(EasyMock.isA(SoustractionCallable.class))).andReturn(soustractionFutureMock);
        EasyMock.replay(executorServiceMock);

        calculMultiThread.calculsParalleles(5, 6, 8, 3);

        EasyMock.verify(additionFutureMock);
        EasyMock.verify(soustractionFutureMock);
        EasyMock.verify(executorServiceMock);
    }
}

Voilà, ce n’est pas plus compliqué de tester du code multithreadé. Pour plus d’informations, vous pouvez toujours consulter les liens qui suivent, merci !

Articles liés :

La couche Modèle de Rails (Partie 3)

Pierre Quillery — Sun, 10 Jan 2010 14:32:26 +0000

Aujourd’hui, je me propose d’achever cette série par quelques explications concernant les fichiers de garniture (aussi appelés fixtures) ainsi que l’utilisation des filtres (on parle de named scope) pour faciliter la sélection de données.

Cet article fait partie d’une série sur le framework Ruby on Rails dont vous pouvez consulter le plan sur mon ancien site.

Il est également le dernier de la série de trois articles que j’ai publié sur l’implémentation de la couche Modèle de Ruby on Rails. Vous pouvez lire le premier article ou le second, si vous ne l’avez pas fait.

Les filtres (named_scope)

Ces filtres sont à mon avis une fonctionnalité très intéressante de Rails : ils permettent d’ajouter simplement un jeu de critères nommé à une requête SQL. Si on traduit le terme Anglais, il s’agit littéralement de « points de vue nommés » ; ce n’est pas très explicite, et c’est pourquoi je préfère le terme de « filtre » – il ne faut cependant pas les confondre avec les filtres de Contrôleur dont je parlais dans un précédent article.

Par exemple, imaginons que nous avons à notre disposition un magasin en ligne qui souhaite mettre en avant les produits qui sont les moins chers (dont le prix est entre 1 et 5 euros par exemple). Nous pourrions être tentés d’écrire ceci, par exemple :

Articles.find :all, :conditions => { :prix => [ 0 .. 5 ] }

Notez la syntaxe [ ... ], elle permet de spécifier un intervale de valeurs. L’inconvénient de cette façon de faire c’est que si par la suite nous voulons ajouter d’autres crtières de sélection (uniquement les articles de telle catégorie, uniquement ceux qui sont soldées, dont la date de péremption expire bientôt, etc.) nous allons devoir dupliquer ce critère … De plus, si notre client décide d’agrandir la gamme de prix, nous serions obligés de repasser sur tout notre code en risquant d’oublier quelque chose.

Nous pourrions bien sûr utiliser des constantes, ou des variables de classe, mais ça rendrait l’écriture de nos conditions encore plus longues et moins explicite – c’est là qu’interviennent les named_scope. Éditons la classe Article pour ajouter un filtre :

class Article < ActiveRecord::Base
  named_scode :pas_chers, :conditions => { :prix => [ 0 .. 5 ] }
end

Pour l’instant, nous n’avons fait que déplacer un peu de code du Contrôleur vers le Modèle, rien de transcendant – mais voilà ce que nous pouvons maintenant écrire :

@articles = Article.pas_chers.find :all, :conditions => { :rubrique_id => 2 }

Et voilà le travail : nous pouvons réutiliser et même chaîner des jeux de critères de sélection ! Attention toutefois à ne pas en abuser, même si c’est assez tentant : cela a un impact sur les performances qui doit rester maîtrisé.

Pour en savoir plus, je vous renvoie à la documentation de la méthode sur l’API ainsi qu’à un épisode des Railscasts de Ryan Bates (en Anglais).

Les fichiers de garniture (fixtures)

Les fichiers de garniture permettent d’ajouter facilement des données de test à votre application et vont donc en faciliter le développement : leur écriture peut se faire sous forme de fichier yaml ou csv. La première forme est la plus intéressante, car elle s’intègre mieux à Rails et permet même d’utiliser directement les mécanismes de relations entre les classes Modèles que nous voyions dans un précédent article.

Concrètement, tout se passe dans les fichiers qui sont générés automatiquement quand vous créez des Modèles à l’aide de la commande script/generate model .... Regardez dans le répertoire test/fixtures pour les retrouver. En reprenant l’exemple des classes que nous voyions dans l’article précédent, vous devriez ainsi trouver les fichiers articles.yml, taggables.yml, tags.yml et utilisateurs.yml.

Ouvrons dans un premier temps le premier fichier, articles.yml :

one:
  login: MyString
  mot_de_passe: MyString

two:
  login: MyString
  mot_de_passe: MyString

Comme vous pouvez le voir, le fait d’utiliser le générateur pour créer la classe de modèle Utilisateur a également eu pour effet de générer deux entrées dans ce fichier en renseignant directement les noms des colonnes que nous avions spécifié.

Notez également que chaque enregistrement possède déjà un identifiant (one et two) qui nous permettra d’y faire référence dans un autre fichier pour créer une relation !

Modifions un peu ce fichier pour créer des Utilisateur plus intéressants :

pierre:
  login: pierre
  mot_de_passe: mdp1

killian:
  login: killian
  mot_de_passe: mdp2

georges:
  login: georges
  mot_de_passe: mdp3

Nous pouvons maintenant utiliser chacun de ces enregistrements dans la garniture de la classe Article ! Ouvrons donc le fichier articles.yml :

one:
  titre: MyString
  contenu: MyText
  utilisateur_id: 1

two:
  titre: MyString
  contenu: MyText
  utilisateur_id: 1

Rails nous propose de changer la valeur de la colonne utilisateur_id, ce qui est tout à fait possible – cependant, puisque nous avons déjà défini des relations entre ces deux classes, nous allons pouvoir nous passer de cette étape et réécrire le contenu de ce fichier de la façon suivante :

article1:
  titre: "Mon premier article"
  contenu: "Contenu de mon premier article"
  utilisateur: pierre

article2:
  titre: "Mon deuxième article"
  contenu: "Contenu de mon deuxième article"
  utilisateur: killian

article3:
  titre: "Mon troisième article"
  contenu: "Contenu de mon troisième article"
  utilisateur: pierre

Rails comprendra tout seul que l’utilisateur pierre auquel nous faisons référence a été défini dans le fichier utilisateurs.yml.

Nous pouvons maintenant vider notre base de développement (rake db:reset)pour la remplir avec ces quelques enregistrements, à l’aide de la commande rake db:fixtures:load. Ouvrez maintenant une console Rails, (script/console) et constatez que les enregistrements ont bien été créés dans la base :

>> Utilisateur.find :all
=> [#,
#,
#]

>> Article.find :all
=> [#,
#,
.#]

Vous remarquerez que les identifiants des enregistrements créés par ce biais ne commencent jamais par 1, ce qui permet de les distinguer facilement des enregistrements standards et ce qui évitent qu’ils perturbent vos tests manuels.

Si vous voulez tagger un article dans les garnitures, c’est un peu plus sophistiqué, car il faut indiquer à Rails que vous passez par une table intermédiaire à cause de l’utilisation du système has_many :through ; la démarche reste cependant la même : voyez directement dans la documentation pour en apprendre plus.

En guise de conclusion, notez que les fixtures ne sont pas une réponse à toutes les situations. Par exemple, c’est généralement une mauvaise idée de s’en servir pour placer des données nécessaires au bon fonctionnement de l’application : les données que vous y placerez doivent être réservées à vos tests fonctionnels & unitaires.

Si vous avez besoin de mettre en place des données de base pour votre application en production, utilisez le fichier db/seeds.rb. Vous pourrez ensuite exécuter les commandes qu’il contient avec la commande rake db:setup.

La suite au prochain épisode !

Cet article était le dernier de notre série consacrée à la couche Modèle de Rails : aussi dès la semaine prochaine (si tout va bien ) nous entamerons une toute nouvelle séquence qui concernera l’implémentation des ressources et des formulaires dans notre framework préféré.

Articles liés :

Applications et bases de données, comment tester ?

Killian Ebel — Thu, 17 Dec 2009 08:50:09 +0000

Même si l’on préfèrerait l’éviter, les tests unitaires d’une application web par exemple, portent souvent sur des parties du programme accédant à une base de données. Bien qu’il existe plusieurs outils servant à simplifier la tâche, voici tout d’abord des bonnes pratiques que je conseillerais à tout développeur.

Bien séparer les couches

Même si cela peut paraître idiot de le répéter encore une fois, il est indubitable que moins votre code concernera les accès à la base, moins il y aura de tests à faire en ce sens. Ainsi, concentrez ces parties par exemple dans des DAO, très loin des partie « IHM » et « Business » de votre application.

Utilisez une base de données embarquée

Je ne sais pas si c’est réellement une bonne pratique, mais il me semble idéal pour l’indépendance des tests qu’ils puissent être lancés n’importe où / n’importe quand, même quand le SGBD réel n’est pas actif. Ainsi, des systèmes tels que sqlite, HSQLDB ou d’autres de la même catégorie sont à mon goût plus adaptés pour les tests.

Évitez au maximum les dépendances

Analysez ces deux classes et imaginez la plus pratique à tester :

public class UserDAOImpl implements UserDAO {

    protected Connection getConnection() throws SQLException {
        return DriverManager.getConnection("jdbc://...", "login", ...);
    }

    // ... createUser ...
}

public class UserDAOImpl implements UserDAO {
    private Connection connection;

    public UserDAOImpl(Connection connection) {
        this.connection = connection;
    }

    // ... createUser ...
}

Voici la méthode createUser (JDBC) :

public User createUser(String userId, String firstName, String lastName) throws DAOException {
    try {
        PreparedStatement ps = getConnection().prepareStatement("INSERT INTO ...");
        ps.setString(1, userId);
        ps.setString(2, firstName);
        ps.setString(3, lastName);
        ps.executeUpdate();
        ps.close();
        return new User(userId, firstName, lastName);
    } catch (SQLException e) {
        throw new DAOException(e.getMessage());
    }
}

On voit rapidement que le premier code est directement dépendant du DriverManager, en gérant lui-même la récupération de la connexion courante. Dans le deuxième cas, on injecte la connexion dans le DAO, c’est à dire plus de dépendance directe, et beaucoup plus facile à tester. Pour mieux découpler, un bon Framework d’injection de dépendance vous aidera à rendre vos classes autonomes.

Les différentes approches

L’approche par les Mocks / Fakes

Bien que très pratiques, les Mocks peuvent ne pas être appropriés pour les tests d’accès à la base, certains les déconseillent même vivement.

Les avantages sont une vitesse d’exécution bien supérieure, en plus de pouvoir tester aisément les cas les plus extrêmes en forçant les exceptions. En contrepartie, cela représente beaucoup de code à écrire (tous les objets factices à implémenter), et de plus si la structure des tables venait à changer, les tests pourraient ne pas échouer alors qu’ils ne seraient plus adaptés sémantiquement.

En fonction de la testabilité de votre code, l’écriture des Mocks peut s’avérer très compliquée. Si votre code viole la loi de Déméter, vous aurez à créer des Mocks / Fakes à la chaîne ; par exemple dans l’exemple précédent (qui est un mauvais exemple !), la méthode createUser, l’appel à getConnection() n’est utilisé que pour instancier un PreparedStatement…

final MockConnection connection = new MockConnection();
expect(mock.prepareStatement("INSERT..."));
...

final UserDAO dao = new UserDAOImpl(connection);
dao.createUser(...);
...

L’approche « Sandbox »

Cette approche très différente consiste à premièrement, utiliser une base de test différente de la base de production. Les avantages sont évidents, mais les défauts aussi : très lourd à maintenir, il faut rétablir l’état initial de la base entre chaque test pour garder leur indépendance, ce qui rend l’exécution d’une suite de tests très lente (par expérience, il est pénible d’attendre 10 – 15 minutes pour avoir les résultats d’une suite de tests).

Une alternative à cette méthode est de travailler en mode transactionnel et de faire un Rollback après chaque test, pour que les données n’y persistent pas ; je trouve l’idée intéressante, mais il faut faire attention car si le test lance une erreur imprévue et que le Rollback n’est pas exécuté, il faussera la suite des tests en semant la zizanie au sein des données…

Enfin, toujours dans l’idée de rendre les tests indépendants du moment et du lieu d’exécution, cette approche utilise fréquemment le concept de « Dataset » (ou Fixtures). Selon l’outil utilisé, la façon de charger les données de test sera différente mais l’idée reste la même.

Voici une liste d’outils dont le but est de faciliter ce type de tests :

DbUnit (Java)

Le Framework de référence (où en tout cas, celui sur lequel les autres se basent).

Il fonctionne sur un principe de Dataset XML. Deux types de Dataset existent, le XmlDataSet et le FlatXmlDataSet, respectivement :



    USER_IDFIRST_NAMELAST_NAME
            1
            Foo
            Bar
        
            ...

et :

Le XmlDataSet est ainsi bien plus verbeux mais plus généraliste, alors que le FlatXmlDataSet est plus simple à écrire mais peut être plus fastidieux à mettre en place (il faut créer le DTD de son Dataset).

Voici un exemple basique qui montre une des opérations disponibles :

public class SampleTest extends DBTestCase {

    public SampleTest(String name) {
        super(name);
        // ... configuration de la connection
    }

    protected DatabaseOperation getSetUpOperation() throws Exception {
        // On rafraîchit la base avant chaque test
        return DatabaseOperation.REFRESH;
    }

    protected DatabaseOperation getTearDownOperation() throws Exception {
        // On ne fait rien après un test
        return DatabaseOperation.NONE;
    }

    public void testAjoutMembre() {
        UserDAO dao = ...;
        dao.createUser(...)

        // On récupère l'état courant de la table sous forme de dataset
        IDataSet databaseDataSet = getConnection().createDataSet();
        ITable actualTable = databaseDataSet.getTable("USERS");

        // On le compare à un dataset XML
        IDataSet expectedDataSet = new FlatXmlDataSet(new File("expectedDataSet.xml"));
        ITable expectedTable = expectedDataSet.getTable("USERS");

        Assertion.assertEquals(expectedTable, actualTable);
    }
}

DbUnit et Spring (Java)

Spring, l’ingénieux Framework d’Inversion de Contrôle (et de plein d’autres choses !), permet de simplifier l’utilisation de DbUnit. Spring et les annotations rendent conjointement le test vraiment agréable à écrire, jugez-en par vous même.

Voici le fichier applicationContext.xml avec la configuration de la DataSource :

Et le test unitaire :

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations={"classpath:applicationContext.xml"})
public class SampleTestWithSpring {

    @Autowired
    private DataSource dataSource;

    @Before
    public void init() throws Exception {
        // Avant le test on insère le dataSet
        DatabaseOperation.CLEAN_INSERT.execute(dataSource.getConnection(), getDataSet());
    }

    @After
    public void after() throws Exception {
        // Après le test on supprime le dataSet
        DatabaseOperation.DELETE_ALL.execute(dataSource.getConnection(), getDataSet());
    }

    private IDataSet getDataSet() throws Exception {
        return new FlatXmlDataSet(new File("src/test/resources/dataset.xml"));
    }

    @Test
    public void testXXX() {
        ...
    }
}

On pourra ajouter que Spring contient à lui seul un module pour les tests d’intégration.

Unitils (Java)

Déjà évoqué concernant l’utilisation des Mocks, Unitils permet de simplifier les tests d’accès à la base de données.

public class UserDAOTest extends UnitilsJUnit4 {

    @Test
    @DataSet("UserDAOTest.testFindByMinimalAge.xml")
    public void testFindByMinimalAge() {
        List result = userDao.findByMinimalAge(18);
        assertPropertyLenientEquals("firstName", Arrays.asList("jack"), result);
    }
}

Le fichier dataset est un fichier XML similaire à ceux utilisés par DbUnit. J’avoue préférer la syntaxe d’Unitils à celle de DbUnit, car l’utilisation des annotations (par exemple @ExpectedDataSet ou @Transactional(TransactionMode.ROLLBACK)) combinée à Spring rendent ce framework extrêment flexible.

PHPUnit Database Extension (PHP)

Cette extension de PHPUnit est en fait un portage de DbUnit en PHP. Il utilise ainsi le même principe des dataset.xml :

require_once 'PHPUnit/Extensions/Database/TestCase.php';

class BankAccountDBTest extends PHPUnit_Extensions_Database_TestCase {

    protected $pdo;

    public function __construct() {
        $this->pdo = new PDO('sqlite::memory:');
    }

    protected function getConnection() {
        return $this->createDefaultDBConnection($this->pdo, 'sqlite');
    }

    protected function getSetUpOperation() {
        return $this->getOperations()->CLEAN_INSERT();
    }

    protected function getTearDownOperation() {
        return $this->getOperations()->DELETE_ALL();
    }

    protected function getDataSet() {
        return $this->createFlatXMLDataSet(dirname(__FILE__).'/_files/users-dataset.xml');
    }

    public function testNewUserCreation() {
        $user = new User(...);
        // ... enregistrement ...

        $expected_dataset = $this->createFlatXMLDataSet(dirname(__FILE__).'/_files/expected-users-dataset.xml');
        $this->assertDataSetsEqual($xml_dataset, $this->getConnection()->createDataSet());
    }
}

Doctrine ORM (PHP)

Ayant pas mal utilisé cet outil dans divers projets PHP, j’ai cherché par curiosité s’il proposait une façon de gérer les tests unitaires. Effectivement, il propose quelques raccourcis via la classe Doctrine_UnitTestCase, mais sans entrer dans le détail j’ai l’impression que les possibilités sont malheureusement moins grandes qu’avec PHPUnit.

class Doctrine_Sample_TestCase extends Doctrine_UnitTestCase {

    public function prepareTables() {
        $this->tables[] = "Users";
        parent::prepareTables();
    }

    public function prepareData() {
        // Peut-être des fixtures peuvent être chargées ici ?
    }

    public function testNewUserCreation() {
        $this->assertTrue(...);
    }
}

Un point intéressant proposé par Doctrine est la présence des Mock Drivers, qui permettent de simuler le comportement des tests sur un SGBD virtuel (si vous voulez par exemple tester la génération des requêtes pour Oracle) :

class Doctrine_Sample_TestCase extends Doctrine_UnitTestCase {

    public function testInit() {
        $this->dbh = new Doctrine_Adapter_Mock('oracle');
        $this->conn = Doctrine_Manager::getInstance()->openConnection($this->dbh);
    }

    public function testMockDriver() {
        $user = new User();
        $user->username = 'jwage';
        $user->password = 'changeme';
        $user->save();

        $sql = $this->dbh->getAll();

        $this->assertEqual($sql[0], 'INSERT INTO user (username, password) VALUES (?, ?)');
    }
}

NDbUnit (.Net)

Un projet pour .Net sous licence LGPL écrit en C#. Le fonctionnement est assez similaire à DbUnit ; d’après la documentation, on peut facilement le combiner à Proteus afin de simplifier l’écriture du code et d’éviter les redondances.

Voici un exemple de Dataset (UsersDataSet.xml) :

Et un exemple de test :

[TestFixture]
public class Tests
{
    private string _connectionString;
    private NDbUnit.Core.INDbUnitTest _mySqlDatabase;

    [SetUp]
    public void _Setup()
    {
        _mySqlDatabase.PerformDbOperation(NDbUnit.Core.DbOperationFlag.CleanInsertIdentity);
    }

    [FixtureSetUp]
    public void _TestFixtureSetup()
    {
        _connectionString = "server=localhost;user=dbuser;password=dbpassword;initial catalog=MyDatabase;";
        _mySqlDatabase = new NDbUnit.Core.SqlClient.SqlDbUnitTest(_connectionString);

        _mySqlDatabase.ReadXmlSchema(@"..\..\UsersDataSet.xsd");
        _mySqlDatabase.ReadXml(@"..\..\UsersDataSet.xml");
    }

    [FixtureTearDown]
    public void _TestFixtureTearDown()
    {
        _mySqlDatabase.PerformDbOperation(NDbUnit.Core.DbOperationFlag.DeleteAll);
    }

    [Test]
    public void Test()
    {
        CustomerRepository repository = new CustomerRepository();
        Assert.AreEqual(2, repository.GetAllCustomers().Count);
    }
}

Ruby On Rails (Ruby)

Si vous êtes développeur Ruby et utilisez le framework Rails, sachez que ce type de tests est prévu par l’outil : un mécanisme de fixtures YAML ou CSV est inclus dans le projet, qui combiné au moteur de tests unitaires par défaut (ActiveSupport::TestCase) se révèle très complet.

De plus, un ensemble d’assertions vous permettra de tester rapidement vos modèles (ainsi que d’effectuer rapidement des tests d’intégration et fonctionnels, mais c’est un autre sujet !).

Le Framework peut travailler avec d’autres outils comme NullDB, qui permet d’éviter l’utilisation d’une base de données, ou d’autres méchanismes en remplacement des fixtures (Factory Girl, Machinist).

Voici un exemple de dataset (users.yml) :

david:
    name: David Heinemeier Hansson
    birthday: 1979-10-15
    profession: Systems development

steve:
    name: Steve Ross Kellock
    birthday: 1974-09-27
    profession: guy with keyboard

Ces fixtures peuvent être rendus dynamiques à l’aide d’ERb.

require 'test_helper'

class PostTest < ActiveSupport::TestCase
    def test_user
        david = users(:david).find
        assert_equals("Systems development", david.profession)
    end
end

C’est un test très basique mais je pense qu’on peut pousser bien plus loin à l’aide du Framework.

Django (Python)

Le puissant Framework Python propose aussi tout l’outillage nécessaire pour tester votre application. En plus des TestCase habituels, vous pourrez créer des TransactionTestCase, qui réinitialisera l’état de la base (de test) avant le lancement des tests en chargeant les données initiales.

De plus, des fixtures peuvent aussi être utilisées, au format JSON ou YAML (ici users.json) :

[
    {
        "model": "myapp.models.User",
        "pk": 1,
        "fields": {
            "first_name": "John",
            "last_name": "Lennon"
        }
    },
    {
        "model": "myapp.models.User",
        "pk": 2,
        "fields": {
            "first_name": "Paul",
            "last_name": "McCartney"
        }
    }
]

Le dataset peut de même être un fichier SQL, même si cela rend vos tests un peu moins indépendants du SGBD utilisé :

INSERT INTO myapp_user (first_name, last_name) VALUES ('John', 'Lennon');
INSERT INTO myapp_user (first_name, last_name) VALUES ('Paul', 'McCartney');

Et voici un exemple de classe de test utilisant ces fixtures :

from django.test import TestCase
from myapp.models import User

class UsersTestCase(TestCase):
    fixtures = ['users.json']

    def testUsers(self):
        john = User.objects.get(pk=1)
        self.assertEquals("John", john.first_name)

Et les procédures stockées ?

Dans beaucoup d’applications, procédures stockées et triggers sont utilisés pour automatiser certaines tâches. Il existe deux méthodes pour les tester : localement, via une autre procédure de test, ou à distance, en appelant la procédure avec votre langage par défaut (Java, Ruby…).

Voici un exemple de procédure stockée à tester :

CREATE OR REPLACE PROCEDURE add (
    a IN NUMBER,
    b IN NUMBER,
    result OUT NUMBER
)
IS
BEGIN
    result := a + b;
END;
/

Pour écrire un test sous forme de procédure stockée, il existe l’outil utPLQSL pour Oracle, mais il n’a plus l’air maintenu depuis quelques années. Je n’ai pas trouvé d’outil similaire pour les autres SGBD, si ce n’est SQLUnit, mais je ne l’ai pas étudié en détail.

CREATE OR REPLACE PACKAGE BODY ut_myapp
IS
    PROCEDURE ut_setup
    IS
    BEGIN
        NULL;
    END;

    PROCEDURE ut_teardown
    IS
    BEGIN
        NULL;
    END;

    PROCEDURE ut_ADD
    IS
        result NUMBER;
    BEGIN
        ADD ( A => 3,  B => 2, RESULT => result );
        utAssert.eq ( 5, result );
    END ut_ADD;

END ut_myapp;
/

Les tests unitaires rattachés aux bases de données permettent d’assurer un peu plus la stabilité de l’application et surtout l’intégrité de ses données. Utilisez-vous un de ces outils ou un outil similaire, et avez-vous rencontré des problèmes lors de sa mise en place ? Quels seraient les conseils à donner à tous les développeurs pour améliorer l’écriture de leur code / tests ?

Quelques références

Articles liés :

La couche Modèle de Rails (Partie 2)

Pierre Quillery — Sat, 12 Dec 2009 21:38:02 +0000

Voici la suite du premier article qui parlait de la couche Modèle dans Rails, n’hésitez pas à aller y jeter un œil si vous ne l’avez pas encore lu ! Ce post fait partie d’une série de tutoriels dont vous pouvez trouver la liste sur mon ancien site.

Configuration des base de données dans Rails

Comme vous l’avez sans doute remarqué dans le précédent article, nous avons directement commencé à travailler avec la base de données sans pour autant avoir eu besoin de configurer quoi que ce soit au niveau de l’application. En effet, ainsi que je le décrivais déjà ici, Rails se repose par défaut sur une base Sqlite, ce qui permet de s’affranchir de configuration et rentrer directement dans le vif du sujet.

La configuration concernant les bases de données est placée dans le fichier config/database.yml. Comme vous pouvez le voir, on y trouve 3 zones qui correspondent à la configuration de chaque environnement (dev, preprod et prod). L’intérêt de ce fonctionnement est qu’il est très souple à l’usage : pour développer vous aurez rarement besoin d’une base MySql, alors qu’en production, c’est une nécessité.

# SQLite version 3.x
#   gem install sqlite3-ruby (not necessary on OS X Leopard)
development:
  adapter: sqlite3
  # Emplacement du fichier où se trouve la base
  database: db/development.sqlite3
  # Nombre de connexion dans le pool
  pool: 5
  timeout: 5000

# ...

Notons que MySQL n’est pas le seul SGBD supporté par Rails : il en est de même pour PostgreSQL, DB2, SQL Server, Oracle, Sybase, Firebird, etc.

Prenons l’exemple de MySQL, et changeons la configuration pour nous connecter à une base MySQL correspondant à notre application en production :

# ...

production:
  adapter: mysql
  # Encodage du client
  encoding: utf8
  # Nom de la base à laquelle se connecter
  database: monapplication_prod
  pool: 5
  username: monnomdutilisateur
  password: monmotdepasse
  # Si la base se trouve sur la machine locale ...
  socket: /var/run/mysqld/mysql.sock
  # ... Ou si la base se trouve ailleurs
  host: serveurbdd.monapplication.com

Interaction avec les bases de données avec la ligne de commande

Nous avons vu dans le précédent article comment utiliser les migrations pour interagir avec les bases de données via la ligne de commande Rails. Voici quelques autres commandes qui vous permettront de tester tout ça à loisir :

rake db:create → Créer la base de donnée
rake db:destroy → Détruire la base de données

Notez que ces commandes, comme toutes les opérations en ligne de commande de Rails, sont sensibles au contexte pour le choix de l’environnement à affecter : par défaut, vous travaillez avec l’environnement de développement. Pour changer ce comportement, il vous faut changer la valeur de la variable d’environnement RAILS_ENV en lui donnant le nom de l’environnement de votre choix.

Ainsi vous écrirez par exemple la commande suivante pour supprimer le contenu de la base de production :

RAILS_ENV=production rake db:destroy

Sélection, Modification et Suppression d’élément

Utilisation de la console Rails

Ruby on Rails intègre une console interactive qui est un lieu d’expérimentation privilégié : vous pouvez directement créer des objets persistants en base, tester un bout de code, une fonction, etc. Nous allons l’utiliser pour la suite du tutorial, car cela nous évitera d’avoir à nous soucier des autres couches. Pour la démarrer, rien de plus simple :

script/console

Vous entrez maintenant dans la console interactive, tapez quit pour en sortir à tout moment ! Notez enfin que l’invite de commande commence toujours par les caractères >> alors que les retours de ruby sont préfixés d’une flèche =>.

Mise en place de notre projet de travail

Voici quelques commandes qui vous nous permettre de mettre en place un projet pour tester un peu les possibilités offertes en ce qui concerne les opérations simples de CRUD sur lesquelles nous allons nous attarder aujourd’hui.

rails appli_de_test
cd appli_de_test
script/generate model Utilisateur login:string mot_de_passe:string
script/generate model Article titre:string contenu:text utilisateur_id:integer
script/generate model Tag libelle:string --skip-timestamps
script/generate model Taggable tag_id:integer article_id:integer --skip-timestamps

Nous allons créer, comme vous l’avez compris un blog minimaliste : un Utilisateur possède des Articles. Les Articles partagent un ou plusieurs Tags via la relation Taggable.

Il ne nous reste plus qu’à éditer les fichiers de classes correspondants que vous trouverez dans le répertoire app/models pour exprimer explicitement les relations qui lient ces éléments entre eux :

# app/models/utilisateur.rb
class Utilisateur < ActiveRecord::Base
  has_many :articles
end

# app/models/article.rb
class Article < ActiveRecord::Base
  belongs_to :utilisateur
  has_many :taggables
  has_many :tags, :through => :taggables
end

# app/models/taggable.rb
class Taggable < ActiveRecord::Base
  belongs_to :article
  belongs_to :tag
end

# app/models/tag.rb
class Tag < ActiveRecord::Base
  has_many :taggables
  has_many :articles, :through => :taggables

  # Ce champ est obligatoire, on force donc sa présence
  validates_presence_of :libelle
end

Maintenant, il ne nous reste plus qu’à mettre en place la structure de la base de données, à l’aide de la commande rake db:migrate puis à nous connecter à la console de Rails pour commencer nos essais : script/console

Création d’élément

Précisons en guise de préambule que cet aperçu des possibilités qui vous sont offertes par Rails et Active Record (classe qui s’occupe spécifiquement de la persistence des données en base) est vraiment très superficiel ; je ne saurais trop vous conseiller de vous référer à la documentation d’Active Record pour apprendre réellement à vous en servir .

Nous allons tout d’abord créer des Tags à l’aide de la méthode create(). Cette méthode va instancier un objet Tag et créer directement l’enregistrement en base (si la validation s’est bien déroulée).

>> t = Tag.create
=> #

Ah, nous remarquons le Tag n’a pas d’id (nil signifie null en PHP) ; cela signifie qu’il n’est pas présent en base – or il devrait l’être, puisque c’est ce que nous attendons de la commande create() …

Une erreur s’est produite à cause de la validation que nous avons ajouté dans la classe Tag : j’ai volontairement omis de préciser le champ libelle et l’enregistrement n’a pu être effectué. C’est ce mécanisme qui nous permettra de faciliter la validation des formulaires, ainsi que nous le verrons dans un prochain article.

Rails nous indique en fait dans la variable errors de l’objet t la liste des erreurs qui se sont produites et qui empêchent la validation et donc l’enregistrement de l’élément :

>> t = Tag.create
=> #
>> t.errors
=> #[#>]}>, @base=#>

Le message n’est pas forcément très lisible présenté comme ça, mais nous apprenons ainsi qu’il s’agit d’une erreur qui concerne le champ libelle et qu’elle a le type :blank. Le mécanisme de validation de formulaire de Rails rendra ce tableau très facile à exploiter pour nous par la suite, même s’il n’a pas l’air très avenant vu sous cet angle !

Essayons maintenant de reprendre la saisie des Tags en évitant de provoquer des erreurs :

>> Tag.create :libelle => "Rock"
=> #
>> Tag.create :libelle => "Folk"
=> #
>> Tag.create :libelle => "Soul"
=> #
>> Tag.create :libelle => "Funk"
=> #

Ce coup-ci, il est clair que tout se passe bien : les enregistrements se voient directement attribuer un id numérique, ce qui signifie qu’ils sont maintenant présents en base.

Sélection d’éléments

Maintenant que la base est peuplée de quelques éléments, nous pouvons nous intéresser aux méthodes qui nous permettent de retrouver ces mêmes éléments. Tout passe à vrai dire par la méthode de classe find qui est disponible pour chaque classe de modèle.

Ainsi, pour sélectionner une collection d’éléments, nous utilisons la variante find :all, en voici un exemple :

>> Tag.find :all
=> [#, #, #, #]

Notez que dans le retour qui est fait, Rails nous renvoie bien une collection d’éléments qu’il a placé dans un tableau ([ ... ]) ; comme en Javascript, on emploie en Ruby les crochets pour écrire un tableau.

Essayons maintenant d’ajouter une condition à notre sélection – plusieurs syntaxes sont disponibles, voici celle qui permet de créer une sorte de requête préparée qui prend la forme d’un tableau. Les ? dans la requête SQL sont ainsi remplacés par les valeurs entrées dans les index suivant. Ici nous recherchons par exemple les Tags qui commencent par la lettre F.

>> Tag.find :all, :conditions => [ 'libelle like ?', 'F%' ]
=> [#, #]

Voyons maintenant comment sélectionner un élément unique dans la base ; pour cela, on emploie la version find :first de la méthode :

>> Tag.find :first, 1
=> #

Dans le cas présent, Rails a bien renvoyé un élément unique, et non un tableau, ainsi que c’était le cas précédemment. On aurait éventuellement pu omettre le :first, c’est en fait la méthode utilisée par Rails si on ne précise rien.

Nous allons maintenant voir une autre façon d’écrire les conditions : plutôt que de passer un tableau, il est également possible de passer un simple hash ({ ... }) – il s’agit d’une sorte de tableau associatif :

>> Tag.find :first, :conditions => { :libelle => 'Rock' }
=> #

Voilà les bases de ce qu’il est possible de faire pour sélectionner des éléments ; vous trouverez ici le détail des différentes options supportées par la méthode find, elles sont nombreuses. Vous pouvez également regarder ce screencast qui fait une démonstration des possibilités offertes par cette méthode.

Modification d’un élément

Maintenant que vous savez retrouver un élément, il serait utile de savoir le modifier puis le sauvegarder ; voici comment faire en employant assez logiquement la méthode save :

>> t = Tag.find :first, 1
=> #
>> t.libelle = "Rock'n'Roll"
=> "Rock'n'Roll"
>> t.save
=> true

Je sélectionne ainsi l’élément « Rock », que je désire modifier en « Rock’n'Roll ». Il me suffit de changer la valeur du champ « libelle », puis de sauvegarder. Notez que la méthode save retourne une variable qui va nous permettre de savoir que l’enregistrement a bien été effectué, s’il a correctement passé la validation. Retrouvez ici la documentation concernant cette méthode.

Voici un exemple de modification qui va échouer :

>> t = Tag.find 2
=> #
>> t.libelle = ""
=> ""
>> t.save
=> false
>> t.errors
=> #[#>]}>, @base=#>

Comme avec la méthode create que nous voyions tout à l’heure, il est toujours possible d’accéder aux messages de validation. Il nous est toutefois possible de court-circuiter la validation si nous sommes dans un environnement contrôlé, ce qui permet d’accélérer le traitement, grâce à la méthode save!.

Suppression d’un élément

Dernière partie, et non la moins importante de notre passage en revue du CRUD le plus basique en Rails, la destruction d’un élément. Voilà comment s’y prendre, grâce à la méthode destroy :

>> t = Tag.find :first, :conditions => {:id => 1}
=> #
>> t.destroy
=> #
>> Tag.find :first, :conditions => {:id => 1}
=> nil

Il est important de noter que la fonction destroy retourne l’élément supprimé en cas de succès, ce qui s’avère souvent très utile.

Créons des relations entre les objets

Maintenant que nous savons interagir avec nos Modèles, il nous reste à voir comment créer des relations entre eux ; nous allons ainsi créer un Utilisateur et lui ajouter plusieurs Articles, ce qui nous permettra de voir le fonctionnement de la relation 1 à plusieurs. Dans un second temps, nous verrons comment assigner des Tags à un Article donnée en passant par la relation plusieurs à plusieurs.

Utiliser la relation Un à Plusieurs

Voici quelques commandes maintenant connues qui vont nous permettre de créer quelques enregistrements que nous allons utiliser par la suite.

>> util1 = Utilisateur.create :login => "utilisateur1", :mot_de_passe => "mdp1"
=> #
>> util2 = Utilisateur.create :login => "utilisateur2", :mot_de_passe => "mdp2"
=> #

>> arti1 = Article.create :titre => "Titre de mon premier article",
  :contenu => "Pas de contenu pour le moment"
=> #
>> arti2 = Article.create :titre => "Titre de mon second article",
  :contenu => "Pas de contenu pour le moment"
=> #
>> arti3 = Article.create :titre => "Titre de mon troisième article",
  :contenu => "Pas de contenu pour le moment"
=> #

Comment changer le rédacteur du premier Article pour dire qu’il est en fait le premier Utilisateur ? Rien de plus simple :

>> arti1.utilisateur = util1
=> #
>> arti1.save
=> true
>> arti1
=> #

Si nous avions voulu exploiter la relation dans le sens inverse, il nous aurait fallu énoncer les choses différemment : en effet un Article n’a qu’un seul et unique Utilisateur dans notre exemple – alors qu’un Utilisateur peut avoir écrit un nombre indéfini d’Articles.

Rails nous donne donc accès à un tableau dans le lequel il nous suffit d’ajouter les Articles de notre choix à l’Utilisateur qui est leur auteur. Disons que le deuxième Utilisateur a écrit les deux derniers articles :

>> util2.articles = [ arti2, arti3 ]
=> [#,
  #]
>> util2.save
=> true
>> util2
=> #

Et voilà pour la relation Un à Plusieurs ; comme vous le voyez, le fonctionnement de Rails à ce sujet est assez intuitif et logique.

Utiliser la relation Plusieurs à Plusieurs

Nous allons maintenant ajouter les tags que nous avons déjà employé précédemment pour tagguer nos Articles. Rails fait la plus grosse partie de notre travail grâce à la relation has_many :through que nous avons défini dans les classes Article et Tag : nous pouvons faire abstraction de la classe Taggable avec laquelle notre framework se chargera d’interagir.

Commençons par ajouter deux Tags à notre premier article :

>> arti1.tags << Tag.find(:first, :conditions => { :libelle => "Folk" })
=> [#]
>> arti1.tags << Tag.find(:first, :conditions => { :libelle => "Funk" })
=> [#, #]
>> arti1.tags
=> [#, #]

Notez que j’utilise une syntaxe différente pour interagir avec le tableau des tags de l’Article ; l’opérateur << peut se lire comme : « ajoute l’élément suivant à ce tableau » ; il s’agit d’un équivalent du array_push() de PHP ou du push() de Javascript.

Ajoutons encore quelques Tags à un autre Article et regardons le contenu de la table contenant les Taggables, avec lesquels nous ne sommes pas directement intervenus, pour constater que Rails a fait lui-même les associations nécessaires pour nous permettre de nous abstraire de cette table de jointure.

>> arti2.tags = Tag.find(:all)
=> [#, #,
  #]
>> Taggable.find :all
=> [#,
  #,
  #,
  #,
  #]

Voilà, c’est tout pour aujourd’hui ! Dans quelques temps, nous verrons la suite (et a priori la fin) de notre programme initial sur la couche Modèle de Rails, avec les garnitures (fixtures) & les filtres. En attendant, n’hésitez pas à essayer de refaire ce tutoriel chez vous, c’est tout son intérêt , et laissez un commentaire si vous rencontrez un problème.

Articles liés :

La couche Modèle de Rails (Partie 1)

Pierre Quillery — Sat, 05 Dec 2009 14:51:54 +0000

Rails, en bon framework qu’il est, propose bien sûr une couche Modèle assez complète à laquelle les deux prochains articles se proposent de vous introduire. Nous couvrirons dans cet article la définition du concept de Modèle, la création d’objets à l’aide de Migrations, validerons les données et créerons des Relations entre ces même Modèles … Copieux programme en perspective !

Tout d’abord, un petit disclaimer s’impose par rapport au contenu de cet article : il s’agit de la suite d’une série d’articles que j’avais commencé sur mon précédent blog sans aller jusqu’au bout. Je ne pense pas reprendre les anciens articles sur ce blog-ci, ce qui n’aurait pas beaucoup de sens dans un premier temps – je vous invite donc à aller consulter la page de présentation de mon projet ainsi que les premiers articles sur l’ancien site.

Un Modèle ?

Le Modèle est, comme nous l’avons précédemment, une des trois couches du modèles MVC. Il s’agit de celle qui est en charge de permettre l’enregistrement et la recherche de données. Typiquement, on utilise pour cela une classe dite d’ORM, de mapping objet-relationnel, qui va nous permettre de nous abstraire d’un SGBD particulier tout en s’intégrant mieux dans un ensemble de classes.

L’idée est de réduire au maximum la distance qui sépare la base de données (l’implémentation du stockage de données) des objets métiers de notre application (un Client, un Article, un Blog, un Commentaire, etc.). C’est également dans la couche Modèle que nous allons définir facilement les relations entre ces derniers (un Article a plusieurs Commentaires, etc.) ainsi que la validation des données (la date de naissance d’un utilisateur donné doit toujours être sous la forme jj/mm/aaaa, etc.).

Créons une nouvelle classe de Modèle à l’aide des Migrations

Tout d’abord, qu’est ce qu’une migration ? Il s’agit d’un fichier qui va contenir la définition d’une ou plusieurs tables ainsi que des champs qui les composent. Ils peuvent être créés soit automatiquement, (lorsque vous ajoutez une classe métier) soit par un plugin … Vous pouvez également en générer à tout moment.

L’idée est de placer dans un fichier texte facile à lire et à éditer la structure de votre base de données. Rails s’occupera ensuite de générer les commandes SQL qui correspondent dans la base correspondant à votre environnement courant (nous verrons cela plus loin). Vous pouvez ainsi facilement versionner votre base.

Créons donc un classe Modèle de test à l’aide de la console Rails. Comme vous le voyez, je précise immédiatement les champs que je connais de ce Modèle : ils seront ajoutés automatiquement par Rails dans le fichier de migration correspondant que nous complèterons manuellement tout à l’heure.

script/generate model Article titre:string date_publication:datetime contenu:text timestamps

Ça y est : quelques fichiers ont été créés, notamment app/models/article.rb qui est la classe de notre Modèle à propremment parler, et qui ne contient rien pour l’instant et db/migrate/xxxx_create_article.rb, notre Migration.

Voyons maintenant le contenu de ce deuxième fichier :

class CreateArticles < ActiveRecord::Migration

  # Méthode appelée pour mettre en place la migration
  def self.up
    create_table :articles do |t|
      t.string :titre
      t.text :contenu
      t.datetime :date_publication

      # Va créer un champ auteur_id que nous utiliserons un peu plus loin
      t.references :auteur

      # Ajout automatique de champs tels que created_at, modified_at, etc.
      # Ces champs seront ensuite gérés par Rails automatiquement.
      t.timestamps
    end
  end

  # Méthode permettant d'enlever la migration au besoin
  def self.down
    drop_table :articles
  end
end

Nous pouvons éditer le fichier pour ajouter éventuellement des champs supplémentaires puis déclencher la migration en utilisant la ligne de commande Rails. Nous pourrons alors utiliser le fichier de Modèle et poursuivre notre application.

rake db:migrate

Validation dans le Modèle

Nous allons maintenant travailler avec la classe Modèle qui se trouve dans le répertoire app/models et ajouter du code pour faciliter la validation des champs qui s’y trouvent. Cela signifie que nous pourrons ainsi nous assurer par exemple du bon formattage d’un email, d’une date de naissance, de la présence d’un titre etc.

Cette validation empêchera par défaut toute création d’enregistrement ou mise à jour. Elle ajoutera le cas échéant des messages au modèle (personnalisables et même disponibles en plusieurs langues via l’internationalisation du framework) que vous pourrez simplement montrer à l’utilisateur pour lui permettre de corriger facilement sa saisie.

class Article < ActiveRecord::Base
  # Le titre de l'article est obligatoire (il ne doit pas être vide)
  validate_presence_of :titre

  # Le titre ne devrait pas être trop court ...
  validates_length_of :titre, :minimum => 30

  # etc .
end

Voici une page où vous trouverez toutes les méthodes de validation à votre disposition, les méthodes par défaut couvrent une bonne partie des besoins les plus évidents.

Nous verrons dans le prochain article comment exploiter efficacement ces messages de validation pour les afficher à l’internaute lors de sa saisie.

Créons des Relations

La création de relations est une partie intéressante des possibilités que Rails vous offre pour la couche Modèle : vous pouvez ainsi exprimer directement les principaux types de relations dont vous avez besoin pour reproduire tout schéma de base dans votre application.

Précisons d’abord que pour fonctionner, Rails a tout de même besoin que vous respectiez ses propres convention de nommage des champs pour lui permettre de retrouver ses petits et inférer ce que vous voulez faire. Ainsi, les champs de clés étrangères seront toujours nommées champ_id.

Je vais maintenant présenter les principaux types de relations disponibles, mais toutes ces méthodes sont très personnalisables, voyez dans la documentation pour en apprendre plus à leur sujet.

Une à Plusieurs

Un des cas le plus fréquent est la relation Une à Plusieurs : un Auteur a plusieurs Articles, un Article a plusieurs Commentaires, etc. Voici comment l’écrire dans les classes e Modèle (je pars du principe que les modèles correspondants ont été créés et migrés vers la base) :

# Fichier app/models/commentaire.rb
class Commentaire < ActiveRecord::Base
  # C'est cette table qui contient la clé étrangère article_id,
  # on écrit donc belongs_to puis le nom du Modèle à lier au singulier
  belongs_to :article
end

# Fichier app/models/article.rb
class Article < ActiveRecord::Base
  # Deuxième côté de la relation, on écrit has_many puis le
  # nom du Modèle au pluriel.
  has_many :commentaires
end

Une à Une

Moins fréquent, vous pouvez restreindre cette relation pour créer une relation Une à Une en changeant le has_many par un has_one, comme dans cet exemple :

# Fichier app/models/utilisateur.rb
class Utilisateur < ActiveRecord::Base
  # C'est cette table qui contient la clé étrangère profil_id
  belongs_to :profil
end

# Fichier app/models/profil.rb
class Profil < ActiveRecord::Base
  # Deuxième côté de la relation, on écrit has_many puis le
  # nom du Modèle au singulier.
  has_many :utilisateur
end

Plusieurs à Plusieurs et Relations Composites

Vous trouverez sur Internet de nombreux tutoriaux qui vous présenteront l’emploi de la technique dite du habtm ou has_and_belongs_to ; je ferais pour ma part l’impasse sur cette dernière qui est maintenant globalement dépréciée et qui ne devrait plus être utilisée dans la plupart des cas.

Voici donc la bonne façon de voir les choses pour créer une relation Plusieurs à Plusieurs viable, c’est à dire grâce au has_many :through :

# Fichier app/models/utilisateur.rb
class Utilisateur < ActiveRecord::Base
  has_many :abonnements
  has_many :magazines, :through => :abonnements
end

# Fichier app/models/abonnement.rb
class Abonnement < ActiveRecord::Base
  # Notez qu'on emploie dans cet objet deux clés étrangères
  belongs_to :utilisateur
  belongs_to :magazine
end

class Magazine < ActiveRecord::Base
  has_many :abonnements
  has_many :utilisateurs, :through => :abonnements
end

Rien ne vous empêche d’ajouter des champs supplémentaires à votre objet Abonnement si vous souhaitez enrichir la relation ; on pourrait imaginer enregistrer la durée de l’abonnement par exemple. Ce n’était pas possible avec l’ancienne technique (habtm), et c’est une des raisons pour laquelle elle tombe petit à petit en désuétude.

Vous pouvez, sur le même principe, créer des relations composites (ou polymorphiques) qui pourront vous servir à factoriser pas mal de code en créeant une interface commune auxquels des Modèles de différents types pourront s’accrocher. C’est un peu complexe à expliquer, mais un exemple vaut mieux qu’un long discours :

class Coordonnee < ActiveRecord::Base
  # Il faut deux champs supplémentaires dans la table coordonnees :
  # - localisable_id, un entier
  # - localisable_type, une chaîne
  # => Utilisez la syntaxe suivante dans la Migration :
  #    t.references :localisable, :polymorphic => true
  belongs_to :localisable, :polymorphic => true
end

class Utilisateur < ActiveRecord::Base
  has_many :localisations, :as => :localisable
end

class Societe < ActiveRecord::Base
  has_many :localisations, :as => :localisable
end

Grâce à cette syntaxe, les Utilisateurs et les Societes partagent la possibilité d’avoir un objet Coordonnees qui leur est lié, ce qui serait plus complexe à mettre en place sinon. Nous pourrions facilement faire évoluer ce modèle au besoin, c’est ce qui fait sa force.

Dans quelques jours, nous verrons la suite de notre programme sur les Modèles dans Rails en parlant des différents types de base de données disponibles et leur configuration, des requêtes préparées, etc. Voir l’article suivant !

Articles liés :

Le problème du Singleton

Killian Ebel — Wed, 02 Dec 2009 06:00:08 +0000

Le concept du Singleton en lui-même n’est pas un souci, avoir une instance unique d’une classe est même souvent très pratique. Quand bien même, qu’en est-il de la testabilité d’un tel composant ?

L’implémentation reconnue, le design pattern Singleton du fameux GoF, est malheureusement assez compliquée à tester : une classe ne devrait pas forcer elle-même son statut de Singleton, mais l’instance unique devrait être gérée au niveau de l’application.

Le problème

Imaginons un composant Service, une quelconque classe métier. Dans une de ses méthodes, la classe Service fait appel à un autre composant, nommé par exemple Counter ; ce dernier est un simple compteur qui incrémente sa valeur à chaque appel d’un service. Pour avoir un compteur commun à tous les services, il doit en exister une instance unique, partagée par tous les composants de type Service.

Ainsi, voici un exemple d’implémentation :

class Counter {
    private static final Counter instance = new Counter();
    private int count = 0;

    private Counter() {}

    public static Counter getInstance() {
        return instance;
    }

    public void increment() {
        count++;
    }

    public int getCount() {
        return count;
    }
}

class Service {
    public void execute() {
        // ...
        Counter.getInstance().increment();
    }
}

L’implémentation semble correcte, un test unitaire appelant le service peut être écrit afin d’en vérifier le comportement. Imaginons maintenant que :

Un grand nombre d’autres services utilise ce compteur ;
L’appel à l’incrémentation du compteur soit très complexe, faisant appel à des webservices / se connectant à une base de données / lisant un fichier du système ;
Plusieurs tests unitaires, pouvant même être lancés simultanément, ont besoin d’un compteur « remis à zéro ».

Que faire ?

Votre service est complètement dépendant de la classe Counter. Ecrire une méthode qui réinitialise le Singleton ? Rajouter des conditions dans la méthode du Singleton pour éviter les opérations trop importantes en cas de test ? Les tests unitaires n’ont pas à interférer votre code métier, qui réciproquement ne doit pas changer pour s’adapter aux tests. Ce qui importe dans ce test, c’est de vérifier le fonctionnement du service, et non l’appel au compteur ; comment mocker le compteur si celui-ci est un Singleton et crée lui-même son instance ?

Une solution au problème est l’injection de dépendances. Votre application (ou plutôt le container IoC) va se charger d’instancier l’unique compteur et de l’injecter dans chacun des services. Le processus peut-être fait manuellement, mais sera bien plus simple à mettre en place avec un framework spécialisé comme Spring ou Guice. Voici un exemple avec Spring :

interface Counter() {
    void increment();
    int getCount();
}

class ComplexCounter implements Counter {
    private int count = 0;

    public Counter() {}

    public void increment() {
        // Beaucoup de choses compliquées et très lourdes, assez longues à exécuter (le temps d'aller boire un café)
        count++;
    }

    public int getCount() {
        return count;
    }
}

class Service {
    private Counter counter;

    public Service(Counter counter) {
        this.counter = counter;
    }

    public void execute() {
        // ...
        counter.increment();
    }
}

Ainsi votre instance de compteur reste un Singleton au sens conceptuel du terme (instance unique partagée par les autres composants), mais la classe Counter ne gère plus elle-même son instance. L’avantage est de pouvoir tester désormais le service en mockant le compteur, et éviter la liste d’ennuis énoncée précédemment (avec jMock) :

Mockery context = new Mockery();

public void testService() {
    final Counter counter = context.mock(Counter.class);
    context.checking(new Expectations() {{
        oneOf(counter).increment();
    }});

    Service service = new Service(counter);
    service.execute();

    // Assertions ...
    context.assertIsSatisfied();
}

On s’attend seulement (Expectations) à ce que la méthode increment du compteur soit appelée, et peu importe son réel fonctionnement, vu que seul le Service doit être testé !

Que pensez-vous de cette solution à propos du Singleton ? Comment faîtes-vous pour tester vos classes Singleton ?

Voici quelques références :

Le guide de l’écriture d’un code testable, par des développeurs de Google
Injected Singleton

Articles liés :

VRaptor, le framework qui a les crocs

Killian Ebel — Fri, 30 Oct 2009 06:00:50 +0000

A l’occasion de la sortie de VRaptor 3, un framework MVC dernière génération pour Java, je me suis permis de faire un petit article de présentation.

VRaptor s’annonce très prometteur, mais n’est malheureusement pas encore disponible sur un dépôt Maven. Pour rappel, Maven est un outil de build qui fonctionne en indiquant les dépendances de son projet, appuyé par des conventions d’architecture. Ainsi, en respectant les standards proposés par Maven au niveau de l’arborescence d’un projet, il n’est plus nécessaire d’indiquer impérativement une opération de compilation, vu que Maven se charge de vous fournir le bon classpath et de télécharger les librairies manquantes si votre projet en dépend.

Si Maven vous fait peur, que le XML vous rebute, je ne peux que vous conseiller d’utiliser Gradle. Cet outil de build basé sur Groovy me paraît très flexible et simple à mettre en place ; nous le verrons rapidement à la fin de l’article.

Mise en place de Maven

Créez votre fichier de projet pom.xml :




    UTF-8


4.0.0
fr.chosesafaire
blog
war
blog
0.0.1
Test de VRaptor
http://www.chosesafaire.fr


    
        
            org.apache.maven.plugins
            maven-compiler-plugin
            
                1.5
                1.5
                UTF-8
            
        
        
            maven-war-plugin
            
                ${basedir}/src/main/webapp
                ${env.TOMCAT_HOME}/webapps/${project.artifactId}
            
        
    



    
        org.aspectj
        aspectjrt
        1.6.4
    
    
        cglib
        cglib-nodep
        2.2
    
    
        commons-fileupload
        commons-fileupload
        1.2.1
    
    
        org.apache.commons
        commons-io
        1.3.2
    
    
        commons-logging
        commons-logging
        1.1.1
    
    
        com.google.collections
        google-collections
        1.0-rc2
    
    
        org.hamcrest
        hamcrest-all
        1.1
        test
    
    
        javassist
        javassist
        3.8.0.GA
    
    
        javax.servlet
        jstl
        1.2
    
    
        junit
        junit
        4.7
        test
    
    
        log4j
        log4j
        1.2.12
    
    
        net.vidageek
        mirror
        1.5.1
    
    
        org.objenesis
        objenesis
        1.1
    
    
        ognl
        ognl
        2.7.3
    
        
        com.thoughtworks.paranamer
        paranamer
        2.1
    
    
        org.reflections
        reflections
        0.9.4
    
    
        org.slf4j
        slf4j-api
        1.5.6
    
    
        org.slf4j
        slf4j-log4j12
        1.5.6
        
    
        org.springframework
        spring
        2.5.6
    
    
        br.com.caelum
        vraptor
        3.0.0

Pour la liste des dépendances, j’ai pris toutes les librairies qui étaient incluses dans l’exemple de projet vide avec VRaptor (plus d’autres, comme JUnit et Hamcrest), et les ai recherchées sur http://www.mvnrepository.com/. On remarque certaines dépendances intéressantes et encore expérimentales comme Google Collections. J’ai pris soin à chaque fois de récupérer la version la plus récente (en espérant qu’il n’y aura pas de problèmes de compatibilité !).
Comme VRaptor (version 3) n’est encore disponible sur aucun dépôt Maven, il va falloir télécharger le JAR, puis l’installer dans votre dépôt local ( plus de détails ) :

mvn install:install-file -Dfile=/path/to/vraptor-3.0.0.jar -DgroupId=br.com.caelum -DartifactId=vraptor -Dversion=3.0.0 -Dpackaging=jar

De même, je n’ai pas trouvé l’archive reflections-0.9.4.jar, mais le projet est herbergé sur Google Code alors comme pour VRaptor, récupérez l’archive et installez le dans votre dépôt local :

mvn install:install-file -Dfile=/path/to/reflections-0.9.4.jar -DgroupId=org.reflections -DartifactId=reflections -Dversion=0.9.4 -Dpackaging=jar

Mises à part ces deux outils, Maven va se charger de télécharger automatiquement les versions demandées des autres et les incluera dans votre projet (que ce soit au niveau de la compilation ou de l’exécution, c’est à vous de paramétrer). Attention cependant si vous êtes derrière un proxy.

src/main/webapp/META-INF/MANIFEST.MF

Souvent passé à la trappe, ce fichier peut se révéler bien utile dans certains cas. Par défaut, il contient seulement une indication sur sa version :

Manifest-Version: 1.0

Mais comme indiqué sur le site de Sun, il peut être utilisé par exemple à des fins de signature du JAR, ou encore pour indiquer les dépendances de votre JAR. Cette dernière fonctionnalité est la base du fonctionnement des Bundles OSGi, le framework qui transforme votre application en modules indépendants, pouvant être rechargés individuellement et dynamiquement.

src/main/resources/log4j.properties

Pour cet exemple on ne va pas trop complexifier le debugger, qui affichera simplement dans la console :

log4j.rootLogger=debug, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n

src/main/webapp/web.xml

VRaptor s’installe sous la forme d’un filtre, dont le seul paramètre obligatoire est le package de base à partir duquel il va scanner vos classes :




    chosesafaire-blog

    
        br.com.caelum.vraptor.packages
        fr.chosesafaire.blog
    

    
        vraptor
        br.com.caelum.vraptor.VRaptor
    

    
        vraptor
        /*
        FORWARD
        REQUEST

Ce fichier de configuration est le seul dont vous aurez besoin dans votre projet, il est malheureusement obligatoire car c’est le fonctionnement même de Java EE qui l’impose. Cependant, la sortie de Java EE 6 et des Servlets 3.0 va sûrement changer la donne, en privilégiant les annotations par rapport au XML !

src/main/java/fr/chosesafaire/blog/controllers/IndexController.java

Déclarons un contrôleur assez simple qui interceptera les requêtes :

package fr.chosesafaire.blog.controllers;

import br.com.caelum.vraptor.Path;
import br.com.caelum.vraptor.Resource;
import br.com.caelum.vraptor.Result;

@Resource
public class IndexController {

    private final Result result;

    public IndexController(Result result) {
        this.result = result;
    }

    @Path("/{name}")
    public void index(String name) {
        result.include("name", name.toUpperCase());
    }

    @Path("/")
    public void index() {
        index("Anonymous");
    }
}

src/main/webapp/jsp/index/index.jsp

Lors de l’appel de votre méthode index de l’IndexController, VRaptor va automatiquement associer le fichier index/index.jsp pour l’affichage :

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>


    
        
        Le blog des choses à faire
    
    
         has been kicked by the Raptor (Aoutch !)

src/test/java/fr/chosesafaire/blog/controllers/IndexControllerTest.java

Une application de qualité ne le serait pas vraiment si elle n’était pas accompagnée de sa batterie de tests unitaires

Dans le projet d’exemple, les tests d’intégration sont réalisés avec SeleniumDSL et HtmlUnit, et les tests unitaires avec JUnit, JMock et Hamcrest (pour les Matchers). Nous nous contenterons de simples tests unitaires pour compléter l’article, mais surtout regardez le projet d’exemple, qui exploite bien les possibilités de ces librairies de tests !

package fr.chosesafaire.blog.controllers;

import static org.junit.Assert.assertThat;
import static org.hamcrest.Matchers.is;

import org.junit.Before;
import org.junit.Test;

import br.com.caelum.vraptor.util.test.MockResult;

public class IndexControllerTest {

    private IndexController controller;
    private MockResult result;

    @Before
    public void setUp() throws Exception {
        result = new MockResult();
        controller = new IndexController(result);
    }

    @Test
    public void indexWithParameter() throws Exception {
        controller.index("test");
        String name = result.included("name");
        assertThat(name, is("TEST"));
    }

    @Test
    public void indexWithoutParameter() throws Exception {
        controller.index();
        String name = result.included("name");
        assertThat(name, is("ANONYMOUS"));
    }
}

Déploiement de l’application

Un appel à maven-war-plugin vous permettra de compiler votre application dans un WAR :

mvn compile war:war

Si vous souhaitez faire une installation complète (lancer les tests unitaires etc…), vous pouvez utiliser la commande mvn clean install.

Enfin, déployez votre application dans votre serveur d’applications préféré. Si vous utilisez Tomcat par exemple, copiez juste votre WAR dans le répertoire $TOMCAT_HOME/webapps/, puis démarrez-le si ce n’est pas déjà fait (n’oubliez pas de déclarer TOMCAT_HOME !).

Pour éviter de s’embêter à redéplacer l’archive après chaque compilation, il est possible de spécifier une option au plugin (cela est déjà fait dans le pom.xml de l’article) :

...

...
    ${env.TOMCAT_HOME}/webapps/${project.artifactId}
...

...

Vous pouvez aussi vous simplifier la tâche en utilisant directement le plugin Tomcat. Rendez-vous à l’adresse http://localhost:8080/blog/ (ou là où vous l’avez déployé), puis sur http://localhost:8080/blog/chuck.

Encore une astuce Maven

Si vous disposez de plusieurs processeurs, vous pouvez essayer de rendre les builds plus rapides avec une option de Maven :

# Lors de la compilation
mvn -Dmaven.artifact.threads=3 clean install

# Ou pour le rendre définitif
export MAVEN_OPTS=-Dmaven.artifact.threads=3

Bonus : Gradle

Si Maven vous rebute un peu, vous pouvez toujours tenter Gradle, un nouvel outil de build dans l’ère du temps. L’avantage d’écrire votre build en Groovy par rapport au XML est assez évident : plus léger, c’est un langage de script qui peut accéder aux classes Java, tout en apportant une syntaxe dynamique et simplifiée. La documentation de Gradle vous montrera mieux que moi toutes les possibilités offertes (d’ailleurs, Gradle sera étendu pour permettre d’écrire ses scripts en Ruby ou en Python… vraiment génial !).

A la racine de votre projet, créez un fichier build.gradle (l’équivalent du pom.xml, en plus concis !) :

group = 'fr.chosesafaire'
version = '0.0.1'
sourceCompatibility = 1.5

usePlugin('war')

repositories {
    mavenCentral()
    flatDir name: 'localRepository', dirs: 'lib'
}

dependencies {
    compile 'org.aspectj:aspectjrt:1.6.4'
    compile 'cglib:cglib-nodep:2.2'
    compile 'commons-fileupload:commons-fileupload:1.2.1'
    compile 'commons-io:commons-io:1.3.2'
    compile 'commons-logging:commons-logging:1.1.1'
    compile 'com.google.collections:google-collections:1.0-rc2'
    compile 'javassist:javassist:3.8.0.GA'
    compile 'javax.servlet:jstl:1.2'
    compile 'log4j:log4j:1.2.12'
    compile 'net.vidageek:mirror:1.5.1'
    compile 'org.objenesis:objenesis:1.1'
    compile 'ognl:ognl:2.7.3'
    compile 'com.thoughtworks.paranamer:paranamer:2.1'
    compile 'org.reflections:reflections:0.9.4'
    compile 'org.slf4j:slf4j-api:1.5.6'
    compile 'org.slf4j:slf4j-log4j12:1.5.6'
    compile 'org.springframework:spring:2.5.6'
    compile 'br.com.caelum:vraptor:3.0.0'

    testCompile 'org.hamcrest:hamcrest-all:1.1'
    testCompile 'junit:junit:4.7'
}

Faîtes attention si vous êtes derrière un proxy sans l’indiquer, il ne pourra pas télécharger les dépendances. Gradle peut utiliser les dépôts Maven et Ivy ; pour nos deux archives introuvables, on peut simplement déclarer un repértoire (ici lib) qui servira de dépôt (pas besoin d’installer quoi que ce soit). Ainsi, si vous souhaitez récupérer vos librairies manuellement, il suffit d’indiquer à Gradle le répertoire, qu’il scannera automatiquement.

Pour compiler, lancez la commande :

# pour seulement compiler le war
gradle war

# pour la construction totale (tests etc)
gradle build

L’archive WAR se retrouvera dans build/libs/ ; je n’ai pas encore repéré les options comme le nom du war généré et son emplacement. Dans la version actuelle de Gradle, certaines fonctionnalités ne sont pas encore bien implémentées (génération de rapports…), mais je ne doute pas (et j’espère !) que cet outil évoluera assez vite vers sa version finale.

Conclusion

Voilà, votre projet est opérationnel, et fonctionne avec Maven (ou Gradle), ce qui simplifiera tous vos builds futurs. Je n’ai pas vraiment montré les possibilités du framework, la documentation officielle le fera bien mieux que moi, mais en tout cas, il simplifie énormément le travail d’un développeur Java : quasiment rien à configurer, les injections sont automatiques, les intercepteurs aussi… A surveiller de près !

Avez-vous déjà utilisé ce framework dans une précédente version ? Que vaut-il face à Spring MVC ou Struts 2 ?

Articles liés :

Awk : Premiers pas

Pierre Quillery — Mon, 26 Oct 2009 06:00:06 +0000

Awk est un vieil outil *nix qui peut, aujourd’hui encore, nous rendre bien des services pour ce qui est de manipuler des fichiers de données tabulaires, ce qu’il fait à la perfection. Voyons dans cet article comment approcher la programmation de cette commande.

Il y a quelques jours, j’ai pu constater dans le cadre de mon travail l’efficacité et la rapidité de cet outil : nous disposons d’un flux qui nous est mis à disposition par un partenaire ; à nous de le récupérer, et de le rendre « intégrable » dans la base MySQL.

Au départ la solution développée ne reposait pas du tout sur ces commandes, mais quasi-exclusivement sur des feuilles de traitement XSLT. Le traitement durait alors près de 36 minutes pour chaque flux, ce qui rendait les tests et les modifications difficiles.

Il a donc été décidé de refondre ces traitements en employant Awk. Après quelques optimisations, le script, écrit en très peu de temps, a permis de descendre autour de quelques secondes de traitement.

Un peu d’histoire

Awk est un très vieil outil *nix, il est apparu pour la première fois en … 1987 sur System V. Il a été révisé plusieurs fois et existe en plusieurs moutures sur toutes les distributions : awk, gawk, nawk … C’est à peu près le même combat, à quelques différences près (plus de fonctions sont disponibles dans gawk, par exemple). En un mot, il permet de faciliter le traitement de fichiers textes contenant des données tabulaires.

Awk ?

Il s’agit d’un véritable langage de programmation miniature qui contient tout ce dont vous avez besoin pour manipuler des chaînes et, à l’intérieur, des champs. Le principe de base est que vous ciblez une ligne (ou un groupe de ligne, ou toutes les lignes) à l’aide d’une expression régulière et que vous appliquez sur chacune des lignes un traitement particulier. Vous avez également pour compléter ce modèle de traitement la possibilité de définir un traitement à effectuer une seule fois au début (BEGIN) et à la fin du script (END).

L’avantage d’utiliser Awk plutôt qu’un autre langage de script n’est pas qu’une question de performances : grâce à lui et son intégration à *nix, vous bénéficiez également de la possibilité d’utiliser des pipes et autres redirections de flux.

Exemple d’utilisation : un CSV vers un tableau HTML

Plutôt que de transformer un fichier XML en données CSV, je me propose plutôt de montrer ici comment convertir de la façon la plus générique possible un fichier CSV vers un tableau HTML.

Voici tout d’abord la ligne qui me permet d’invoquer la commande Awk en précisant le fichier de script à utiliser (csvtohtml.awk) ainsi le fichier sur lequel il doit travailler (donnees.csv). Enfin, je redirige la sortie standard vers le fichier donnees.html.

gawk -f csvtohtml.awk donnees.csv > donnees.html

Rien de bien sorcier jusqu’ici, reste maintenant à définir le contenu de notre fichier de script, csvtohtml.awk qui va effectuer le fameux traitement.

############################################################
# Définition du pré-traitement
############################################################
BEGIN {
  # Field Separator : dans notre cas, un point-virgule
  FS=";"
  # On démarre l'affichage du tableau HTML
  print ""
}

############################################################
# Fonction pour convertir une ligne du fichier en une ligne
# de tableau HTML.
# @param type (td/th) Suivant le type de ligne à générer
############################################################
function ligne_html(type) {
  retour = ""
  # Pour chaque champ de la ligne courante ...
  for ( i = 1 ; i < NF ; i++ ) {
    # On récupère ce qui se trouve entre les guillemets
    # qui encapsulent éventuellement le champ
    # On place le résultat dans le tableau r.
    match($i,/^[\"]?([^\"]*)/,r)
    # On concatène tout ça à la variable de retour
    # Le champ 1 de r contient ce qu'on a trouvé 
    # précédemment.
    retour = retour "<" type ">" r[1] ""
  }
  return retour ""
}

###########################################################
# Définition du traitement global 
# (appliqué à toutes les lignes)
###########################################################
{
  # Si le Number of Record est à un, il nous faut traiter
  # le case de la première ligne, celle qui contient les 
  # entêtes.
  if ( NR == 1 ) {
    # On génère une ligne de table headers et on ouvre
    # le corps du tableau.
    print "" ligne_html("th") ""
  } else {
    # Pour toutes les autres lignes, on génère des td.
    print ligne_html("td")
  }
}

############################################################
# Définition du post-traitement
############################################################
END {
  # On termine le tableau ... C'est fini :) !
  print "
"
}

Si vous souhaitez approfondir le sujet, je ne peux que vous diriger sur le petit opuscule « Sed & Awk (2nd Edition) » de Arnold Robbis, publié chez O’Reilly (vous pouvez l’avoir sur Amazon pour 5€ avec les frais de port, c’est une affaire).

Aucun article lié