Quand 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.
Je reviens d'un atelier SCJP (certification Java) et ça fait plusieurs mois que je voulais poster un petit billet à ce sujet. Il est organisé par les JDuchess (en particulier Katia) et vous pouvez vous inscrire sur le groupe google si vous souhaitez être tenus au courant ou participez virtuellement […]
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.
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.
Misko Hevery reprend dans Design for testability les différents points abordés lors de ses clean code talks.
En conséquence, si vous avez regardé les vidéos clean code talks, vous allez sentir quelques répétitions.
I really enjoyed the first part of the book and read it very fast. Then I got slower in the second part with the case studies. But I eventually finished it and I really don't regret purchasing it. Read the review of Clean Code....
Fitnesse is great, but it is not so easy to remember the wiki's syntax. I often found myself looking for an test I did months ago to remember how to use this or that. The cheat sheet on Fitnesse web site is a good start : http://fitnesse.org/FitNesse.UserGuide.QuickReferenceGuide. Richnesse is a […]
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).
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 […]
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 […]
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 :
En parallèle, nous avons deux applications qui tournent sur le serveur :
C'est oldschool, mais cela nous a bien servi !
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.
Misko part du principe où tous les ifs pourraient être remplacés par du polymorphisme. Les avantages sont que :
Je suis en train de lire Clean Code de Robert Martin et je me rends compte que ma facon de coder est beaucoup plus sale que je ne le pensais, en dépit de tous mes efforts. C'est un peu comme la musique : c'est facile de sentir que quelqu'un chante faux, c'est une autre histoire de savoir chanter juste. Ce livre apporte également beaucoup de réponses à des problématiques que j'avais rencontré, qui me génaient mais que je ne savais pas comment résoudre.
Le billet d'aujourd'hui concerne le recours aux méthodes privées. Ma facon de procéder était la suivante : je code, et s'il y a deux fois le meme code, je crée une méthode privée pour factoriser. J'aimais bien aussi tout avoir sous les yeux, dans la même méthode, plutot qu'éparpillée dans la classe.
L'approche de Martin est différente : le code propre doit se lire comme un roman. Les méthodes privées ont, de fait, un autre role : donner du sens au code. C'est seulement si nous souhaitons connaitre le détail que l'on rentre dans la méthode privée.
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
new et de la logiqueplus que par des méthodes longues et/ou privées.
Il y a 3 types de tests, du moins au plus nombreux :
Service.hello().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 […]
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);
}
Maven version clash plugin A plugin to make maven versions resolution more obvious, and therefore to avoid surprises. http://hexapixel.com/software/maven-version-clash-plugin
JMockit est en développement actif depuis quelques mois, et une montée de version au delà de 0.96 fera échouer les tests. Certaines nouveautés du framework brise en effet l'API : https://jmockit.dev.java.net/changes.html. Le créateur du framework est encore en train de recueillir les retours pour […]
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.
JMockit Annotation et JMockit Core impose la définition d'une classe de mock supplémentaire. JMockit Expectation permet d'effectuer des expectations sans redéfinir de classes de mock, même s'il a d'autres limitations (l'impossibilité de mocker un constructeur par exemple, ou une methode de classe abstraite).
Documentation officielle : https://jmockit.dev.java.net/javadoc/mockit/Expectations.html
Les blocs statiques peuvent devenir un véritable cauchemar lorsque nous essayons d'introduire des tests sur du code existant. Le bloc étant statique, nous avons beau mocker, il est tout de même appelé. Avec JMockit, il devient possible de mocker aussi ces blocs là !