.NET Continuous unit testing : a dream comes true

.NET Continuous unit testing : a dream comes true

For many years, I’ve been green with envy of those Java guys who could use tools like Infinitest and JUnitMax to continuously unit test their code.  My wait is finally over. Similar tools have now become available for the .NET platform!  Some of you may be wondering: “What’s the point of a continuous unit test tool?”  In short, a continuous unit testing tool provides you, the developer, with constant feedback about the state of your unit tests without requiring any manual intervention on your part. It tells you immediately when you break something by running the tests automatically as soon as you change the code.

A few tools started to come out last year:

●      ContinuousTests

●      .NET Demon

●      NCrunch

I have not used ContinousTests or .NET Demon.  Therefore, my intention in this article is not to compare these tools but to discuss my experience with NCrunch.

Running in the background

The first thing you notice when using NCrunch is that there is no need to save your file.  A simple keystroke will launch the continuous test runner in the background.  It does not interrupt your current work and you can always see the current status of your test in the Risk/Progress window.

Figure A – Progress Bar (1 failing test)

You can also see a more traditional detailed view of the tests in the Tests window.

Figure B – NCrunch Tests Window

Code Editor Integration

NCrunch offers visual indicators of the state of your tests directly in the source code editor.  All paths and lines of code covered by a working unit test (and the test themselves) have a green widget besides it.  There is a red widget in front of all failing tests or code that isn’t covered.

Figure C – Code Integration

Impact navigator

You can see which tests cover a specific line of code simply by clicking on the widget in front of the line.

Figure D – Impact Navigator

Conclusion

I’ve been using NCrunch for a few months and have been extremely satisfied with it.  It runs smoothly on almost every existing solution I have tried it on.  The very few bugs I have had were all related to specific configuration errors within a solution.

NCrunch is free for the beta testing period but will be sold as a commercial product when it officially comes out.  .NET Demon, from RedGate, has the same disclaimer.  I guess (and hope) those products will be reasonably priced.  Not all employers will invest on a tool that does not necessarily increase the developers’ productivity by much even though it provides them with a more enjoyable experience while doing TDD.

When I use this tool, it really makes me feel more nimble. I think price will be a key point given that many companies still think tools like Resharper are expensive toys instead of seeing them as really cheap investments to increase developer productivity.

At less than 50$, I would not even wait for my company to buy it. I’d buy it from my own pocket simply for my personal enjoyment and satisfaction. I’m eagerly awaiting the official launch of NCrunch. In the meantime, I’ll probably take a look at .Net Demon but I can tell you NCrunch has definitely become part of my TDD tool belt.

Bob Martin nous parle de son livre Clean Coder

Dans cette seconde vidéo Robert C. Martin discute avec Louis-Philippe Carignan de son plus récent livre, The Clean Coder: A Code of Conduct for Professional Programmers. Il explique comment ce livre est en réalité un ouvrage très personnel puisqu'il est basé sur son propre parcours professionel. Il y partage avec ses lecteurs ses réussites comme ses échecs. Ce livre est aussi son premier ouvrage qui ne soit pas purement orienté sur des aspects techniques.

Nous espérons que cette entrevue vous donnera le goût de lire ou relire cet excellent bouquin et que vous bénéficierez de l'expérience de Bob Martin.

Comme promis, d'autres vidéos de l'Oncle Bob suivront dans les prochains jours.

Atelier lors du démarrage d'un projet Agile

Lors du démarrage d'un projet Agile, il est important d'identifier ce que chaque membre de l'équipe peut apporter au cours du projet. Bien qu'on pourrait facilement écrire un document où l'on rassemble les compétences de chacun, je crois qu'il est bon d'utiliser des techniques pour mettre en valeur la collaboration dès le départ d'un projet Agile. Un atelier collaboratif permet aussi à l'équipe de réalisation de briser la glace avec leur propriétaire de produit et ainsi bâtir une belle relation entre eux pour la durée du projet.

Dans leur livre "Choisir l'Agilité : Du développement à la gouvernance", Mathieu Boisvert et Sylvie Trudel suggèrent un atelier à la page 28 qui permet d'identifier les gens qui seront les "cochons" de l'équipe.

L'atelier consiste à tracer deux demi-cercle l'un en face de l'autre avec le Scrum Master entre les deux demi-cercles. Un demi-cercle va contenir l'équipe de réalisation tandis que l'autre représente les parties prenantes. L'image montre comment le Scrum Master protège son équipe en étant entre les deux demi-cercles. Le facilitateur demande alors aux personnes présentent dans la salle de mettre leur nom dans un seul demi-cercle. Si vous avez des gens dans la salle qui désirent s'impliquer à moitié dans le projet, vous les forcerez ainsi à choisir un camp.  

J'aime bien cet exercice puisqu'il permet d'identifier dès le départ les gens qui seront impliqués dans le projet. Si jamais vous avez quelqu'un qui veut "traîner" dans l'équipe Agile sans s'impliquer, vous le cernez dès le départ.

Matrice des compétences

J'utilise cet atelier lorsque j'ai une nouvelle équipe où je veux que les gens sachent ce qu'ils peuvent offrir au projet. Cette matrice permet d'identifier ce que les membres de l'équipe sont en mesure de faire, peuvent faire et aimeraient faire. Une fois cette matrice créé, je l'utilise lors des planifications d'itération pour aider les gens à travailler en équipe pour réaliser les stories de l'itération.

Dans l'image suivante, on peut voir une matrice des compétences dessinée par les membres de l'équipe. Chaque personne écrit son nom sur une ligne. Elle crée ensuite des colonnes où elle y inscrit les compétences qu'elle peut, veut et aimerait faire dans ce projet. Pour différencier ces trois catégories, on utilise un symbole différent:

• Peut faire: Un X
• Veut faire: Un cercle 
• Amerait faire: Un cercle avec une étoile à l'intérieur

Une fois terminée, je prends une photo de la matrice. Je m'assure qu'elle soit visible dans la salle des rencontres de l'équipe Scrum (mêlées quotidiennes, planification, revue) pour que l'équipe la garde en tête. Des fois, j'ajoute une dernière colonne à cette matrice où l'on y présente une passion que chaque personne a. Cela permet de tracer un lien plus personnel avec les gens et ainsi savoir ce qui les occupent à l'extérieur du travail.  

Conclusion

Comme vous pouve le constater, ces deux ateliers permettent de mieux cerner les gens qui seront impliqués dans le projet Agile. Dans le cadre de la matrice des compétences, on peut aussi voir ce que les membres de l'équipe peuvent, veulent et aimeraient faire. Bien qu'il est possible de simplement rédiger un document qui identifie ces compétences, je crois qu'un atelier collaboratif viendra renforcir le lien de travail entre les membres de l'équipe.

Bon démarrage de projet Agile!

Pourrez-vous soutenir le rythme?

Lors d’un précédent billet intitulé « OÙ EN ÊTES-VOUS DANS VOTRE PROGRESSION AGILE », nous avons énuméré quelques techniques permettant d’évaluer la progression d’une adoption Agile dans une organisation.

Bien que ces mesures permettent l’évaluation de l’état actuel de la situation, bien peu d’entre elles permettent d’estimer si le produit développé permettra à une organisation de soutenir le rythme et contribuer à la prédictibilité espérée en développement itératif.

Soutenir le rythme

Au cours de sa durée de vie, est-ce que votre logiciel pourra évoluer tout en maintenant un niveau de coût linéaire plutôt qu’exponentiel?  La figure suivante illustre la différence entre les coûts de développement au cours du temps d’un produit répondant aux (nombreux) critères de qualité et un autre qui minimise ou voir même néglige l’importance des principes de qualité logicielle.

Figure A - Coûts du développement d’un produit dans le temps

Un logiciel de qualité pourrait avoir un coût initial plus élevé qu’un autre de moindre qualité.  Il est cependant indéniable que les raccourcis pris (consciemment ou non) lors de la conception de ce dernier rattraperont et dépasseront rapidement les coûts de celui développé selon les caractéristiques d’un logiciel de qualité.

Un « nouveau » produit deviendra assez tôt un « ancien » sans ces caractéristiques de qualité.  Il sera bientôt difficile de défendre le produit contre les attaques des coûts de maintenance astronomique et l’incessante croissance de la complexité.  Ironiquement, ce sera probablement l’équipe de développement qui militera face aux gestionnaires afin de remplacer l’ancien produit par un (autre) nouveau.  Et malgré les bonnes intentions, il est fort possible que les caractéristiques de qualité soient encore absentes et que le gaspillage se répète tout en dilapidant les précieux revenus de l’organisation.

Un logiciel de qualité, c’est quoi exactement?

Pour bien répondre, nous devrions faire plusieurs billets sur le sujet, mais de façon (très) concise, voici quelques-unes des caractéristiques d’un logiciel de qualité

• Principes SOLID
• Lisibilité, facilité de compréhension
• Faible Couplage
• Facile à tester (automatisé)
• Architecture émergente extensible
• Principes Clean Code (“cheat sheet”)

Feuilles de thé ou lignes de la main?

Vous pouvez toujours essayer les méthodes « alternatives » afin de faire des prévisions sur la capacité du logiciel à soutenir le rythme, mais ce ne serait pas notre premier conseil.  Quelles mesures pourraient bien nous aider?

La vélocité?  Pas vraiment.  Bien que la vélocité permette d’estimer la capacité de l’équipe, elle dépend de beaucoup de facteurs subjectifs et variables.  Dont celui de notre définition de « Terminé ».  Ce qui signifie que nous pourrions avoir une vélocité moindre en ajoutant des critères de qualité à notre définition de « Terminé ».

Le nombre de défectuosités?  Après tout, avoir la plus petite quantité de défectuosités possible, n’est-ce pas ce qu’on entend par « un logiciel de qualité »?  Non, non et non!  On peut atteindre un nombre limité de défectuosités en investissant une quantité de temps indécente dans le « contrôle de qualité » d’un produit plus que déficient.

Le taux de couverture de nos tests automatisés, ça c’est bon…N’est-ce pas?  Désolé, un logiciel de piètre qualité peut avoir 100% de couverture en tests automatisés tout en demeurant illisible et sans respecter les principes SOLID ou Clean code etc.

La beauté, c’est à l’intérieur

Hé oui, vous devrez « regardez sous le capot » pour savoir si vous avez un logiciel de qualité entre les mains.  Vous me direz peut-être que vous faites de la revue de code régulièrement.  Que signifie régulièrement pour vous?  Plusieurs fois par année, par mois?  Peut-être avez-vous la discipline de le faire plusieurs fois par semaine.  Même cette fréquence ne peut probablement pas permettre d’obtenir une idée objective de la qualité du logiciel au cours des itérations.

Afin de soutenir le rythme d’un développement itératif et de vous assurer que vous n’êtes pas en train d’alimenter le spectre d’une dette technique grandissante, plusieurs outils et techniques sont à votre disposition.  En voici quelques-uns

• Outils automatisés pour les mesures statiques
  • Sonar (Java, C#, C, PHP)
  • TFS avec CodeMetric
  • NDepend (mesures statiques et analyse des dépendances)
  • Revue de code entre les pairs intégré dans votre définition de « Terminé »
  • Programmation en pair

Conclusion

N’oublions jamais le paradigme sous lequel nous devons concevoir les projets sous les principes Agile.  La qualité ne doit plus être une variable, mais bien une constante (Figure B).  La meilleure façon d’obtenir cette régularité est d’inspecter et adapter assidûment ce que l’on crée afin que l’organisation génère un actif plutôt qu’un passif.

C’est ainsi que l’organisation sera en meilleure posture afin de répondre aux besoins de ses clients…aujourd’hui et demain.



Figure B – Paradigme des contraintes de projets Agile

©Cette image est une gracieuseté de M. Patrik Malmquist (http://www.applitude.se)

Atelier pour Scrum Master à Agile Québec

Merci beaucoup à tous ceux et celles qui ont participé à mon atelier Scrum Master du 25 janvier à la Communauté Agile de Québec. J'espère que vous avez l'impression d'avoir profité d'une activité riche en apprentissage et que vous retournerez au travail avec un outil supplémentaire pour vous épauler dans votre rôle de Scrum Master.

Pour ceux qui aimeraient visionner ma présentation, vous pouvez la télécharger sur notre canal Slideshare ou tout simplement la visionner ci-dessous.