Skip to content

By: Brice Dutheil

05 March 20126 comments code

Hello à tous,

Hackergarten Logo

Mercredi 7 mars (à 19h) aura lieu la 2ème session Hackergarten. Après Soat, on a le plaisir d’être hébergé par Valtech (103 Rue de Grenelle, 75007 Paris) et il y aura des pizzas, gros merci à eux.

Hackergarten c’est le rendez-vous des gens qui veulent participer aux projets opensource. L’idée c’est, dans un format de 3h, de contribuer un logiciel, un fix, un feature, une documentation dont d’autres pourraient avoir l’usage. Il s’articule autour de commiters actifs pour mentorer les hackers qui participent à l’évènement.

Bref que du bon. Pour la planification de l’évènement c’est par là ⇒ http://hackergarten-paris.eventbrite.com/

Alors pour éviter les soucis de setup le jour J, ce post donne quelques informations sur ce qu’il y aurait à récupérer ou faire en avance sur votre machine. Si vous avez des questions ou si vous voulez participez aux discussions : inscrivez vous sur la mailing-list à cette adresse ⇒ http://groups.google.com/group/hackergarten-paris/

Continue reading “Hackergarten Paris – ce qu’il faut savoir sur les projets” »

By: Brice Dutheil

19 December 2011no comments code, TDD

EDIT: Hop. Enfin la release 1.9.0 est dispo en téléchargement.

Après pas mal de travail avec des périodes plus ou moins intenses – bref les vicissitudes du développement Open Source – le projet sort une nouvelle version 1.9.0 en Release Candidate, avec des bugfixes et bien sûr des nouvelles features. Il y a un changelog mais dans les faits le billet suivant liste brièvement ce qui est nouveau. Ah oui la version est téléchargeable ici et bientôt disponible sur le central maven.

  • Pour être plus fluent et expressif, l’API introduit les alias then et will pour les réponses personnalisées (Answer). Ainsi que d’autres petits tweak de l’API:
    @Test
    public void engine_should_only_work_with_diesel() {
      given(engine.start()).will(throwExceptionIfEssenceInsteadOfDiesel());
      // ...
    }
    
    private Answer throwExceptionIfEssenceInsteadOfDiesel() {
      return new Answer<EngineStatus>() {
        public EngineStatus answer(InvocationOnMock invocation) {
          // answer code
        }
      };
    }
  • Les mocks peuvent maintenant être déclaré dans la configuration du stub, sur une ligne.
    DieselEngine de = given(mock(DieselEngine.class).start()).willThrow(TankIsEmpty.class).getMock();
  • On peut maintenant renvoyer la classe d’une exception plutôt que son instance.
    given(someMock).willThrow(IllegalArgumentException.class, SomethingIsWrongException.class);
  • Si jamais vous avez besoin de debugguer un bout de code ou les interactions sont non prédictibles, il est maintenant possible de loguer les invocations du mock ou de l’espion. Attention, bien qu’utile à l’occasion avec du code legacy, quand même si jamais ce besoin s’en fait sentir sur un nouveau développement c’est que ce code devient trop complexe.
    List mockedList = mock(List.class, withSettings().verboseLogging());
    mockedList.get(0);

    On pourra également ajouter des callbacks sur chaque interaction du mock.

    Observer observer = mock(Observer.class, withSettings().invocationListeners(listener1, listener2));
    willThrow(IllegalArgumentException.class).given(observer.update(observable, "what has changed"));
  • Pas mal de travail a été fait sur les annotations. Maintenant il n’est plus nécéssaire d’initialiser un champ annoté par @Spy s’il existe dans la classe un constructeur sans argument.
    @RunWith(MockitoJUnitRunner.class)
    public class SomeTest {
      // pas besoin d'initialiser le champs
      @Spy private ArrayList spiedArrayList;
    
      @Test public void verify_some_interactions() {
        spiedArrayList.iterator();
        verify(spiedArrayList, once()).iterator();
      }
    }
  • Et pour la fin mais pas des moindres, le mécanisme d’injection de mockito supporte maintenant l’injection par constructeur. A l’heure actuelle, seul les mocks et spies déclaré dans le test en tant que champs pourront être injecté dans le constructeur du champs annoté par @InjectMocks.
    @RunWith(MockitoJUnitRunner.class)
    public class EngineTest {
      @Mock Diesel diesel;
      @InjectMocks Engine engine;
    
      @Test public void engine_should_consume_Diesel() {
        engine.start();
      }
    }

    Ou Engine a un constructeur avec le paramètre Diesel.

    public class Engine {
      Diesel diesel;
      public Engine(Diesel diesel) {
        this.diesel = diesel;
      }
    
      public boolean start() {
        checkNotEmpty(diesel);
        // ...
      }
      // ...
    }

Pour l’instant en RC, cette release permettra d’adoucir les angles si nous en avons loupé certains éléments. N’hésitez pas à nous poser des questions sur la mailing list ou stackoverflow.

By: Brice Dutheil

21 October 2011no comments code, TDD

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é.

  1. 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()
  2. 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()
  3. 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()
  4. Description : Add @RunWith(MockitoJUnitRunner.class)
    Abbréviation : ‘rwm’
    Template text :

    @org.junit.runner.RunWith(org.mockito.runners.MockitoJUnitRunner.class)
    
  5. 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
  6. 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()
  7. 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()
  8. 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()
  9. 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

By: Brice Dutheil

18 October 2011no comments Uncategorized

Pas vraiment un article mais plutôt une astuce que j’ai utilisé pour afficher la valeur de certaines property.

Il faut ajouter dans la section build/plugins du pom une tache ant qui efera simplement un echo. A noter que cette tache est disponible dans la phase validate.

<build>
<plugins>

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.1</version>
        <executions>
            <execution>
                <phase>validate-property</phase>
                <goals>
                    <goal>run</goal>
                </goals>
                <configuration>
                    <tasks>
                        <echo>Displaying properties resolution</echo>
                        <echo>some.property]= ${some.property}</echo>
                        <echo>project.build.directory = ${project.build.directory</echo>

                        <echo>project.build.finalName= ${project.build.finalName}</echo>
                    </tasks>
                </configuration>
            </execution>
        </executions>
    </plugin>

</plugins>
<build>

Cela dit n’étant pas un expert maven, il y existe peut-être une solution plus élégante, un commentaire est le bienvenu dans ce cas.

By: Brice Dutheil

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()). Étant donné que MBeanServer étends MBeanServerConnection il est possible d’exécuter des querys, de faire des invocations sur les MBean etc….

Performance Optimization WordPress Plugins by W3 EDGE