Jean-Yves, Bricolage et Bidouilles

J'avais dans l'idée de faire un blog perso et un blog plus pro, comme je n'arrive pas à mettre à jour ni l'un ni l'autre, j'ai décidé de n'en garder qu'un qui sera , j'en ai d'ailleurs profité pour le mettre à jour sous dotclear 2.X

Donc plus de posts ici, je vais d'ailleurs reprendre mes anciens posts et les tranférer vers ce blog unique.

Cela fait déjà un petit moment que je tourne autour de wicket et j'ai fini par me lancer à l'occasion d'un petit projet web utilisant spring. Comme d'habitude un petit tour chez Matt qui est une source inépuisable d'exemples, chez qui je télécharge appfuse-light en version "wicket".

On peut aussi s'inspirer du wicket phone book bien que le code soit un peu plus fouillis que celui de Matt.

C'est un peu déroutant au début, mais par contre très facile à tester (voir le wiki de wicket).

Conclusion, pas de conclusion car j'ai du abandonner pour reprendre Spring MVC, le projet devant utiliser JDK 1.4 ... A plus tard wicket

En cours de lecture , lorsque l'on commence a avoir pas mal de tests dans un projet il est temps d'avoir une vision un peu plus globale.

Bon je viens de mettre en place en plugin anti span à base Captcha, donc je rouvre les commentaires et j'essaie d'être un peu plus assidu.

Une autre façon de mesurer sa couverture de tests :

1. Modifier le code
2. Repasser les tests
3. Si les tests ne passent plus c'est que la couverture de tests est correcte, sinon il certains cas ne sont pas prévus par les tests.

Il existe des outils qui font le boulot de "destruction de code automatiquement", comme jtester par exemple. Pratique pour ceux qui n'ont pas un collégue avec des gros doigts sous la main :).

Voir aussi l'article d'IBM sur le sujet ainsi que la page du wiki XP Developer . Encore un truc à tester et à mettre en oeuvre.

Découverte aussi récemment du "test en continu", affaire à suivre

Ce qui est un peu énervant avec Maven c'est la fiabilité des plugins, tant que l'on ne fait pas mvn -U tout va bien, mais dés que l'on met à jour les plugin c'est le début des ennuis.

Ca m'est arrivé ce matin avec l'assembly plugin qui s'est mis à bricoler sur un projet qui date de plusieurs semaines ....

La solution revenir en arrière sur la version :

<artifactId>maven-assembly-plugin</artifactId>
              <version>2.1</version>

Quelle idée aussi de mettre des version beta dans le repository officiel !

Dette technique et code "boulet"

La dette technique mesure le côté brouillon ou périmé des travaux de développement d'un logiciel. Au fur et à mesure la masse de code "boulet" vous rattrape.

Une page marrante mais instructive sur les pratiques de l'extreme programing.

J'ajouterais, les banlieues de code, partie du code ou l'on ose plus mettre les mains de peur de tout casser, que l'on contourne par du nouveau code qui fait a peu près la même chose mais un peu plus avec les bugs que l'on rajoute ....

Une page de pub

Vu sur le blog de Jquery Un exemple de ce que l'on peut faire avec du CSS et Jquery, impressionnant !!

Ca y est je suis passé sans douleur de Edgy vers Feisty, je commence même à utiliser tout çà pour travailler c'est pas gagné.

La litérature déborde d'informations sur la façon de faire des test unitaires sur des classes simples et autonomes.

Lorsque l'on creuse un peu plus on arrive vite à avoir besoin d'utiliser des objets factices ou encore 'Mock Object', ce que encore une fois l'on fait facilement grâce à des librairies comme JMock, que je ne saurais trop conseiller d'ailleurs car son utilisation, une fois passé l'écueil de la documentation un peu sommaire, est assez facile.

Après avoir passé quelques heures à tester et à implémenter des classes simples, on se retrouve à implémenter les couches basses de l'application qui font appel à des librairies non conçues pour les tests unitaires (n'utilisant pas d'interfaces).

Comment procéder lorsque l'on doit tester d'une manière unitaire le code suivant ?

(Ce n'est pas forcément l'implémentation optimum d'un client TCP, mais disons que cet exemple est la pour illustrer la méthode de test :)).

   public boolean sendMessage(byte message, int length) {
       Socket socket = null;
       try {
           socket = new socket(inetAddress,portnumber);
           OutputStream outPut =socket.getOutputStream();
           outPut.write(message, 0, length);
           outPut.close();
       } catch (IOException e) {
           return false;
       }
       return true;
   }

La classe Socket et OutputStream, ne sont pas des implémentations d'interface, et il est donc impossible d'utiliser JMock pour vérifier que leur appel est bien effectué, ou de simuler le comportement de problème réseau qui peuvent lever des IOException. Pourtant il serait bien pratique de le faire et éviterai d'avoir à tester manuellement les cas de connexion et déconnexion réseau en devant enlever ou remettre le câble réseau de la machine.

Première solution, on laisse tel quel et on testera à la main.

Deuxième solution, qui une fois que l'on a trouvé la façon de faire ne parait pas si difficile, ecrire soit même des object factices qui seront renvoyé par une 'SocketFactory' que l'on pourra elle même utiliser d'une manière factice grâce à JMock. Ces objets héritent des objets que l'on ne peut pas tester et l'on peut facilement surcharger les méthodes que l'on veut pouvoir simuler.

• Ecrire la classe factory qui renverra l'implémentation de la socket

   public class SocketFactoryImpl implements SocketFactory {
   
       public Socket createSocket(InetAddress address, int port)
                           throws IOException {
   
       return new Socket(address,port);
       }
   
   }

• Utiliser cette factory pour renvoyer la Socket à la classe utilisatrice.

   protected boolean sendMessage(byte message, int length) {
       Socket socket = null;
       try {
           socket = socketFactory.createSocket(inetAddress, portNumber);
           OutputStream outPut =socket.getOutputStream();
           outPut.write(message, 0, length);
           outPut.close();
       } catch (IOException e) {
           return false;
       }
       return true;
   }

• Ecrire dans le test unitaire des classes factices Socket et OutputStream

   private class MockOutputStream extends OutputStream {
       
       public  boolean writeCalled = false;
       public  boolean closeCalled = false;
       public boolean sendException = false;
       
       public void write(byte b, int off, int len) throws IOException {
           if (sendException) throw new IOException("MockOutputStream exception");
           writeCalled = true;
       }
       
       public void close() throws IOException {
           closeCalled = true;
       }
       /* (non-Javadoc)
        * @see java.io.OutputStream#write(int)
        */
       @Override
       public void write(int b) throws IOException {
           
       }
       
   }
   private class MockSocket extends Socket {
       
       public boolean sendException = false;
       public boolean closeCalled = false;
       private OutputStream outputStream;
       
       public void setOutputStream(OutputStream outputStream) {
           this.outputStream = outputStream;
       }
       public OutputStream getOutputStream() throws IOException {
           if (sendException) throw new IOException("mock exception");
           return outputStream;
       }
       
       public synchronized void close() throws IOException {
           if (sendException) throw new IOException("mock exception");
           closeCalled = true;
       }
       
   }

Une fois ces deux classes écrite il est facile de les utiliser pour simuler un comportement réseau hératique.

Exemple :

   public void testSendMessage() {
       MockOutputStream mockOutputStream = new MockOutputStream();
       MockSocket mockSocket = new MockSocket();
       mockSocket.setOutputStream(mockOutputStream);
       socketFactory.expects(once()).method("createSocket").will(returnValue(mockSocket));
       
       assertTrue ("message not sent",tcpLink.sendDataMessage(new byte32, 32));
       
       assertTrue("output stream write not called",mockOutputStream.writeCalled);
       assertTrue("output stream close not called",mockOutputStream.closeCalled);
       assertTrue("socket close not called",mockSocket.closeCalled);
   }
   
   public void testSendMessageSocketException() {
   
       MockOutputStream mockOutputStream = new MockOutputStream();
       MockSocket mockSocket = new MockSocket();
       mockSocket.setOutputStream(mockOutputStream);
       mockSocket.sendException = true;
       socketFactory.expects(once()).method("createSocket").will(returnValue(mockSocket));
       
       assertFalse ("message should be not sent",tcpLink.sendDataMessage(new byte32,32));
       
   }

Cette solution est bien entendu applicable lorsque l'on a peu de cas possibles ou de méthodes à tester, dans le cas contraire le nombre de combinaisons possibles deviendrait assez élevé et la complexité de l'implémentation des objets factices rendrait les tests difficile à écrire et donc non exempts de défaut.

Il y a d'autres pistes à creuser, comme l'utilisation d'une classe de délégation ou l'utilisation d'une classe dérivée implémentant une interface similaire à la classe à simuler. Peut être à un prochain billet pour décrire ces deux méthodes.

Première étape d'intégration d'Xplanner et de Mylar en utilisant le connecteur web generique

Matt Raible s'est laché ce week-end, beaucoup d'articles avec un contenu très dense.

• TSE Keynote: The Bigger Picture with Adrian Colyer, Un tour d'horizon des sous projets de Spring : SFW, SWF, SWS, S-OSGi. Les services d'entreprise clustering, persistence, messaging et scheduling. Les tendances du moment: SAO, Web 2.0/RIA, RAD stacks. Je rajouterai à tout çà le projet de validation.

• A suivre de près Spring-OSGI with Adrian Colyer

• Spring-OSGI with Adrian Colyer

• Selenium Plugin for Maven, A mettre en place au plus vite !

• Designing Stateful Web Application Control Flow with Erwin Vervaet Spring Web Flow.

• Using Dynamic Languages with Spring with Rod Johnson and Guillaume LaForge

• Rapid Web Application Development with Rob Harrop

Beaucoup de choses à lire et à faire ....http://www.thespringexperience.com/

Affaire à suivre, téléchargé le plugin aujourd'hui j'essaye d'intégrer avec Xplanner dés que j'ai le temps. ^[1] Mylar is a task focused UI for Eclipse that makes working with very large workspaces as easy as working with small ones. It makes tasks a first class part of Eclipse, and integrates task repositories such as Bugzilla, Trac, and JIRA.

Mylar est une interface orienté tâches pour Eclipse, qui permet de travailler avec des workspaces très grand ou très petit.... Il peut intégrer des gestionnaires de tâches comme Bugzilla, Trac ou JIRA.

En plus on peut facilement ? intégerer des outils 'web based'. Si j'ai bien compris, je travaille sur un tâche (correction de défaut, ajout, modification), lorsque j'ai fini la tâche, j'ai ouvert un tas de chose sur mon "bureau Eclipse". Si je désire revenir sur la tâche, mon environnement se repositionne automatiquement dans la même configuration que lorsque j'ai quitté la tâche en question.

• Un témoignage d'un utilisateur content ici

Modifs du 07-Dec-2006

Après quelques heures de galére de de googleage, je livre tout cru le fichier de configuration Spring C3p0 Hibernate qui fonctionne avec MySQL et qui tiens la distance en espérant que cela pourra servir à quelqu'un.

La première config n'était pas si bonne que cela, ci-dessous les corrections à apporter ... (Ce coup ci j'ai vérifié !). Voir tout en bas de la doc C3p0 le paragraphe sur la configuration avec hibernate.

Reste encore à régler le problème du cache.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
    "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
    <bean id="c3p0dataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
        <property name="driverClass" value="${jdbc.driverClassName}"/>
        <property name="jdbcUrl" value="${jdbc.url}"/>
        <property name="user" value="${jdbc.username}"/>
        <property name="password" value="${jdbc.password}"/>
        <property name="acquireIncrement" value="1"></property>
        <property name="minPoolSize" value="5"></property>
        <property name="maxPoolSize" value="50"></property>
        <property name="acquireRetryAttempts" value="10"></property>
        <property name="preferredTestQuery" value="SELECT 1"></property> 
        <property name="testConnectionOnCheckin" value="true"></property>
        <property name="testConnectionOnCheckout" value="false"></property>
        <property name="maxIdleTime" value="50"></property>
        <property name="idleConnectionTestPeriod" value="30"></property>
    </bean>

    <bean id="sessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
        <property name="dataSource" ref="c3p0dataSource"/>
        <property name="mappingResources">
            <list>
                   ................................... 	
	   </list>
        </property>
        <property name="hibernateProperties">
            <props>
               <prop key="hibernate.dialect">${hibernate.dialect}</prop>
               <prop key="hibernate.hbm2ddl.auto">update</prop>
		<prop key="hibernate.connection.release_mode">on_close</prop>
               <prop key="hibernate.c3p0.acquire_increment">1</prop>
               <prop key="hibernate.c3p0.minPoolSize">2</prop>
               <prop key="hibernate.c3p0.maxPoolSize">50</prop>
		<prop key="hibernate.c3p0.timeout">1800</prop>
		<prop key="hibernate.c3p0.max_statement">0</prop>  
		<prop key="hibernate.c3p0.idle_test_period">30</prop>          
	     </props>
        </property>
    </bean>
</beans>