JUnit et tests paramétrés

Dans la plupart des cas, l'écriture de tests JUnit se base sur plusieurs classes, contenant chacune des méthodes représentant les différents cas à tester. Ce concept permet l'organisation de tests visant à mettre à l'épreuve une série de fonctionnalités (métier ou techniques) dans différents scénarios. Or il est parfois nécessaire de réaliser le processus inverse : éprouver le même scénario plusieurs fois à partir d'un jeu de données précis...

Pour cela, le framework propose, dans sa dernière version, un nouveau runner permettant de réaliser ce genre d'action : les tests paramétrés. Voici le code à mettre en place :

import java.io.File;
import java.util.ArrayList;
import java.util.Collection;

import junit.framework.TestCase;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.runners.Parameterized;
import org.junit.runners.Parameterized.Parameters;

@RunWith(Parameterized.class)
public class JUnitParameters extends TestCase {
 
 private File ctlFile;

 protected static Collection<Object[]> filesToTest = new ArrayList<Object[]>();
 
 @Parameters
 public static Collection<Object[]> getTestsFiles() throws Exception {
  return parseFolderForFilesToTest("C:\\JUnit");
 }
 
 protected static Collection<Object[]> parseFolderForFilesToTest(String folderPath) throws Exception {
  File folder = new File(folderPath);
  parseFolder(folder);
  return filesToTest;
 }

 private static void parseFolder(File folder) throws Exception {
  for (File f : folder.listFiles()) {
   if (f.isDirectory()) {
    parseFolder(f);
   } else {
    filesToTest.add(new Object[] { f });
   }
  }
 }
 
 /** Parameters inject by JUnit */
 public JUnitParameters(File file) {
  ctlFile = file;
 }
 
 @Test
 public void testGenerate() {
  assertTrue("Le fichier est vide!", ctlFile.exists() && ctlFile.length()>0);
 }

}

La première annotation @RunWith permet d'indiquer au runner qu'il s'agit d'un test paramétré. Il va donc avant toute action (avant même le @BeforeClass) appeler la méthode marquée par @Parameters afin de constituer le jeu de données. Chaque tableau d'objets est par la suite injecté au constructeur du test, rappelé à chaque jeu de données.

La suite du test s'exécute de manière classique, les méthodes marquées @Test sont appelées successivement par introspection.

Comme on peut le voir ci-dessous, ma classe ne contenant qu'une méthode de test a été exécutée autant de fois que nécessaire :

Fichier(s) joint(s) :