Archive

Posts Tagged ‘Testing’

Editique et automatisation des tests

February 26th, 2007

Je viens de démarrer un nouveau projet en tant que Scrum Master. Je me trouve au sein d’une équipe éditique. Nous devons produire une batteries de documents destinés à des clients (courriers, contrats, …). La qualité des documents est notre préoccupation première.

Pour valider le contenu et la forme de nos documetns, Scrum va nous permettre de vite avoir du feedback. Par contre, il existe de nombreuses règles à respecter pour qu’un document soit complet et satisfaisant. Par exemple, nous sommes limités à une liste de polices et à certaines couleurs. Nous devons vérifier que les blocs de texte ne se chevauchent pas dans des cas limites. Les marques de pliage et les adresses postales doivent être positionnées très précisément… Dans ce domaine, il n’est pas certain qu’un oeil humain puisse nous aider. Plus le nombre de règles est important, plus difficile il sera de valider un document.

Mes réflexes de développeur Java me poussent à chercher des outils de tests automatisés. Un peu comme un checkstyle permet de vérifier le respect de quelques normes de codage, il faudrait un outil capable de décortiquer un document pdf et à même de vérifier certaines règles communes à tous les documents.

Mes recherches sur Google n’ont rien donné pour l’instant. Il semble exister un marché pour les outils vérifiant si un pdf respecte les normes d’accessibilité mais rien pour le domaine éditique pur. On doit se contenter d’un outil qui prend un fichier xml en entrée, lance la génération de pdf et compare avec un document cible. Cela permet juste d’évacuer la plupart des régressions.

Si l’on parvient à lire le contenu d’un pdf en Java (peut-être avec iText), il est théoriquement possible de coder certaines de ces règles, mais cela reste complexe.

 Avez-vous des expériences similaires ou de idées à me soumettre ?

Blog , ,

ExcelTemplate, la lecture de fichiers Excel facilitée

January 26th, 2007

Cet article présente un petit outil OpenSource que j’ai développé pour faciliter la lecture de jeux de test Excel dans une démarche Test Driven Requirement.

Le méthodes agiles préconisent de tester avant de développer. Pour ce faire, un outil comme Fitness permet d’écrire des tests utilisateur automatisés en utlisant un wiki et des tables HTML. Pour ma part, je préfère une approche basée sur des fichiers Excel®. Se pose alors la problématique de la lecture de ces fichiers.

POI-HSSF permet de lire un fichier Excel®. Toutefois le code à écrire est vite illisible et répétitif.
En m’inspirant (très) fortement des JdbcTemplate et JmsTemplate de Spring, j’ai commencé à concevoir un ExcelTemplate capable d’encapsuler les appels à POI-HSSF, dans le but de lire des feuilles Excel®, avec un code lisible.

Voici le résultat pour convertir un onglet donné en tableau de String :

ExcelTemplate reader = new ExcelTemplate (”a.xls”);
String[][] lines = reader.read (”TabName”);

Un autre exemple pour lire un liste de Map. Chaque ligne du fichier est représentée par une Map. La première ligne donne les clefs. Les autres lignes donnent les valeurs. Petite subtilité, le fichier est lu depuis le Classpath :

ExcelTemplate reader = new ExcelTemplate (”a.xls”,getClass());
List lineAsMaps = reader.readList (”tab”);

Il est également possible de mapper les lignes dans des POJO, de cette façon :

ExcelTemplate reader = new ExcelTemplate (”a.xls”);
List beans = reader.readBeans (”tab”, MyBean.class);

Les trois exemples précédents présentent des comportements par défaut bien pratiques. Il est toutefois possible de tout customiser par l’utilisation de classes Callback. Le code suivant lit le contenu d’un onglet avec un CellMapper permettant de personnaliser la convertion du contenu d’une cellule en objet (par exemple pour tenir compte du style de la cellule) :

String[][] lines = (String[][]) reader.read (”tab”, new MyStringCellMapper(), String.class);

Voici un autre exemple utilisant un SheetExtractor pour personnaliser complètement la lecture du contenu d’un onglet tout en déléguant au template la compléxité du parsing de la feuille :

SheetInfo sheetInfo = (SheetInfo) reader.read (”TabName”, new SheetExtractor() {
public Object extractData (HSSFSheet sheet) throws IOException, DataAccessException {
return new SheetInfo (sheet.getFirstRowNum(), sheet.getLastRowNum());
}
})

private static class SheetInfo {
public int firstRow;
public int lastRow;

public SheetInfo (int firstRow, int lastRow) {
this.firstRow = firstRow;
this.lastRow = lastRow;
}
}

Le projet est en OpenSource. Les classes reposent sur Spring et sur POI-HSSF. Le projet est construit avec Maven2 et utilise des plug’ins comme Cobertura ou Checkstyle. Il a été développé avec une approche TDD et la couverture de tests est proche des 100%.

Il me reste à écrire la documentation. Un volontaire ?

Blog ,

Alors tu l’as testé TestNG ?

May 24th, 2006

Mon précédent article parle de TestNG et compare ses fonctionnalités avec celles de JUnit. J’ai écris cet article sans tester TestNG et je m’étais donc promis de l’utiliser pour mieux juger.

Alors tu l’as testé TestNG ?

Et bien, je dois avouer que non.

Pourquoi ?

Tout simplement, je constate que JUnit répond à tous mes besoins. Le code des TestCase est clair et les tests sont complètement isolés les uns des autres donc simplissimes à remanier.

Tu peux faire pareil avec TestNG et même plus !

Oui, je sais.

Et pourquoi ne pas le tester alors ?

J’ai mes petites habitudes et JUnit est intégré à tous mes outils (Eclipse, Maven, …). Pourquoi passer du temps à remplacer un outil qui répond à mes besoins et qui n’est plus qu’une commodité ?

Un avantage que je vois à TestNG est de réduire la durée des tests en mettant en évitant de répéter certaines phases d’initialisation à chaque test. Cependant, pour vraiment réglr le problème, il faut changer les frameworks que l’on met en oeuvre, pas l’outil de test. Par exemple, je préfère tester un POJO que de déployer un EJB avec toute la phase d’initialisation qui précède.

Blog ,