Premier test setup/expect/where

def "String param should correspond to numeric spockInfoDay - classical syntax"() {
    setup:
     def spockResource = new SpockResource(new CalendarDaoStatic())
    expect:
    spockResource.findCalendarByDay(day).day == dayNumeric

    where:
    day  <<   ["1", "2", "3"]
    dayNumeric << [1, 2, 3]
  }

Le test est organisé en 3 blocs : setup, expect et where le tout placé dans un objet dont le nom est défini par def « nom du test ».  Le premier bloc setup sert à déclarer les variables qui vont être utilisées dans la suite du test. Ici c’est par exemple l’instanciation de l’objet spockResource. Dans le bloc where, je définis deux variables : l’une day qui prendra successivement les valeurs ‘1’,’2′ et ‘3’ et l’autre dayNumeric les valeurs 1,2,3 [groovy est un langage dynamique donc pas besoin d’indiquer le type des variables, il sera déterminé automatiquement]. Dans le bloc expect, j’indique mon test : je vérifie que la méthode spcokResource.findCalendarByDay retourne bien un objet comportant un attribut day dont la valeur correspond à la valeur en tant qu’entier d’une chaîne de caractère [c’est à dire que ma fonctionnalité ne fait pas grand chose d’autre qu’un Integer.valueOf].  Lors de l’exécution, il y a en réalité 3 tests JUnit qui sont exécutés, un pour chaque couple de paramètre day=’1′ & dayNumeric=1 / day=’2′ & dayNumeric=2 / day=’3′ & dayNumeric=3

Test avec structure en tableau

Le même test peut être écrit d’une manière différente en utilisant une autre syntaxe, encore plus lisible.

def "String param should correspond to numeric spockInfoDay"() {
    setup:
    def spockResource = new SpockResource(new CalendarDaoStatic())
    expect:
    spockResource.findCalendarByDay(day).day == dayNumeric

    where:
    day     | dayNumeric
    "1"  | 1
    "2"  | 2
    "3"  | 3
  }

Ici même principe,  3 tests seront joués , avec les paramètres day = ‘1’ et dayNumeric = 1 / day = ‘2’ et dayNumeric = 2 /day = ‘3’ et dayNumeric = 3 . Les paramètres étant les uns à la suite des autres et  séparés par des | cela permet de mieux visualiser ses données de test.

Le choix entre la première et la deuxième méthode dépend du contexte. Si les données à tester sont statiques, la deuxième méthode est plus claire. Mais la première méthode permet de tester avec des données dynamiques comme par exemple :

where:
[a, b, c] << sql.rows("select a, b, c from maxdata")

Ces deux syntaxes permettent de faire du data-driven testing, c’est à dire du test piloté par les données : il est possible de vérifier plusieurs test cases en injectant les données de départ et les données attendues via une source externe, ici le bloc where. Nettement plus simple que de lancer trois tests JUnit différent pour le même comportement, le tout en restant très lisible.

JUnit

Si on regarde l’équivalent JUnit

 @RunWith(Parameterized.class)
public class DataDrivenSimpleTest {
  private Integer day;
  private Integer dayNumeric;

  @Parameters
  public static Collection data() {
    return Arrays.asList(new Object[][] { { 1, 1 }, { 2, 2 },
              { 3, 3 } });
  }

  public DataDrivenSimpleTest(Integer day, Integer dayNumeric) {
    super();
    this.day = day;
    this.dayNumeric = dayNumeric;
  }

  @Test
  public void shouldReturnTheNumericValueOfDay() {
    FoetusCalendarResource calendar = new FoetusCalendarResource(
        new CalendarDaoStatic());
    assertEquals(calendar.findCalendarByDay(day).getNbJour(), dayNumeric);

  }
}

Voilà l’exemple avec l’annotation @Parameters incluse dans JUnit depuis la version 4.0 et il n’y a que l’essentiel pour tester la méthode findCalendarByDay. Tout d’abord, la classe doit être lancée avec un runner spécifique Parameterized.class (à la ligne 1). Elle a besoin de deux variables de classes day et dayNumeric ainsi que d’un constructeur qui initialise ses deux variables. Il y a aussi besoin d’une méthode public static qui retourne une collection d’object représentant les différentes données pouvant être prises par les deux paramètres day et dayNumeric annotée avec @Parameters. Seulement ensuite apparait la méthode de test, shouldReturnTheNumericValueOfDay qui utilise les variables de classes day et dayNumeric. Il est également possible dans la méthode annotée par @Parameters de définir de manière dynamique des jeux de données, on peut par exemple penser à l’importation de données à partir d’un fichier excel ou d’une requête SQL par exemple comme avec Spock. Outre la verbosité de cette méthode, il n’est possible que d’avoir un seul test paramétré par classe.

Les pré-requis à l’utilisation des tests paramétrés avec JUnit (variables de classe, runner, constructeur …) font que je préfère largement utiliser Spock pour faire du data-driven testing.

Il y a différentes possibilités :

• S’abonner à la mailing list de son « Java User Group » local
• suivre les flux des différentes SSII proches de chez vous qui organisent de temps à autres des soirées.
• Twitter est également un bon moyen de se tenir à jour !
• L’équipe de JDuchess France fournit également un calendrier des évènements à venir : Agenda Conférences des Duchess. Il est possible d’ajouter facilement cet agenda à son Google calendar en tant qu’agenda ami : Consulter l’agenda Conférences dans Google Agenda

Si vous désirez ajouter un de vos évènements à l’agenda des JDuchess, tout est indiqué sur le blog des duchess

Les actions menées en France seront de plusieurs types :
– La création d’un réseau virtuel, via twitter, linkedin, une mailing list …
– Inciter les femmes à participer à des évènements locaux, comme les soirées JUG ou les autres conférences.
– Se rencontrer pour échanger, avant ou après les soirées JUGs, autour d’un apéro ou d’un repas.
– Lister les différents évènements en France pour ne pas les rater et éventuellement trouver quelqu’un avec qui y aller.

Pour se tenir informer des évènements de ce groupe, vous pouvez nous rejoindre sur twitter @duchessfr , sur LinkedIn ou via notre mailing list.

Le premier évènement aura lieu le 9 mars à 18h30 , juste avant le paris JUG au Vavin Café (18 rue Vavin 75006 Paris). Lorsque vous serez inscrites au JUG, contactez ellene(dot)dijoux(at)jduchess(dot)org qui vous accueillera Mardi prochain.