Posts Tagged ‘test unitaire’
Hello, j’en avais un peu marre d’écrire régulièrement voire répétitivement dans mes tests les constructions mockito.
Pour ça je me suis créé dans mon IDE favori, IntelliJ, ce qu’on appelle des Live Template. Ces templates permettent à partir d’une abréviation d’insérer des fragments de code. Ainsi par exemple :
Taper iter dans votre éditeur puis de faire Ctrl+J (sous OSX) va développer cette abréviation dans le bout de code ci-dessous (suivant le contexte bien entendu)
for (TypeInIterable type : someIterable) {
}
Taper sur Ctrl+J (sous OSX) vous permet de lister les abréviations disponible dans le contexte courant.
Les Live Template pour Mockito
Bien qu’imparafaite pour des raisons de limite technique d’IntelliJ, elles sauvent un minimum de temps, multiplié par le nombre de test. Malheureusement il n’y a pas non plus d’import export uniquement pour les live template, il faut donc se taper la configuration de intellij à la main. Cela dit il est possible de contourner partiellement ce problème avec la sauvegarde de la configuration personnelle sur les serveurs intellij, ou encore d’exporter la configuration pour les live templates, les file templates, et encore autre chose.
J’ai défini toutes ces annotations dans un nouveau groupe ‘test’, et j’ai activé pour toutes le contexte Java, avec reformatage et simplification du nom qualifié.
- Description : Creates a field with the @Mock annotation
Abbréviation : ‘am’
Template text :@org.mockito.Mock private $TYPE$ $MOCK_FIELD$
Les variables du templates sont :
Name Expression Default value Skip if defined TYPE variableOfType(“Object”) MOCK_FIELD suggestVariableName() - Description : Creates a field with the @Spy annotation
Abbréviation : ‘as’
Template text :@org.mockito.Spy private $TYPE$ $MOCK_FIELD$
Les variables du templates sont :
Name Expression Default value Skip if defined TYPE variableOfType(“Object”) MOCK_FIELD suggestVariableName() - Description : Creates a field with the @InjectMocks annotation
Abbréviation : ‘aim’
Template text :@org.mockito.InjectMocks private $TYPE$ $MOCK_FIELD$
Les variables du templates sont :
Name Expression Default value Skip if defined TYPE variableOfType(“Object”) MOCK_FIELD suggestVariableName() - Description : Add @RunWith(MockitoJUnitRunner.class)
Abbréviation : ‘rwm’
Template text :@org.junit.runner.RunWith(org.mockito.runners.MockitoJUnitRunner.class)
- Description : BDD Stub mock with given(…).willReturn(…) style
Abbréviation : ‘gw’
Template text :given($MOCK$).willReturn($ARGS$)$END$
Les variables du templates sont :
Name Expression Default value Skip if defined MOCK variableOfType(“Object”) ARGS - Description : BDD Stub spy/mock with willReturn(…).given(…) style
Abbréviation : ‘wg’
Template text :org.mockito.BDDMockito.willReturn($RETURNED$).given($MOCK$).$CALL$ $END$
Les variables du templates sont :
Name Expression Default value Skip if defined RETURNED complete() MOCK variableOfType(“Object”) CALL complete() - Description : Inserts a verify(…) statement
Abbréviation :‘verif’
Template text :org.mockito.Mockito.verify($MOCK$).$CALL$
Les variables du templates sont :
Name Expression Default value Skip if defined MOCK variableOfType(“Object”) CALL complete() - Description : Inserts Mockito.inOrder(mocks) followed by inOrder.verify(…) statement
Abbréviation : ‘ioverif’
Template text :org.mockito.InOrder $inOrderVar$ = org.mockito.Mockito.inOrder($MOCKS$); $IN_ORDER_VAR$.verify($MOCK$).$CALL$;
Les variables du templates sont :
Name Expression Default value Skip if defined IN_ORDER_VAR suggestVariableName() MOCKS variableOfType(“Object”) MOCK variableOfType(“Object”) CALL complete() - Description :Inserts a verify(…) statement
Abbréviation :‘verif’
Template text :$IN_ORDER_VAR$.verify($MOCK$).$CALL$;
Les variables du templates sont :
Name Expression Default value Skip if defined IN_ORDER_VAR variableOfType(“org.mockito.InOrder”) MOCK variableOfType(“Object”) CALL complete()
Voilà donc les templates que je me suis créé pour IntelliJ, il manque certainement des cas d’utilisation, mais je trouvais plus judicieux de mettre ces cas là au moins. Pour nos amis Eclipse oou Netbeans, il y a des fonctionnalités comparables plus ou moins évoluées (de mémoire le système d’Eclipse est plutôt pas mal).
Références
Vous devez écrire du code qui fait appel à JMX, en bon citoyen et bon développeur vous voulez tester ce code.
Première approche; vous enregistrez vos MBean sur un MBeanServer, disons celui de la plateforme (avec Java 6 : ManagementFactory.getPlatformMBeanServer()).
mBeanServer.registerMBean(theMBean, theMBean.getObjectName());
Étant donné que MBeanServer étends MBeanServerConnection il est possible d’exécuter des querys, de faire des invocations sur les MBean etc. Si le code est suffisamment isolé des aspects techniques de connexion à JMX, vous passerez le MBeanServer en lieu et place de la MBeanServerConnection.
Supposons le code suivant.
public class OperateOnJMXConnection implements JMXOperation {
public void perform(MBeanServerConnection connection) {
// doing some stuff there
}
public Result getResult() { return result; }
}
Pour tester ce code il faudrait alors écrire :
@Test
public void do_not_fail() {
operateOnJMXConnection.perform(mbeanServer);
assertThat(result).satisfies(someCondition);
}
Mais voilà, vous restez en local, et par exemple si vous avez merdé sur la sérialisation de vos beans, vous ne verrez pas d’échec dans vos test et vous aurez une surprise en prod, ou avant si votre projet a un processus qualité décent.
Évidement il y a une solution, l’idée c’est de pouvoir se connecter au mBeanServer local à votre processus (typiquement dans maven 3, l’exécution de vos tests peuvent être forkée).
Alors j’ai essayé de récupérer les informations pour récupérer les informations de la VM qui tourne, mais bon on tombe dans des classes sun, j’ai préféré ne pas continuer sur ce chemin semé d’embûches, sans compter sur la faiblesse de cette approche.
Bref en relisant les articles de Khanh sur JMX, j’ai vu quelque chose d’intéressant JMXConnectorServerFactory. Cette classe permet donc de créer un JMXConnectorServer avec l’URL qu’on lui spécifie et d’un MBeanServer. A noter que cette URL doit respecter un certain formalisme tel que la javadoc l’indique : service:jmx:protocol:remainder.
Le protocole ne peut pas être n’importe quoi, il faut qu’il y ait le bon service enregistré pour qu’il soit géré. Dans notre cas RMI est standard, c’est donc le protocole que je prendrai. Pour le remainder, il s’agit plus d’une partie d’une URL, je vous laisse voir la Javadoc de JMXServiceUrl à ce sujet, mais dans les grandes lignes la forme doit être la suivante : //[host[:port]][url-path]
JMXConnectorServer connectorServer = JMXConnectorServerFactory.newJMXConnectorServer(
new JMXServiceURL("service:jmx:rmi://"),
null,
mBeanServer
);
connectorServer.start();
Hop dans le code précédent, on a créé puis démarrer notre JMXConnectorServer. Il n’y a plus qu’à se connecter dessus de manière standard :
Je vais utiliser connectorServer.getJMXServer() pour récupérer l’URL du service, il y a une raison à cela, c’est que comme l’indique la javadoc, l’URL passée pour la création du JMXConnectorServer peut être légèrement modifiée par celui-ci, il faut donc récupérer la nouvelle URL.
JMXConnector jmxConnetor = JMXConnectorFactory.connect(connectorServer.getJMXServiceUrl()); MBeanServerConnection connection = jmx.getgetMBeanServerConnection();
Et voilà vous avez accès à une MBeanServerConnection, qui vit dans la JVM locale, mais qui utilise RMI pour communiquer avec le MBeanServer, du coup vous êtes nettement plus proches des conditions du code de production et c’est ce qui nous intéresse dans cet article.
Pour référence les articles de Khanh, et en français s’il vous plait
:
- Partie 1 : http://jetoile.blogspot.com/2010/10/jmx-pour-les-nuls-les-concepts-partie-1.html
- Partie 2 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-differents-mbeans.html
- Partie 3 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-agents-jmx-partie.html
- Partie 4 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-les-classes-de-base.html
- Partie 5 : http://jetoile.blogspot.com/2010/11/jmx-pour-les-nuls-le-mbean-server.html
- Partie 6 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-chargement-dynamique.html
- Partie 7 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-les-services-jmx.html
- Partie 8 : http://jetoile.blogspot.com/2010/12/jmx-pour-les-nuls-les-connecteurs.html
Quelques liens javadoc :
Enfin je me suis créé une petite classe de commodité qui permet de créé facilement un loopback pour les TU :



Follow