Ernst's Thoughts

Développement ASP.NET piloté par les tests (partie 2)

2015-04-26T16:59:00.000+02:00

Ce billet fait partie d'une série sur le développement ASP.NET piloté par les tests.

Le premier test

Dans le dernier billet, j'ai présenté les raisons qui me poussent à partir de la page blanche lorsqu'il s'agit de créer une application web que je maîtrise dans tous ses aspects. Assez confiant de cette stratégie, je me lance dans le développement de l'application. J'ai une idée très imprécise du périmètre de cette application. Tout ce que je sais pour l'instant c'est que ce sera une application web qui affichera les scores de matchs de tennis.

Accès à l'application web

Message de bienvenue
Liste des matchs en cours
Créer un nouveau match
Charte graphique

C'est déjà pas mal comme exigences. Et même si on est loin d'avoir un ensemble complet de fonctionnalités, j'ai beaucoup à mettre en place en terme d'environnement et d'infrastructure de développement. La question est donc par où commencer ? Etant donné que je me laisse guider par les tests, la réponse est à la fois facile et non évidente. Facile, parce qu'il me faut bien sûr commencer par un test. Non évidente parce qu'il me faut trouver le premier test.

La plupart des tutoriels du développement piloté par les tests débutent par un test unitaire, c’est-à-dire un test qui vérifie le comportement ou le résultat d'une méthode d'une classe. Bien que je comprenne la pédagogie de cette approche, dans la pratique c'est loin d'être la façon la plus efficace de débuter un projet. En effet, il y a risque de s’égarer dans des détails et considérations techniques sans vraiment progresser dans mon but qui est de livrer une version fonctionnelle de cette application. J’utilise les tests pour me donner des objectifs précis et atteignables tout en m’assurant qu’à la fin j’aurai quelque chose de tangible pour un utilisateur. Mon premier test ne sera donc pas un test unitaire mais plutôt un test fonctionnel qui va vérifier qu'une fonctionnalité utile du point de vue d'un utilisateur est bien présente dans l'application.

Je décide donc de me concentrer sur le message de bienvenue de la page d'accueil.

Accès à l'application

Message de bienvenue

Liste des matchs en cours
Créer un nouveau match
Charte graphique

Il me faut donc créer un test qui accède à la page d'accueil de l'application et vérifie la présence du message de bienvenue. Puisque je n'ai pas encore codé l'application ce test va évidemment échouer. Par contre ce premier test est capital car une fois rédigé, il me permet de savoir sans équivoque que j'ai terminé le premier des 4 points qui satisferont les utilisateurs.

Je vais donc créer une solution qui ne contiendra pour l'instant que mon projet de tests.

Une des premières décisions à prendre est quel framework de test utiliser. J'ai toujours préféré l'API d'assertion de NUnit à celui de MSTest. Ma prochaine tâche consiste à installer NUnit et vérifier que tout fonctionne bien dans mon environnement.

En passant, je suis dans le TGV vers Karlsruhe… Il n'y a pas d'accès wifi à Internet comme l'indique le message d'alerte de Nuget. Une chance que j'ai déjà installé Nunit sur ma machine. J'espère que je pourrai me rendre au bout de l'exercice…

Je crée mon premier test. Rien d'époustouflant pour l'instant. Je veux juste m'assurer que j'aurai un feedback lorsque quelque chose ne va pas. Pour cela, la tactique consiste à créer un test qui échoue forcément et voir comment Visual Studio s'organise pour m'avertir de cet échec. La classe BasicTest avec son assertion d'échec Assert.Fail(); devrait suffire.

En passant comme je suis installé côté fenêtre et que je voyage de jour, la réverbération me pousse à adopter le thème de couleur 'Light' car je n'arrive plus à voir ce que j'écris...

Je lance les tests avec la combinaison Ctrl+R, A et alors que je m'attendais à avoir une indication claire d'échec, rien ne semble s'être produit. Incrédule, je m'y prends à plusieurs reprises pour me rendre à l'évidence, Einstein avait bien raison… Il me faut prendre du recul. Mes tests ne sont pas reconnus par l'explorateur de test de Visual Studio. En fouillant dans ma mémoire, je retrouve non sans mal l'information que j'oubliais: il me faut installer NunitTestAdapter.

J'ai changé quelque chose! Voyons voir si j'obtiens d'autres résultats! Ctrl+R, A…

On avance, car la console m'indique bien que Visual Studio a trouvé et exécuté 1 test. Pourtant, je n'ai aucune indication d'échec. Est-ce mon test qui est mal écrit ? J'affiche l'explorateur de test et... voilà!

Je vois que le test a bien échoué. Toutefois, j'ai du explicitement afficher l'explorateur de tests. Ce n'est pas malin ça. Le feedback est très important pour le cycle TDD et ce comportement de Visual Studio risque de me causer pas mal de confusions. Aussi j'abandonne l'explorateur de tests et adopte de préférence l'exécuteur de tests de Resharper. Avec la tout aussi pratique combinaison Ctrl+U, L j'obtiens un feedback immédiat sans être obligé de chercher la bonne fenêtre.

Pour faire passer ce test au vert, rien de plus simple. Cette fois-ci, exceptionnellement, je corrige le test en remplaçant l'assertion d'échec par une assertion triviale du genre Assert.IsTrue(true); et le tour est joué!

Ce premier test peut sembler futile car, en soi, il ne teste absolument rien. Et pourtant, l'étape franchie est capitale. Le TDD s'appuie sur des boucles de rétroactions très courtes: RED-GREEN-REFACTOR, RED-GREEN-REFACTOR,… Cette étape m'a permis de m'assurer que les outils mis en place supportent ce cycle, me donnent le bon feedback de façon non équivoque et que je peux m'y fier. Je n'ose pas m'imaginer le temps fou que j'aurais pu perdre si mon but avait été d'isoler une anomalie d'un code existant et que j'interprétais naïvement le mutisme apparent de l'explorateur de tests de Visual Studio comme un signe que les tests que je concevais étaient positifs !

Une anecdote: j'ai, à quelques reprises, entendu mes collègues se plaindre de la qualité de leurs projets et lorsqu'on investigue la base de code on n'y retrouve que des tests du style BasicTests. Ouch!

Par ailleurs, en me relisant je me rends compte que, malgré mes bonnes intentions exprimées en début de ce billet, j'ai également commencé par un test unitaire. Marrant, non ? A ma décharge tout de même, ce n'est pas dans un but pédagogique et je n'ai pas non plus tester aucun code de production.

Ne manquez pas dans le prochain billet : Le second "premier test".

Développement asp.net piloté par les tests (partie 1)

2015-04-12T10:05:00.000+02:00

Ce billet fait partie de la série développement ASP.NET piloté par les tests.

Partir de la page blanche
Le premier test
Le second "premier test" (à venir)

Partir de la page blanche…

Le développement piloté par les test (TDD) préconise des cycles de développement très courts débutant par l'écriture d'un test automatisé avant le code de production. Toutefois les environnements de développement modernes avec toute l'intelligence de leurs menus, leurs options et leurs fonctionnalités de génération de code (scaffolding) ne sont pas toujours adaptés à ce mode de développement. Je ne peux pas nier l'avantage d'avoir un solide point de départ, surtout pour expérimenter rapidement avec une idée ou se familiariser avec des librairies ou cadres applicatifs. Cependant, mon but est différent. Je veux développer de manière maîtrisée une application métier de qualité. J'ai également pour second objectif de me familiariser avec les changements apportés avec la version 5.2 de Asp.NET MVC. Le développement piloté par les tests me semble approprié pour cela. Je me propose donc de développer une application web MVC avec Visual Studio 2013 en me laissant entièrement guider par les tests afin voir si l'environnement de développement proposé par Microsoft s'y prête bien ou pas.

Avant de commencer le développement en tant que tel, je me suis posé la question si cela vaut la peine de tester une application aussi simple que celle que j'ai en tête. J'ai toujours été un grand fan de la plateforme .NET qui offre une panoplie de technologies, d'outils et de librairies à la fois diversifiés et bien intégrés. Cela contribue grandement à la productivité du développeur qui a moins à se soucier de mettre en place un environnement fonctionnel et peut se concentrer sur l'application à développer. Visual Studio est un de ces outils de développement qui offrent une multitude de fonctionnalités pour "aider" le développeur. Je peux, en 7clics ou moins, générer la base d'une application web avec authentification et gestion d'utilisateurs, prise en charge des librairies Javascript (JQuery, Boostrap, Modernizr, RespondJS) et du CSS, gestion transverse des erreurs inattendues avec un Filtre, et j'en passe… Et bien sûr, tout cela fonctionne! Un clic sur le bouton de lancement, et je peux naviguer sur mon application web flambant neuve.

Toutefois, un doute m'envahit lorsque je survole le code généré : 33 types pour un total de 384 lignes répartis dans 13 fichiers C#. Ces chiffres ne prennent pas en compte les vues Razor (25 fichier .cshtml) et le Javascript des librairies utilisées (15 fichiers). Ai-je besoin de tout cela ? Qu'est-ce qui est vraiment nécessaire pour faire rouler l'application ? Difficile à dire du premier coup d'œil.

Les métriques en soit ne sont pas catastrophiques. Toutefois le faible taux de couverture de 2% obtenu par les tests générés automatiquement avec la solution ne fait rien pour me rassurer de la qualité du code. De plus, ceci implique qu'en lisant les tests je ne peux espérer comprendre que 2% du code du généré. Il me faut soit faire confiance à Microsoft ou parcourir les tutoriels et blogs sur le web pour m'assurer de comprendre dans ces moindres détails ce qui a été généré. Je ne me sens pas en maîtrise…

Je décide donc de partir d'une solution vide à laquelle je rajouterai au fil de l'eau les éléments nécessaires à l'application tout en les validant avec des tests. Avant de me lancer dans le développement de ma nouvelle application, je vérifie que j'obtiendrai de meilleurs résultats avec cette approche en effectuant une expérimentation pour (ré-)apprendre (Spike) les bases du cadre applicatif. Je crée une nouvelle solution web vide.

J'aurais pu opter pour introduire peu à peu des tests dans la solution. Cette option aurait l'avantage de correspondre au contexte de la plupart des projets qui concernent des applications existantes. Ceci me permettrait également de mettre en pratique les techniques pour tester du code existant que l'on retrouve dans Working with Legacy code, ou Brownfield Application Development in .NET. Je réserve tout ceci pour une autre série.

La solution générée est plus modeste. Seulement 2 classes totalisant 6 lignes de codes. Pas de vue Razor, ni de javascript.

Cette fois-ci le taux de couverture des tests est de 0%. Par contre, il n'y a que 8 instructions de code à tester. C'est beaucoup plus encourageant…

De plus, l'application ne fonctionne pas. Lorsque je la lance, j'obtiens une page d'erreur m'indiquant que la page d'accueil n'existe pas. Ça me semble être un bon point de départ pour mon premier test…

La suite dans le prochain billet…

Démarrer une communauté de pratique agile tout en jouant

2014-01-13T15:28:00.002+01:00

J'ai récemment eu la chance de participer au démarrage d'une communauté de pratique agile pour l'un de mes clients. J'ai tout particulièrement apprécié l'occasion qui m'a été offerte d'animer deux moments cruciaux de cette rencontre. Je me propose de partager dans ce billet un retour sur les jeux que nous avons utilisés pour faciliter les échanges et l'engagement : "Pocket-Sized Agile Principles" et "Circle of Influences".

Vue l'émergence de plusieurs initiatives agiles au sein de son entreprise, mon client veut mettre en place une communauté qui permettra aux membres de partager les pratiques qui fonctionnent bien et ainsi augmenter globalement les compétences agiles au sein de l'entreprise. L'objectif du lancement de la communauté est d'informer de la mise en place de ce moyen de communication et d'impliquer ceux qui sont intéressés à son rayonnement.

Les enjeux

Persuader les dirigeants du bien fondé et du retour sur investissement d'entretenir une communauté de pratiques ;
Impliquer de façon minimale et efficace les collaborateurs dans l'organisation et la vie de la communauté ;

Les défis

Différents degrés de familiarité avec l'agilité des participants ;
Réticences envers l'agilité de certains participants clés ;
Démarrer les conversations dans une ambiance sereine ;

La question du format de la réunion de lancement s'est vite posée. Un format forum ouvert ("open space") ne nous a pas semblé approprié vu les objectifs spécifiques de lancement de communauté. Nous avons donc opté pour des sessions de travail en sous-groupes avec mise en commun par la suite. Ce format, bien que plus directif, a permis à tous les participants de s'exprimer et de partager sur les sujets importants auxquels la communauté devraient s'atteler.

Pocket-Sized Agile Principles
Don McGreal présente cet atelier, comme un jeu permettant de communiquer les principes du manifeste agile. Les participants ont travaillé en sous-groupes de 5 à 8 personnes afin de résumer sur un post-it avec un maximum de trois mots chacun des 12 principes. Pour faciliter la mise en commun, on retrouve sur chaque post-it un numéro référençant un principe et les trois mots qui le résument. Voulant favoriser les échanges, nous avons opté pour une boîte de temps d'une heure pour cette étape.

Cet atelier, malgré sa simplicité, fut très efficace pour focaliser les conversations et introduire les concepts de l'agilité aux personnes qui y étaient moins familières. Le maximum de trois mots incite les sous-groupes à creuser les principes afin d'en tirer l'essence et de l'exprimer dans des termes significatifs pour tous. En prime, certains principes ont donné lieu à des témoignages d'expériences personnelles ce qui a augmenté la compréhension des enjeux de l'agilité au sein de la compagnie.

En bonus, nous avons demandé aux participants de voter avec la technique du "dot voting" les principes les plus importants. Nous avons ainsi obtenus d'eux une vision partagée des éléments importants de l'agilité qui pourra servir de base au processus d'amélioration continue de la compagnie. Dans notre cas, les principes qui sont ressortis sont : 10 - Simplicité, 9 - Excellence technique, 1 - Priorisation de la valeur, 5 - Confiance en des personnes motivées, 3 - Livraisons fréquentes.

Circles of Influence
Plus tard durant le lancement, après avoir dressé et ordonné une liste de sujets que la communauté devrait aborder, il nous fallait déterminer les contributions que chaque membre pouvait faire en vue d'organiser les futures activités. Cette étape de la rencontre a tout naturellement créé une atmosphère d'incertitude dans le groupe constitué d'individus n'ayant pas souvent collaborer ensembles. Il nous fallait rapidement trouver un objectif rassembleur et laisser émerger l'auto-organisation du groupe. Nous avons, sur le tas, opté pour le jeu "Circles of Influence" de la série "Innovation Games". Cette activité permet à un groupe de déterminer de manière collaborative les actions à accomplir et les moyens dont il dispose en vue d'atteindre l'objectif qu'il s'est fixé.

Après avoir réfléchi quelques instants, le groupe a défini son objectif: "Faire vivre la communauté". Cette étape a été cruciale puisqu'elle a permis aux participants de trouver un sens aux contributions et engagements qu'ils s'apprêtaient à faire. Tel que présentées sur l'image, les actions sont indiquées sur des post-it collés à l'intérieur du cercle "Tâches" (à gauche). Dans notre cas, ces actions étaient des contributions soit techniques comme par exemsur un post-itple la mise en place d'une plateforme collaborative pour la communauté, ou des contributions de contenu sous forme de présentations ou animation d'ateliers. Chaque contributeur a aussi pris le temps d'indiquer son nom et le temps qu'il peut consacrer à sa contribution. Par ailleurs, les moyens ont été identifiés sur des post-it accolés au cercle "Comité/Support" (à droite). On peut voir sur l'image que les participants se sont peu concentrés sur le support dont ils avaient besoin et qu'ils sont plutôt dans l'action.

En conclusion
Voilà deux jeux simples et efficaces qui nous ont permis d'établir un climat de collaboration peu probable au sein d'un groupe d'individus ayant un bagage et une expérience agile très diverses. Ce climat serein a permis aux participants de définir un objectif commun et d'offrir leurs contributions à la communauté. Ce fut la première fois que j'utilisais ces jeux dans un contexte hors formation ou coaching d'équipe et, vu les résultats obtenus, ce ne sera sûrement pas la dernière. Et vous, comment organisez-vous le lancement d'une communauté ?

3 days with Greg Young

2010-06-03T22:36:00.001+02:00

Last week Pyxis hosted an intensive three days immersion into Greg Young's Applied DDD course. This course is amazingly packed with tips and tricks on how to come up with an architecture that delivers business value customers have come to expect from their investments in software systems. Powered by Greg’s energetic tone, this course challenged my assumptions of how software should be designed and I would recommend it to anyone interested in architecture innovations surrounding Domain Driven Design. Following is an overview of the topics we’ve tackled during the training.

DDD recap

The first day was spent refreshing some of the fundamental but often misunderstood concepts of Domain Driven Design. We were reminded that Strategic Design is essential while embarking on a Domain Driven Design project as we must make sure that the value we get out from it is well worth the effort. Notions such as Bounded Contexts and Core Domain allow highly knowledgeable teams to focus on value added development work while leaving less crucial aspects of the software to others.
Another topic that stroke a chord with me was Greg’s presentation of Aggregates and the role the play in well crafted software systems. Aggregates exist to provide transaction boundaries around the behaviors of domain objects. Aggregate roots provide the sole entry point to this grouping of domain behaviors and encapsulate validation logic as well as invariant consistency inside the aggregate.

CQRS

We spent the second day learning about Command Query Responsibility Segregation and Event Sourcing. CQRS is different then Command Query Separation (Bertrand Meyer) which advocates that methods that change state should be separated from functions that return value. CQRS takes the same principle and applies it to the hole architecture. In this style of design some objects (write model) represents the commands the domain respond to and other objects (read model) handles the queries and their results. Having separate models for these concerns brings a lot of benefits that I will bring up in later posts.

The write model

It’s common OO knowledge that objects should be designed around behaviors in a domain. Having a dedicated write model consisting of aggregates that define transaction boundaries around the behaviors in the domain focuses work on the most valuable part of the system. This is the place to maximize the return on the work of your most skilled developers aided by domain experts.

The read model

The query side doesn’t have a domain as it’s mostly straightforward boilerplate code. The preferred implementation of a read model is having request DTOs going through a thin query layer that projects directly off of a data source. This is way simpler that using the domain model to do the same. This way pre-fetched paths and optimizing ORMs queries are avoided.

Event Sourcing

Event sourcing can be seen as a way to “standardize” thus reduce the cost of implementing separated read and write models. The basic idea is that all domain can be modeled as receiving commands that and producing associated events. These events can be stored as a log of what happened in the system and also be used to update the read model.
While exposing concurrency issues and ways to handle them Greg showed us a merging algorithm that’s quite simple and clever. Probably, the only piece of code Greg would ever write with a Goto statement as you can see in the picture.

Fine tuning the architecture

The third day was spent analyzing the properties of this architecture and how it could be fine tuned to produce low latency, high availability and high reliability systems. Most notably CQRS architecture can used to get around CAP theorem issues which states that you can’t guarantee all three Consistency, Availability and Partitionability in one system. Look here for another treatment on how to get around CAP.
All these architecture talks made me realize that using DDD and CQRS is a lot of work. And it’s no wonder that they should be applied to core domains. Now most companies I’ve worked with deal with multiple domains such as Sales, Security, Insurance, etc... And it would have been difficult to single out the one that constitutes their core domain. But every company must have a core domain otherwise it would not have a competitive advantage. Turns out a lot of companies derive their competitive advantage from their business process that integrate all of the domains they deal with. This is the place their core domain reside and that’s where Sagas help.

Pyxis source of high quality technical learning

All in all, these three days were packed with useful technical knowledge and eye opening discussions with an expert in his craft. The participants enjoyed the learning experience in Pyxis’ agile environment where they got a close up look at our facilities supporting agile teams. Pyxis is proud to have sponsored this event and is dedicated to bringing high quality technical training to the public.
Other technical trainings :

My presentation at the Toronto Code Camp 2010

2010-05-04T06:15:00.001+02:00

I had a blast meeting new people and sharing experiences writing software. I especially liked Barry Gervin’s keynote on successful product management and Todd Anglin’s talk on HTML5.

As for me, I did and introductory talk on Scrum and Visual Studio 2010 briefly touching on some of the content of the Professional Scrum Developer course. The training has already started in several countries around the globe: Brazil, Australia and US. I’ll be teaching the Montreal edition that’s coming in June 7th. It’s going to be awesome!

About the Professional Scrum Developer Course

The Scrum Developer course is a unique and intensive five-day experience for software developers. The course guides teams on how to turn product requirements into potentially shippable increments of software using the Scrum framework, Visual Studio 2010, and modern software engineering practices. Attendees will work in self-organizing, self-managing teams using a common instance of Visual Studio Team Foundation Server 2010 to achieve this goal.

Course attendees are prepared to take an assessment at course completion and then become Certified Professional Scrum Developers.

Professional Scrum Developper Training

2010-03-25T16:51:00.000+01:00

Dates are now open for the Professional Scrum Developper on the .Net platform training in the Montreal and Toronto areas. This training is fully packed with knowledge and hands-on exercices that are important for today's developers, architects and testers working in agile teams.

Scrum Developer course is a unique and intensive five-day experience for software developers. The course guides teams on how to turn product requirements into potentially shippable increments of software using the Scrum framework, Visual Studio 2010, and modern software engineering practices. Attendees will work in self-organizing, self-managing teams using a common instance of Visual Studio Team Foundation Server 2010 to achieve this goal.

Course attendees are prepared to take an assessment at course completion and then become Certified Professional Scrum Developers.

You can register via scrum.org

Hope to see you there!

Agile Testing

2010-03-21T19:15:00.000+01:00

I've just watch this talk from Elizabeth Hendrickson. Very interesting content on Agile Testing.

Professional Scrum Master Level II

2010-03-21T03:43:00.000+01:00

I've just received confirmation from Ken Schwaber that I've successfully completed the Professional Scrum Master Level II assessment available on Scrum.org. I'm very proud of announcing that I'm also a .Net Professional Scrum Developper Trainer and that I will be delivering this course in Canada in May and June. Stay tuned for the official dates.

Automated Unit Tests as Documentation

2010-03-18T17:48:00.001+01:00

Introduction

In our quest to produce quality software and our relentless use of automated unit tests in our development activities, we’ve come to realize they possess other virtues as well. One of those being they stand as a documentation of the system being developed. I’ve taught this idea in several agile and TDD courses. In this blog I want to give you an example of how that may be. I’m purposely not discussing executable specifications and Behaviour Driven Development as it would make this blog too long. My goal is to show how using some convention and Visual Studio 2010 can go a long way in cranking up your unit tests another notch.

Documentation of API usage

One clever use of unit tests is for learning a new API or even a new language. Writing several assertions to validate our understanding and assumptions about an API usage is very rewarding as the feedback is rapid and progress towards a goal is constantly measured. These learning tests may be kept around to document the assumptions made that constitute the basis of our solution. Here is an example of a learning test for the Character.IsWhiteSpace() method of the BCL.
[TestMethod]
[Description(@"White spaces are the following characters: ' ', '\t', '\n', '\r'")]
public void May_be_a_white_space()
{
    Assert.IsTrue(char.IsWhiteSpace(' '));
    Assert.IsTrue(char.IsWhiteSpace('\n'));
    Assert.IsTrue(char.IsWhiteSpace('\t'));
    Assert.IsTrue(char.IsWhiteSpace('\r'));
    Assert.IsFalse(char.IsWhiteSpace('A'));
    Assert.IsFalse(char.IsWhiteSpace('+'));
}
A test can also document how to use the classes we create in our solutions. The following is an example of such a test. In our chess software, this unit test documents the way of obtaining a chess piece which is to call the NewPiece() factory method and passing it a color (either Color.White or Color.Black) and a Kind (such as Kind.Pawn) as arguments.
[TestMethod]
[Description("A chess piece consists of a kind and a color that are specified when the piece is created")]
public void Should_retain_its_color()
{
    Piece pawn =
           Piece.NewPiece(Color.Black, Kind.Pawn);
    Assert.IsTrue(pawn.IsBlack);
    Assert.IsFalse(pawn.IsWhite);
    pawn = Piece.NewPiece(Color.White, Kind.Pawn);
    Assert.IsTrue(pawn.IsWhite);
    Assert.IsFalse(pawn.IsBlack);
}

Documentation of behaviours

Unit tests document behaviours of our code. Test classes should be given names that provide context for all the test methods they contain.
[TestClass]
public class When_displaying_a_board
{
    [TestMethod]
    public void A_black_queen_should_show_as_Q()
    {
        …
    }
    …
}
Test methods should also be named in such a way that the behaviour they validate is evident.
[TestMethod]
[Description("The board is displayed on 8 lines with blacks pieces on line 8 and 7 and white pieces on lines 1 and 2")]
public void It_should_show_all_pieces_in_their_initial_position()
{
    Assert.AreEqual(
        "RNBQKBNR".Line() +
        "PPPPPPPP".Line() +
        "........".Line() +
        "........".Line() +
        "........".Line() +
        "........".Line() +
        "pppppppp".Line() +
        "rnbqkbnr".Line(),
        board.ToString()
        );
}
Notice that, instead of writing comments, I’m using the Description attribute to tie the behaviour being tested with some requirement or specification of the system. Personally, I’m not doing anything fancy with these descriptions, but you can imagine using a pattern that would provide more traceability in your environment as in the following.
[TestMethod]
[Description("US 234: Black pawns are shown as P, white pawns are shown as p")]
public void A_white_pawn_should_show_as_p()
{
    Piece whitePawn = Piece.NewPiece(
                        Color.White,
                        Kind.Pawn);
    Assert.AreEqual("p", whitePawn.ToString());
}

Documentation of design specifications

Now comes the fun part! Because of the thought we’ve put in selecting meaningful names when the tests are executed in Visual Studio we get a result screen that looks like this.

Notice how combining our test class and method names reads like a phrase that documents the design of our software. If we group the results by Description, we get a list of all the requirements of our software.

If we expand one of the requirements, we see all the tests that validate it so we can trace back to the code that implements it.

Conclusion

I hope I’ve convinced you that tests can serve as documentation using simple tricks, conventions and tooling you may already have at your disposal. Because this documentation is embedded in code it has a lot more chance of being maintained as the code evolves. These techniques require agreement amongst team members but they foster good practices of choosing explicit names and tying development work with planning activities for traceability purposes.

Coding and Debugging in Bubbles

2010-03-12T01:44:00.001+01:00

A new concept for the modern IDE, Code Bubbles allows developers to see and work different fragments of code as one unit. Debugging sessions can be associated with those units save and retrieved later for continued work. Quite impressive! It’s really a departure from the IDEs we’ve been using so far. Of course, this is not mainstream yet. Nevertheless, I would like to try something like that and it would probably be interesting to have the equivalent in the .Net space.
I have to wonder though, what the impact will be on Object Oriented Programming and encapsulation if developers are lead to think of their code as fragments of functionality scattered in their code base…

FizzBuzz à la façon LINQ

2010-02-13T23:54:00.000+01:00

Dernièrement mes collègues et moi exécutions le Kata FizzBuzz dans le cadre de notre Dojo pratiques d’ingénierie. L’objectif était de pratiquer le développement piloté par les tests. Je dois avouer que ce fut fort amusant et la solution à laquelle nous sommes arrivés est tout à fait adéquate et présente un modèle objet élégant qui résoud le problème.
La séquence FizzBuzz est générée par la méthode CountTo de la classe FizzBuzz. Cette dernière utilise un ensemble de règles qui vérifient si elles s’appliquent et transforment, le cas échéant, l’entier question soit en “Fizz”, “Buzz” ou “FizzBuzzz”.
class FizzBuzz
{
    private readonly IRule[] _rules = new IRule[] {
        new FizzBuzzRule(),
        new BuzzRule(),
        new FizzRule()
    };
    private readonly IRule _defaultRule = new NumberRule();
    public string[] CountTo(int upperBound)
    {
        var sequence = new List<string>();
        foreach (var n in NumbersUpTo(upperBound))
        {
            sequence.Add(Interpret(n));
        }
        return RespondWith(sequence);
    }
    private static IEnumerable<int> NumbersUpTo(int n)
    {
        for ( int i = 1; i <= n; i++)
        {
            yield return i;
        }
    }
    private string Interpret(int n)
    {
        foreach (var rule in _rules)
        {
            if (rule.Applies(n)) return rule.Apply(n);
        }
        return _defaultRule.Apply(n);
    }
    private string[] RespondWith(List<string> result)
    {
        return result.ToArray();
    }
}
La classe FizzRule est un exemple d’implémentation d’une rèlge.
class FizzRule : IRule
{
    public bool Applies(int number)
    {
        return ShouldSayFizz(number);
    }
    private static bool ShouldSayFizz(int n)
    {
        return IsDivisibleByThree(n) || ContainsThree(n);
    }
    private static bool IsDivisibleByThree(int number)
    {
       return number % 3 == 0;
    }
    private static bool ContainsThree(int n)
    {
        return n.ToString().Contains("3");
    }
    public string Apply(int number)
    {
        return SayFizz();
    }
    private static string SayFizz()
    {
        return Fizz;
    }
    private const string Fizz = "fizz";
}
Plus tard, je me suis demandé de quoi aurait l’air la solution si j’utilisais les fonctionnalités du langage C# 3.0 telles que LINQ, les expressions lambda et les méthodes d’extension. Avec notre batterie de tests comme garde-fou je me suis lancé dans une session de refactorisation au bout de laquelle je suis arrivé à la solution que je présente plus loin.
Les premières pistes que je choisis d’explorer sont les méthodes que Resharper suggère de changer en méthodes statiques. En fait, les méthodes statiques me font toujours penser à des méthodes utilitaires qui en général sont très réutilisables. C’est le cas par exemple des méthodes IsDivisibleByThree et ContainsThree de la classe FizzRule plus haut. Je les rassemble donc dans la classe IntExtensions après avoir introduit un peu de généricité pour qu’elles soient utilisables également dans la classe BuzzRule.
public static class IntExtensions
{
    public static bool Contains(this int n, int number)
    {
        return n.ToString().Contains(number.ToString());
    }
    public static bool IsDivisibleBy(this int number, int dividend)
    {
        return number % dividend == 0;
    }
}
Avec ces modifications, la méthode ShouldSayFizz se lit comme suit:
private static bool ShouldSayFizz(int n)
{
    return n.IsDivisibleBy(3) || n.Contains(3);
}
Je suis content car la lisibilité du code n’en souffre pas. Je m’attaque de la même façon à la méthode NumbersUpTo de la classe FizzBuzz. J’en fais une méthode d’extension que je rajoute à la classe IntExtensions. Je prends le soin de renommer la méthode FirstNumbers pour une meilleure lecture du code client qui se lira
foreach(int number in n.FirstNumbers()) { … }
Cela me rappelle mon cours d’analyse et la série des n premiers nombres entiers… En fouillant un peu dans MSDN, je retrouve comment générer une suite d’entiers grâce à la classe Ennumerable et je modifie mon implémentation en conséquence. J’obtiens le résultat suivant
public static class IntExtensions
{
    public static IEnumerable<int> FirstNumbers(this int n)
    {
        return Enumerable.Range(1, n);
    }
    public static bool Contains(this int n, int number)
    {
        return n.ToString().Contains(number.ToString());
    }
    public static bool IsDivisibleBy(this int number, int dividend)
    {
        return number % dividend == 0;
    }
}
Avec ces méthodes utilitaires hors de la classe FizzRule, la responsabilité de celle-ci devient plus évidente et je la simplifie pour arriver au résultat suivant
class FizzRule : IRule
{
    public const string Fizz = "fizz";
    private const int Three = 3;
    public bool AppliesTo(int number)
    {
        return number.IsDivisibleBy(Three) || number.Contains(Three);
    }
    public string Apply(int number)
    {
        return Fizz;
    }
}
Une bonne chose de faite! Je tourne mon attention vers la classe FizzBuzz. Même si j’ai sorti la génération des nombres entiers hors de cette classe, elle a encore trop de responsabilités: maintenir la liste des règles FizzBuzz, appliquer les règles qui conviennent, formater le résultat. C’est une violation évidente du principe de responsabilité unique (Single Responsibility Principle) de l’oncle Bob. Je décide donc séparer tout ce qui touche à la transformation FizzBuzz dans une classe à part. Les règles et tranformations FizBuzz sont maintenant rendues dans la classe FizzzBuzzExtensions. J’ai changé l’implémentation pour utiliser LINQ étant donnée que le résultat est plus compacte et tout de même très lisible.
static class FizzBuzzExtensions
{
    internal static IEnumerable<string> AsFizzBuzzSequence
                                         (this IEnumerable<int> sequence)
    {
        return sequence.Select(numeral => Transform(numeral));
    }
    private static string Transform(int n)
    {
        return FirstRuleThatApliesTo(n).Apply(n);
    }
    private static IRule FirstRuleThatApliesTo(int n)
    {
        return Rules.First(r => r.AppliesTo(n));
    }
    private static readonly IRule[] Rules = new IRule[] {
        new FizzBuzzRule(),
        new BuzzRule(),
        new FizzRule(),
        new NumberRule()
    };
}
L’astuce d’encapsuler cette fonctionnalité en arrière d’une méthode d’extension facilite grandement la lecture de la classe FizzBuzz qui devient
class FizzBuzz
{
    public string[] CountTo(int n)
    {
        return RespondWith(n.FirstNumbers().AsFizzBuzzSequence());
    }
    internal static string[] RespondWith(IEnumerable<string> result)
    {
        return result.ToArray();
    }
}
Séparer ainsi les responsabilités dans différentes classes a grandement augmenté la clareté du design. De plus l’utilisation de LINQ et des méthodes d’extension fait en sorte que le code est très compacte quoique très expressif.

A Coaching Session

2010-01-29T18:27:00.001+01:00

Following is a conversation I had with a new Scum Master that had me thinking about how coaching works. It's not about telling people what to do but allowing them to figure out what needs to bo done. One powerful tool to do just that is changing perspectives. Reliving the facts as they happened but from a different angle may generate insights that open new opportunities for the coachee. Below is the conversation as I remember it. I hope it generates some insights for you as well.

SM: So what do you think about the sprint planning the other day ?
Coach: Well one thing I noticed, and I did mention it on the spot, the team was about to bend some process improvement rules they agreed on implementing during the last retrospective. Your role as a Scrum Master is to make sure that the team follows its own process so that they may inspect and adapt it if need be. If the team partially implements the process in some cases and fully in some others, than interpretation of the results is more difficult and it will be harder to see what to improve next. You want to be careful when introducing changes to a process so that you know what you will be inspecting in the end.
SM: Well you are right. Sticking to our decision not to include big or unclear stories in the sprint made us realise that we were accepting to tackle underspecified functionality. No wonder our estimates were off and we were not able to complete all the stories in the sprint.
Coach: Good. But what about you ? What do you think about the sprint planning meeting ?
SM: Well, one thing that bugs me is that team members don’t participate in the process.
Coach: Oh? What do you mean ?
SM: I mean they don’t seem to care or are not motivated. For instance, in our Scrum Masters group we thought it would be a good idea to let developers take turn at the Scrum Master’s role in the daily meeting so that they realize what we are dealing with. When I asked my team if one of them would like to take my place I had to wait for a long time before someone reluctantly offered to conduct the daily.
Coach: So you want them to feel what it’s like to wear your shoes ?
SM: It’s not that. It’s just that team members are not getting involved. You witnessed what happened at the sprint planning meeting. When I asked them if they were able to commit on delivering the sprint backlog, I didn’t get an answer.
Coach: Well your organisation has a culture in which developers have been told what to do, when and how to do things. The change to self organisation is not going to happen overnight.
SM: I know. That’s why I want them to get involved in the process but they don’t want to get onboard.
Coach: And why do you think the don’t want to get onboard ?
SM: I don’t know. And that’s why I’m asking you this because I’m running out of ideas.
Coach: So… What are you doing that’s impeding them from getting involved in the process ?
SM: I’m not sure I understand the question… What do you mean ?
Coach: When you are not getting the response you’re expecting from others it’s often useful to consider that you are the one causing them to act the way they do. This empowers to make some changes instead of waiting for others to change their behaviour.
SM: I’m not following you at all…
Coach: Ok. So let’s go back to that sprint planning meeting. Remember how the room was laid out and where everyone was sitting. You remember ?
SM: Yeah…
Coach: Let’s say you take John’s place. What do you see ?
SM: I’m really not sure where you want to go with this… But the only thing I see is that the monitor is too far away and its difficult to read.
Coach: Well that’s something to consider. And what are you doing in the meantime ?
SM: I’m updating the backlog and moving stuff around.
Coach: And how do you think John is perceiving this given the organisational culture ?
SM: I see… So we should probably use index cards that team members will be able to play with and update themselves.
Coach: Good! That way you solve two problems. By giving the team access to the sprint backlog you allow them to grasp more fully and own its content. They’ll probably feel more comfortable committing to it at the end.
SM (not really listening anymore): I can even update the backlog in the tool afterwards so that the flow is not interrupted. Thank you. That’s a great idea!
Coach: Well you know it wasn’t my idea. It’s yours. You just had to change your perspective on things.
SM (already leaving): Good. I’ll let you know how it turns out. Talk to you soon.
Coach (to himself): I’m not really sure what he saw exactly, but changing his perspective really allowed him to find new ideas on how to tackle this issue. This coaching stuff really works… I should blog this…

De retour après un long mutisme…

2009-12-31T20:27:00.001+01:00

Voilà deux ans que je m’adonne à d’autres choses intéressantes. Et comme ce lézard, aujourd’hui je refais tranquillement surface pour partager les idées qui me trottent dans la tête.
Beaucoup de nouveautés depuis! De nos jours, je me consacre presqu’uniquement au développement logiciel sur la plateforme .Net et à l’accompagnement d’équipes qui effectuent une transition agile. La compagnie pour laquelle je bosse est en pleine croissance et de nouveaux défis se profilent à l’horizon. Je vais donc avoir plein de matières à réflexion à vous proposer: Windows 7, .Net 4.0, pratiques d’ingénierie agile...

Je m’approprie, donc les nouveaux outils de blogue à ma disposition et je vous reviens bientôt.

Joyeux temps des fêtes!

NUnit devient plus expressif

2007-06-30T03:49:00.000+02:00

J'ai téléchargé la dernière version de NUnit 2.4 et je suis content des améliorations apportées à l'API. Le nouveau modèle d'assertion basé sur les contraintes rend les tests plus expressifs.
Je n'écrirai plus les assertions du type:

Assert.AreEqual(myString, "Hello");

mais plutôt:

Assert.That(myString, Is.Equal("Hello"));

ou mieux encore si ma classe de test hérite de AssertionHelper, je pourrai écrire

Expect(myString, EqualTo("Hello"));

Il me semble que cette syntaxe est plus lisible

Classification des tests

2007-06-30T03:24:00.000+02:00

Jimmy Bogard a un excellent message sur la classification des tests:

Les tests unitaires vérifient le bon fonctionnement d'une méthode/fonction en isolation du reste du système. Ils doivent s'exécuter rapidement et n'avoir qu'une cause d'échec. Pour ce genre de tests on évite d'impliquer une base de données, un service web ou tout autre système externe.
Les tests d'intégration vérifient le bon fonctionnement d'un système lorsqu'il est intégré avec les systèmes externes tels qu'une base de données par exemple. En général, ces tests vérifient que les données sont bien mises à jours dans la base de données ou qu'un courriel a bien été envoyé.
Les tests fonctionnels vérifient le bon fonctionnement de l'application dans son ensemble du point de vue de l'usager.

À lire également le message de Jeffrey Palermo sur le sujet

Pourquoi introduire de nouveaux acronymes ?

2007-06-14T04:20:00.000+02:00

J'ai visioné une présentation de Dan Ver Johnsson sur les Domain Logical Value Objects. C'est une présentation sur la manière d'introduire le Domain Driven Design dans du code patrimonial. En gros, le présentateur propose de commencer à rendre explicite les valeurs significatives pour le domaine en question: numéro de téléphone, taux de change, etc. De cette manière on peut rapidement bénéficier des améliorations suivantes:

Clareté des API de Service
Validation et gestion d'erreurs proches des données
Simplification du code de la logique de métier
Tests

Même si je suis d'accord avec les points présentés, je regrette toutefois que le présentateur aie ressenti le besoin de fournir un autre acronyme/terme technique: Domain Logical Value Object. Il me semble que tout ce dont il a parlé c'est des Value Object tels que présentés par Eric Evans dans son livre sur le DDD.

Par ailleurs, à un moment donné il propose un exercice pour trouver les situations où l'application du DDD est opportune. Selon moi, la réponse est que cela dépend toujours du contexte dans lequel ces projets sont entrepris. On ne peut répondre juste en se basant sur l'énoncé du domaine. Il faut impliquer les experts afin de connaître où ils en tirent le plus de valeur.

Domain Driven Design et Spécifications éxécutables

2007-06-13T05:20:00.000+02:00

Dernièrement, je donnais un cours sur le Domain Driven Design. Pour les exercices pratiques j'ai utilisé GreenPepper afin de pouvoir spécifier les fonctionnalités à accomplir sans pour autant imposer un design aux participants. Je dois avouer que je suis un peu perplexe quant au résultat de cette expérience. Les participants ont eu l'air de s'intéresser plus au produit qu'aux techniques présentées dans le cours afin de mieux cerner le domaine. Sans compter que l'apprentissage de l'outil peut constituer une barrière importante à la bonne conduite de l'exercice. Pourtant une approche basée sur des tests unitaires fournis ne me semble pas idéale car le design serait alors imposé. Les spécifications exécutables, par contre, se situent plus au niveau du modèle et du langage et de ce fait me paraissent encore plus appropriées...

Krugle - un moteur de recherche pour le logiciel libre

2007-05-30T04:23:00.001+02:00

Aujourd'hui j'ai découvert krugle un moteur de recherche dédié au logiciel libre. Ce site permet d'effectuer des recherches sur une multitudes de dépots de sources de projets du domaine public. Adieu les recherches sur Google...

My first walk in the blogosphere

2007-05-23T16:25:00.000+02:00

Hey,

I'm new to this! In the following weeks, I'll try to share some of my ideas with you. Hope you find them interesting...

Ernst