Distribuer les tests JUnit avec Gridgain et Maven

Gridgain

Gridgain est un framework open source permettant de développer des applications en cloud ou en grille. Basé sur des annotations, il permet depuis la version 1.6 de distribuer les tests :

public class GridTests extends TestSuite {

	@GridifyTest
	public static Test suite()
	{
		TestSuite suite = new TestSuite("Test for fr.javasioux.gridgain");
		suite.addTestSuite(ClientDaoTest.class);
		// ...
	}
}

L’annotation @GridifyTest permet d’exécuter la suite de tests sur la grille, de même que si j’avais déclaré GridJunit3TestSuite au lieu de la simple TestSuite.

C’est censé fonctionner avec JUnit 4 également (GridJunit4Suite) mais j’ai essuyé quelques exceptions m’empêchant d’aller au bout…

Alors bien sûr, ce n’est pas magique et pour distribuer les tests, il faut bien un ou des noeuds sur lesquels les distribuer. Dans le répertoire bin de l’installation de grigain se trouve un fichier gridgain-junit.bat (ou .sh). Lancez le autant de fois que vous souhaitez de noeud. Bien entendu il s’agit du mode le plus simple de tester, en local tout sur la même machine.

Mais ce n’est pas tout. Plusieurs choses restent à configurer. Et plutôt que de le faire dans eclipse comme la vidéo d’exemple le montre, je vais le faire dans Maven…

Maven

Dépendances

Avant de rentrer dans les détails techniques, quelques généralités. Tout d’abord, les dépendances :

	
		gridgain
		GridGain Repository
		http://www.gridgainsystems.com/maven2/
		
			false
		
		
			true
		
	



	
		junit
		junit
		4.4
		test
	
	
		org.gridgain
		gridgain
		2.1.1
		test
	

Il faut ajouter le repo gridgain car les dépendances ne sont pour le moment pas dans le repo central.

Compilation 1.5

Compilation en 1.5 pour le support des annotations :

			org.apache.maven.plugins
			maven-compiler-plugin
			
				1.5
				1.5
			
		
		
	

Exécution de la suite sur la grille

	1.6.4




			org.apache.maven.plugins
			maven-surefire-plugin
			2.4
			
				
				
					**/GridTests.java
				

				
				-javaagent:${basedir}/target/libs/aspectjweaver-${aspectjweaver-version}.jar
				${basedir}/target/libs/
			
		

		

			org.apache.maven.plugins
			maven-dependency-plugin
			
				
					copy
process-resources
					
						copy
					
					
						
							
								org.aspectj
								aspectjweaver
								${aspectjweaver-version}
								${project.build.directory}/libs/
							
						
					
				
			
		
	

• Premièrement, j’exclue les tests pour n’ajouter que la ou les suites de tests.
• Ensuite, on a besoin de préciser le javaagent (doc officielle), en l’occurence aspectj weaver.
• Et pour que le javaagent retrouve ses petits, il faut copier le jar dans le répertoire pointé par le javaagent.

Un point important qu’on ne voit pas dans le pom est la présence du META-INF/aop.xml (disponible dans gridgain-x.x.x/config/aop/aspectj/) dans les ressources du projet (src/test/resources). Effectivement ce répertoire doit être dans le classpath.

Exécution

Comme je le disais plus haut, il faut lancer autant d’instances que nécessaire dans le répertoire bin de gridgain. Ensuite, depuis votre projet mave, lancez simplement un mvn test -DGRID_ROUTER_PREFER_REMOTE=true

-------------------------------------------------------
 T E S T S
-------------------------------------------------------
Running fr.javasioux.gridgain.GridTests
[00:56:01,906][INFO ][main][GridKernal%junit]
  _____      _     _  _____       _
 / ____|    (_)   | |/ ____|     (_)
| |  __ _ __ _  __| | |  __  __ _ _ _ __
| | |_ | '__| |/ _` | | |_ |/ _` | | '_ \
| |__| | |  | | (_| | |__| | (_| | | | | |
 \_____|_|  |_|\__,_|\_____|\__,_|_|_| |_|

...

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

Et voilà ! On a un build Maven qui exécute les tests en parallèle sur plusieurs noeuds.

Conclusion

Ecrire des tests, c’est bien… Les executer, c’est mieux ! Et donc si vous avez arrete de les executer car vous etes perpetuellement en train d’attendre qu’ils soient termines, gridgain peut vous aider. Ce framework de cloud permet (entre autre) de dispatcher les tests en parallele sur differents noeuds et ainsi diminuer la duree du build.

Toutefois, lancer plusieurs fois gridgain-junit.bat sur son poste fini par plomber le temps de build plutot que de l’ecourter. Il faut donc mettre en place une vraie infrastructure de cloud sur des serveurs / VM distantes pour y gagner. Je suis parvenu à utiliser gridgain dans un JBoss local (Mac OS) depuis une VM Windows (Gridgain peut découvrir les noeuds faisant partie de la grille) :

Sur l’integration continue, cela peut egalement etre utile pour alleger la charge sur serveur. L’ideal serait de pouvoir combiner cette fonctionnalite avec les possibilites de build distribue fournies par les principaux acteurs du marche (Teamcity, Hudson) et ainsi lancer les tests sur lea agents deja configure. A quand un plugin Hudson Gridgain ?!