Mot-clé - testing

Fil des billets - Fil des commentaires

Un rapport de tests clair avec Test in Progress

Logo jenkins

Logo jenkinsQuand les tests ne passent plus sur l'intégration continue, le(s) coupable(s) ne saute pas tout de suite aux yeux.

Il n'y a pas non plus d'indication sur la durée d'un test et vous ne savez pas s'ils sont bientôt terminés.

Le tout nouveau plugin Test in progress pour Jenkins vous assiste sur ces aspects.

Lire la suite

ROI des tests automatiques

dollar.jpg

dollar.jpgL'industrie du logiciel est encore loin d'avoir systématiquement des tests automatiques. Le coût est tout de suite visible et rédhibitoire, contrairement à son gain. Personnellement, j'en fais dans mon développement car il me donne de la confiance et m'aide à construire le produit. Pourtant, certaines personnes restent hermétiques à mon enthousiasme. Entre deux réponses à un appel d'offres, un client lambda privilégiera la plus "compétitive" (= la moins chère), quitte à en payer le prix plus tard.

Les clients les plus sensibles à la cause se demandent jusqu'où il faut aller. Est-ce qu'il faut absolument tout tester? Est-ce que la valeur apportée vaut son coût ? Il y a un pallier où la qualité supplémentaire n'a plus de ROI. Je peux fabriquer des biscuits parfaitement rectangulaires mais il n'est pas dit que ma fille de dix ans apprécie le geste outre mesure. Elle ne s'en rendra probablement même pas compte. Je ne sais pas non plus apprécier un couteau damassé 32 couches avec un manche imputrescible à 350 €. Il n'existe pas de ressources illimitées, qu'il s'agisse de temps ou d'argent. Nous ne souhaitons pas que nos produits soient parfaits à tous les niveaux, car cela couterait trop cher. Alors, où s'arrêter ?

Lire la suite

Tester des scripts shell avec ShUnit2

Originellement développé par Vera Peeters and Rik Tytgat, ShUnit a été le premier outil de tests unitaires en shell.

Il permet de valider que vos scripts shell effectuent bien ce que vous en attendez. Intégrez vos tests shunit à votre usine de développement et vous serez assurés qu'ils resteront valides de façon permanente, qu'ils ne souffriront d'aucune régression sans vous en alerter.

Je vous propose de me suivre sur les traces d'un framework un peu plus xUnit like : ShUnit2 de Kate Ward.

Lire la suite

Accelerez vos tests manuels des IHM

Log fireform

Log fireformLes tests automatisés, décidément, c'est vraiment bien. Pourtant sur les IHM, leur implémentation est souvent trop couteuse pour exister durablement. C'est en ayant fait beaucoup à la main ces derniers jours que je bénis vraiment hudson, fitnesse et junit. Et j'admire ceux qui ne font toujours pas de tests automatisables ;-)

J'ai rarement besoin de tester à la main, mais quand ça m'arrive, j'ai vraiment envie de me tirer une balle. Entre deux clics, j'ai essayé de trouver des outils facilement intégrable à firefox pour alléger mon fardeau, en l'occurence : selenium, autofill form, form saver et fireform. Petit bilan.

Lire la suite

Session : comment écrire du code testable

 J'ai eu le plaisir d'animer la session "Comment écrire du code testable" à la conférence Agile France 2010. C'est l'heure de mettre les slides à disposition et de faire une rétrospective !

Connaître les symptômes d'un code intestable vous permettra de mieux vous en débarrasser :
  1. Un constructeur cher
  2. Des instanciations directes
  3. Des blocs statiques
  4. Une dynastie de classes
  5. Des états globaux
  6. Annuaire de service
  7. Interroger des collaborateurs
  8. Des classes hyperactives
  9. Des méthodes trop chargées
  10. Mélanger les objets valeurs et les objets services

Lire la suite

Différentes expériences du TDD

givenWhenThen.jpg

givenWhenThen.jpg

Le projet sur lequel je suis actuellement va bientôt partir en production. Pas d'agilité dans mon équipe (malheureusement) mais quelques bonnes pratiques comme une réunion d'avancement quotidienne, l'utilisation d'une usine logicielle et le développement sous forme de TDD. Il s'agit d'une équipe qui a commencé à environ 8 personnes (projet critique donc on charge la mule au début) pour finir à 2 personnes.

Des TDD, oui ! Mes lesquels ?

Qui dit équipe de 8 personnes, dit expériences différentes de développement. Qui dit projet critique dit pression et donc pas le temps de faire du binômage ni de la revue de code. Argh.

Lire la suite

Soat à l'agile conférence

Agile Conference 2010

Nous tiendrons deux sessions à l'agile conférence (ex-XPDays) les 31 Mai et 1er Juin : un atelier fun et une conférence geek. Survivre sur la lune avec la NASA ou l’importance de travailler en groupe L'idée de l'atelier est de démontrer que pour résoudre un problème, 1111 est bien plus fort que  […]

Lire la suite

Don't Look For Things, de M. Hevery

J'entends assez souvent "il faut", "il ne faut pas", comme si c'était une loi venant d'une instance suprême. Ce n'est pas un reflexe de remettre les choses en cause et de se demander pourquoi on fait quelque chose. Questionner n'est pas forcément bien vu non plus et peut heurter. C'est la force de l'habitude.

Si un projet plante, et que le manager n'a rien fait de "spécial", on se dira que c'est la faute à pas de chance. S'il a eu le malheur d'innover, en mettant en place des méthodes agiles par exemple, alors il y a de grandes chances pour que ce soit cette innovation qui soit pointée du doigt. Quelque part, suivre sans interroger se comprend, nous supposons que d'autres gens se sont déjà penchés sur la question. Heureusement que nous avons un minimum confiance en notre passé.

Extrait d'une conversation :

Bonnie : On devrait regrouper les imports statiques des matchers JUnit que l'on utilise dans une librairie à part, et ne faire qu'un seul import.

Clyde, hésitant : S'ils sont amenés à être utilisés ensemble, pourquoi le framework ne met pas directement tout dans un seul import ou dans le même package? Plutot que pousser chacun à tout repackager?

Bonnie : C'est une bonne pratique, même sur Xebia ils le disent. Si tu ne me crois pas, tu peux demander aux architectes, ils te diront la même chose.

Ah bah s'ils le disent... Autant vous dire que l'argument qui tue "c'est Jacques que tout le monde respecte qui l'a dit" a beaucoup aidé Clyde.

Cela n'empêche pas Bonnie d'avoir raison. Un argument est évoqué dans Clean Code, elle concerne les API externes en général. L'idée est de réduire le couplage de notre code avec les API externes tout bêtement. Si elles changent, il n'y aura qu'un endroit à changer. Depuis, j'ai cette "note pour moi-même" : même si les raisons me paraissent évidentes, elles ne le sont pas pour tout le monde, il vaut mieux dire d'emblée pourquoi je pense qu'il vaut mieux faire ci que cela.

Je m'égare, je m'égare. Là où je voulais en venir, c'était qu'on m'avait fait remarquer un jour "qu'il ne faut pas faire travailler un constructeur, même pas en appelant une méthode init()". Je savais cela, mais honnêtement, je ne savais pas très bien pourquoi. Du coup, quand un petit travail dans le constructeur me facilitait la vie, je le faisais quand même...

Et bien voici une raison, citée par Misko Hevery dans Don't Look For Things : pour poser un test sur un objet, l'opération que l'on ne peut absolument pas éviter est d'instancier l'objet et donc d'invoquer le constructeur. S'il y a des opérations compliquées dans le constructeur, nous sommes obligés de faire avec dans les tests. Et tous les tests utilisant cet objet en tant que collaborateur auront le même boulet à trainer (à moins d'avoir un framework magique qui permette de mocker les constructeurs).

Lire la suite

Tutoriel JMockit

Un petit post pour signaler que l'article "Comment tester du code intestable avec JMockit" est en ligne sur Developpez. A la base, ce blog a été crée comme "brouillon" pour écrire des tutoriaux, en particulier sur JMockit. Entre temps, le framework a pas mal évolué. L'article de  […]

Lire la suite

JMockit devient beaucoup moins contraignant

Je suis en train d'écrire l'article JMockit pour developpez, en testant avec la version 0.993 et je vais de surprise en surprise. En plus d'avoir développé d'autres API (JMockit Verifications pour le BDD), d'avoir mavenisé le projet, sans parler des efforts sur la documentation, Rogerio Liesenfeld  […]

Lire la suite

Serveur d'intégration continu PHP pour fitnesse

Il y a quelques temps, j'ai travaillé sur un projet PHP appelé "network" pour mettre en place l'infrastructure agile. Le projet était tout nouveau, il avait à peine un ou deux mois d'existence avant mon arrivée. Conséquence : quasiment pas de dette technique et il est encore temps de poser les tests fonctionnels. Pour automatiser le lancement de ces tests, nous avions crée 4 scripts, tous programmés dans une crontab :

  • commit-fitnesse.sh
  • run-fitnesse-tests.sh
  • update-application.sh
  • launch-fitnesse-server.sh

En parallèle, nous avons deux applications qui tournent sur le serveur :

  • network, qui sert aussi de demo
  • fitnesse, pour pouvoir créer des tests fonctionnels et enregistrer les résultats des tests lancés.

C'est oldschool, mais cela nous a bien servi !

Lire la suite

Inheritance, Polymorphism & Testing de Misko Hevery

Il était une fois un bout de code que je voulais refactorer car il me semblait très redondant. Le hic est que les parties similaires étaient en "sandwich", ce qui m'a fait utiliser le polymorphisme. J'étais assez contente de moi mais un doute subsistait.... est ce que je me faisais plaisir pour la beauté du code ou est ce que mon refactoring avait un réel intérêt, autre qu'économiser quelques lignes redondantes?

La présentation "Inheritance, Polymorphism, & Testing" aborde justement le sujet du polymorphisme par rapport aux conditions.

Pourquoi le polymorphisme plutot que des conditions?

Misko part du principe où tous les ifs pourraient être remplacés par du polymorphisme. Les avantages sont que :

  • les fonctions sans if sont plus faciles à lire
  • et plus faciles à tester
  • les systèmes polymorphiques sont plus simples à maintenir. Il est aisé d'ajouter des nouvelles méthodes : il suffit de les rajouter aux sous classes, pas la peine de parcourir le code à la recherche des blocks ifs.

Lire la suite

Unit Testing de Misko Hevery

Misko Hevery est un développeur chez Google et aborde de nombreux aspects des tests unitaires sur son blog et lors de Google TechTalks.

Je vous fais un petit topo sur la conférence Unit Testing qu'il a donné, la présentation originale est disponible sur youtube.

Le code réellement difficile à tester est caractérisé par

  • un mélange de new et de la logique
  • le fait de chercher des choses (<=> par des lookups notamment)
  • du traitement dans le constructeur
  • des états globaux

plus que par des méthodes longues et/ou privées.

Il y a 3 types de tests, du moins au plus nombreux :

  • les tests par scénario : un cas d'utilisation de l'utilisateur, tel qu'il le percoit et de bout en bout. Exemple : l'utilisateur se connecte sur l'application et saisit un mauvais mot de passe.
  • les tests fonctionnels : une fonctionnalité de l'application testé de facon isolée. Exemple : un autoradio d'une voiture.
  • les tests unitaires : une methode d'une classe. Exemple : Service.hello().

Lire la suite

JMockit : comment migrer vers la version 0.97 ou plus

Petit essai express En suivant la documentation officielle de migration, voici ce qu'il en ressort. Concernant le paramètre javaagent qui ne serait plus nécessaire, ce n'est pas si évident... Que ce soit avec Java 5, 6 avec ou sans la nouvelle annotation @RunWith(JMockit.class), mes tests semblent  […]

Lire la suite

Accelérez vos tests avec Twip

Twip se base sur les tests paramétrés de JUnit 4.5 pour permettre la factorisation des tests.

Il m'arrive souvent d'avoir les memes expectations quelques soient les valeurs d'une variable. Pour un booléen par exemple, cela me fait faire deux tests, une avec true comme valeur, un autre avec false.

Avec Twip, un seul test suffit :

@Test
void myTest(boolean flag) {
    String toto = makeItTrue(flag);
    assertEquals("toto","true",flag);
}

Lire la suite

Eclipse plugins for java

My favorite plugins for Eclipse : M2Eclipse for maven, Spring IDE, Subclipse for Subversion, Jadclipse to decompile classes, Java source helper and Properties Editor.


My very short list


M2Eclipse for maven

Resolves the project dependencies with maven, displays the tree of dependencies (why X.jar is returned), makes it easy to add a dependency to the pom by parsing the repository... Also provides a decoration label to display the current version of a project.

http://m2eclipse.sonatype.org/update/

Spring IDE

Autocompletion for classes, properties name and validation.

http://dist.springframework.org/release/IDE

Subclipse for subversion

Subversion options with a synchronizing feature as a bonus : it prevents unfortunate commits to be done. Also "override and update" is useful.

http://subclipse.tigris.org/update_1.6.x or http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA

Jadclipse for jad

Opens .class files with jad instead of the annoying "no source found".

http://jadclipse.sf.net/update

Jora for Oracle

Avoids having a greedy Toad opened and provides much better and quicker auto completion (tables, fields). It has less features than toad but it is enough for my use and make the features accessible more easily (SQL History, oracle functions).

http://jora.luenasoft.de/updatesite or http://jora.luenasoft.de

More Unit

Decorates classes that have tests and make you switch from the class to its test in one shortcut (Ctrl+J). I just wish there were also a shortcut to run the test even when we are on the tested class.

http://moreunit.sourceforge.net/org.moreunit.updatesite or http://moreunit.sourceforge.net/

Lire la suite

JMockit Core | Expectations : creer une implémentation vide d'une interface?

Il y a les objets que l'on souhaite mocker parce que l'on en attend des choses (que telle méthode soit appelée, avec tel paramètre) et les objets que l'on souhaite simplement bouchonner betement, pour affranchir notre test unitaire des dépendances de l'objet testé.

Les expectations de JMockit rempliront le premier besoin. La méthode newEmptyProxy de JMockit comblera des besoins plus simples, comme celui d'avoir une implémentation vide d'une interface.

Lire la suite

Haut de page