Java Bien!

Testing an application is not easy. Automating the tests is even more complex (think about how many tools you need to master compared to just click on the GUI). However the easiest tests to write and automate are regression tests. Those that you write to make sure that bugs will never reappear in your application.

It’s easier to write because :

• You know what to test. The goal of the test is to show a clearly identified buggy behavior. You don’t have to guess in advance where your applcicaton might fail.
• You have the application to test. You can imagine that it’s more complex to test the application before it’s written, even if it’ a good practice made possible with modern tools and architectures.
• The testing tool doesn’t have to be clever. The gool old action recorder is enough at the beginning.
• It’s easier to find the budget to automate the test. It is part of a “lengthy expensive bug fixing” operation and not of a “develop features as fast as you can” operation. Plus, the customer really hates regressions.

I’m not saying that you should only work on these tests. If you should ever want to write as few as possible tests, these are the easiest to write. It will not result in your application being stable quickly but at least it will be less prone to annoying regressions and will stabilize over time.

Chances are also that once you start writting regression tests, you’ll discover the power of automated tests. Think of your system as a black box with known inputs and expected outputs. You compare the real outputs with the expected outputs and you get a test running. Change the inputs and you get a second test running… Capture these data in java test classes, xml files, a fit wiki or scenarios written with a DSL and you have a powerful test engine.

Regression testing is not anymore an objective. It becomes a mean to write better quality code.

So let’s all shout “No regression is good for you” !

Une bonne couverture de code par les tests est primordiale. En même temps, un taux de couverture élevé ne signifie pas grand chose. ce que je vais appeler la fragilité des tests est un élément très important.
Read more…

I’m a big fan of HsqlDB for writing tests.

Yesterday I discovered this projet : H2 Database, written by the same author. It seems to have better performance for larger applications and better support for ACID properties.

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 ?

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 ?