Les tests et Spring

Introduction

Les préoccupations centrées sur les tests sont fondamentales dans les développements d’aujourd’hui. Le TDD (Test-Driven Development ou en français développement piloté par les tests), qui consiste, lors de l’écriture de nos programmes, à écrire les tests unitaires avant d’écrire le code source d’un logiciel, est de plus en plus utilisé. Depuis quelque temps nous utilisons aussi des BDD (Behavior Driven Development) qui sont une évolution du TDD avec lequel on décrit les tests via des phrases, par exemple, en français ou en anglais avec une syntaxe particulière, qui sont ensuite utilisées avec un framework comme Cucumber. Il existe aussi les ATDD (Acceptance Test-Driven Development) pour lesquels on transcrit les critères d’acceptation dans les tests.

Spring propose des API qui nous simplifient la mise en œuvre des tests unitaires (TU) et des tests d’intégration (TI). Il faut tester tout ce qui vaut le coup d’être testé. Si vous rencontrez des problèmes lors de la rédaction des TU et TI, c’est qu’il faut retravailler (refactoriser) votre code. Une bonne pratique consiste à écrire le test en même temps que la classe testée et même parfois à coder les tests avant l’implémentation...

Les mock objects

Quand nous testons une classe, nous voulons centrer nos tests sur celle-ci et nous devons alors trouver un moyen de ne pas tester les autres classes qui interagissent avec la classe testée. Nous pouvons utiliser des simulacres d’objets nommés mocks pour ne pas avoir à invoquer des objets réels qui demanderaient un contexte d’exécution trop étendu.

Spring fournit un ensemble de mocks très complet. Ils sont plus simples à utiliser que les mocks EasyMock et MockObjects. On les utilise souvent avec le framework Mockito (http://site.mockito.org/).

public class Vehicule { 
[accesseurs] 
   private long id; 
   private String modele; 
} 

final Vehicule person = new Vehicule();  
ReflectionTestUtils.setField(person, "id", new Long(99), 
long.class); 
assertEquals("id", 99L, person.getId());  
ReflectionTestUtils.setField(person, "modele", null, String.class); 
assertNull("modele", person.getModele()); 
try {  
   ReflectionTestUtils.setField(person, "id", null, long.class); 
   fail("Devrait lever une exception !"); 
} catch (IllegalArgumentException aExp) { 
   assert (aExp.getMessage() 
               .contains("IllegalArgumentException")); ...

Les frameworks de test JUnit et TestNG

Spring a intégré les deux frameworks les plus complets aujourd’hui afin d’en simplifier l’utilisation. La construction d’un environnement pour lancer nos tests devient un jeu d’enfant et il est possible de ne charger en mémoire que le strict minimum pour pouvoir faire nos tests. Il y a deux versions de JUnit : la version 4 et la version 5 appelée Jupiter. Il est possible de mixer la syntaxe du JUnit4 avec Jupiter pour des projets hybrides ou en cours de migration. Dans la suite de ce chapitre, nous allons voir les tests d’intégration qui utilisent Spring et JUnit. Les tests utilisant TestNG sont similaires à ceux qui utilisent JUnit et ne sont pas détaillés.

Les tests unitaires sont faits hors Spring et ne sont donc pas traités ici.

Les tests d’intégration sont relativement complexes car nous cherchons à créer le contexte minimum, contenant le minimum de beans Spring qui sont nécessaires et suffisants pour tester la partie que nous souhaitons tester.

@RunWith(SpringJUnit4ClassRunner.class) 
@TestExecutionListeners({}) 
public class SimpleTest { 
    @Test 
public void testMethod() { 
[...] 
} 

@IfProfileValue(name="java.vendor", value="Oracle Corporation") 
@Test 
public void testProcessavecJvmOracle() {  
 
@IfProfileValue ( name = "test-groups" , values ={ "unit-tests" ,  
"integration-tests" }) 
@Test 
public  void  
testProcessWhichRunsForUnitOrIntegrationTestGroups() { 
     // une certaine logique qui devrait fonctionner uniquement 
     // pour les tests unitaires et les tests d'intégration