juillet 2010Monthly :

Les Agilistes de ce monde sont au fait de l’importance des tests automatisés pour assurer la pérennité d’un projet informatique. En fait, tout développeur qui a tenté la pratique du TDD et qui a réussi à inclure cette pratique dans son travail au quotidien découvre rapidement le sentiment de puissance qui en résulte. Ce sentiment de puissance prend sa source dans le fait que le développeur a beaucoup plus d’assurance et de confiance dans le logiciel qu’il développe. Le fait d’avoir plus d’assurance et de confiance laisse une meilleure impression au client et inévitablement résulte en une équipe plus heureuse. Cependant, afin de toujours s’assurer de livrer le maximum de valeur au client, il est parfois nécessaire d’ajuster le niveau de couverture des tests selon le contexte du projet.

Dans le cadre du développement d’une ‘preuve de concept’ (prototype), par exemple, il y a de fortes chances que le développement du prototype ne se poursuive pas pendant des mois. Le système ayant une taille réduite, l’équipe peut limiter la couverture des tests unitaires à certaines parties critiques du code car il est moins probable que le système régresse en qualité sans que l’équipe découvre rapidement une anomalie. Ainsi, s’appuyer simplement sur quelques tests manuels peut être un choix judicieux lorsque l’équipe a peu de temps pour développer les fonctionnalités requises afin de répondre aux objectifs d’affaires du prototype, à condition bien sûr de ne pas reprendre le développement du système à partir du prototype (ce qui se produit malheureusement dans la plupart des cas). Dans un projet Web MVC, par exemple, une équipe pourrait décider de tester uniquement le cœur du domaine d’affaires sans tester les contrôleurs ni les vues.

Le fait de couper sur les tests sous prétexte qu’on veut livrer plus de fonctionnalités d’un système dont le développement se déroule sur plusieurs mois à l’aide d’une approche Agile de développement logiciel est un choix qu’on pourrait qualifier de risqué. Un tel choix peut ralentir sérieusement l’avancement du projet car le risque d’endommager les bouts de logiciel déjà livrés sans test augmentera de façon quasi exponentielle sprint après sprint. En plus de provoquer l’inverse de l’effet escompté, ce genre de choix augmentera significativement le coût de développement du système. De plus, cette diminution de qualité créera nécessairement des tensions entre le client et l’équipe, ce qui nuira significativement au plaisir de développer du logiciel.

On constate ainsi que la définition de « Just Good Enough » pour les tests varie significativement d’un contexte de développement à l’autre, d’où l’importance de l’établissement d’une définition de ‘Terminé’ bien adaptée à la situation.

For the past two weeks I’ve used DuckDuckGo as my search engine. It’s a search engine built on open-source software. What made me switch is the capacity to navigate through search results with the keyboard using vi-like keys (hjkl).

I didn’t know at the time but Google also allows you do something similar. You just need to go to http://www.google.ca/experimental/ (also works for google.com and I guess most other domains). There you can opt-in to be part of the Keyboard shortcuts experiment. That’s it! J/K are used to navigate through search results, O (or enter) to open them.

Hopefully this is going to be useful for the other keyboard junkies out there.

ASP.NET MVC est une plateforme qui a été introduite par Microsoft essentiellement pour augmenter la testabilité des applications Web.

En ASP.NET traditionnel, il est relativement complexe de tester unitairement la logique à l’intérieur des contrôles.

1. Toute la logique est séparée individuellement dans chacun des contrôles (fichiers .ascx et .aspx).
2. Cette logique est contenue dans des méthodes appelées à l’intérieur du cycle de chargement des pages (page lifecycle) prédéfini par la technologie ASP.NET WebForms qui est difficile à simuler en dehors d’un contexte Web.

Le cycle évènementiel étant difficile à simuler, il devient nécessaire d’utiliser des ‘fakes’ ou ‘stubs’ des classes partielles des contrôles individuels, ce qui génère beaucoup de code pour de simples tests unitaires. De plus, la nécessité de ces ‘stubs’ complexifie passablement la pratique du développement piloté par les tests (TDD).

En ASP.NET MVC, c’est la séparation en trois responsabilités distinctes (modèle, vue et contrôleur) qui augmente significativement la testabilité des systèmes développés en MVC comparativement à la plateforme populaire ASP.NET WebForms. Ainsi, toute la logique nécessaire à l’exécution des actions appelées par un groupe de vues se trouve à l’intérieur d’un seul contrôleur. Il devient donc relativement simple de tester unitairement, directement (sans ‘stub’ de contrôle) et avec un minimum de code la logique métier des actions exécutables pour un contrôleur donné. On peut ainsi plus facilement piloter le développement du comportement de nos actions en le réfléchissant à l’intérieur d’un test avant même d’en écrire le code! On peut même aller jusqu’à tester les messages d’erreur qui peuvent être retournés aux vues selon les différentes actions. Bien sûr, il est toujours nécessaire de créer des ‘fakes’ pour les objets du domaine dont la logique interne est testée dans d’autres tests unitaires.

En plus d’être un moyen d’assurer la qualité du logiciel, les tests unitaires sont aussi une excellente source de documentation du code. Il est donc intéressant d’utiliser une syntaxe permettant à n’importe quel utilisateur ou programmeur qui ne connaît pas encore le système de comprendre le comportement du système.

Voici une proposition pour nommer les tests et les classes de tests afin d’augmenter leur lisibilité :

• Le nom de la classe de test contient l’action : When <the controller action>,
• La méthode de test explique le comportement souhaité : <object/user> <should be> <an action>…

Un exemple de code avec MS Test :

[TestClass]
public class WhenClosingTheBlog
{
	[TestMethod]
	public void UserShouldSeeAWarningMessageIfHeHasNotSavedHisBlog()
	{
		var blogController = BlogControllerFactory.Generate();

		var actionResult = blogController.Save(new Blog()) as
RedirectToRouteResult;

		Assert.AreEqual(BlogController.PENDING_CHANGE_HAS_NOT_BEEN_SAVED
, blogController.TempData["WarningMessage"] as string);

		Assert.AreEqual("Warning", actionResult.RouteValues["action"]);
		Assert.AreEqual("Blog", actionResult.RouteValues["controller"]);
	}
}
public class BlogController : Controller
{
	private public const string PENDING_CHANGE_HAS_NOT_BEEN_SAVED =
"Vous avez actuellement des changements non sauvegardé. Êtes vous sur de vouloir quitter la page ?";

	//...
	[HttpPost]
	public ActionResult Save(Blog currentBlog)
	{
		var path = userProfile.Path;

		if (currentBlog.HasPendingChange)
		{
			TempData["WarningMessage"] =
PENDING_CHANGE_HAS_NOT_BEEN_SAVED;

			return View("Warning");
		}
		return RedirectToAction("Home");
	}
	//...
}

Cette testabilité est un aspect important qui peut justifier l’utilisation d’ASP.NET MVC dans un contexte de développement d’un projet Web nécessitant l’utilisation de pratiques d’ingénierie Agiles.

Everybody knows no one reads documentation. Hamcrest found an original way to warn users to use the org.hamcrest.BaseMatcher class instead of the org.hamcrest.Matcher interface.

Look at the interface yourself.

They added a dummy deprecated method called _dont_implement_Matcher___instead_extend_BaseMatcher_ in the interface.

I am still unsure whether I will ever use this in my own projects. But when this method appeared in my code today I could not help but look at it. It was then totally clear that I was not doing what they wanted me to do. I’ve seldom seen documentation that obvious.