oct. 21

Encore une fois, les méthodologies agiles font leur tournée en 2009. Et une fois encore, de nombreuses dates sont disponibles partout dans le monde, et principalement en france. Et cette année, un arrêt est également prévu à Lille le 30 Octobre, et c'est gratuit ! Pour plus d'information, regardez leur site web pour avoir tous les détails sur cet évènement !
J'étais très occupé l'année dernière et j'ai donc manqué l'évènement, mais cette année, il était impensable pour moi de ne pas y aller !

Si vous voulez parler de tests, de méthodologies agile, d'intégration continue, ... Rejoignez-nous là bas ! Avec mon partenaire Norman Deschauwer, nous donnerons deux sessions:

Retour d'expérience : XP n'est-il applicable que dans des petits projets ?

Nous avons souvent l’image d’eXtreme Programming dans des projets de courte durée. Et à en juger par quelques chiffres (15 personnes pour plus de 8000 jours hommes), notre projet est en ligne directe avec les métriques des projets traditionnels et semble présenter un volume de travail frôlant ou dépassant les barrières standards des projets agiles.
Cependant, nous en avons fait un vrai projet XP, avec il est vrai quelques adaptations à la méthode pour satisfaire nos contraintes propres.
Nous aimerions montrer ici qu’un projet critique – dans le domaine financier – même durant plus de cinq ans peut tout à fait être réalisé en XP. Serait-ce même la solution à suivre ?

Nous parcourrons les différentes valeurs et pratiques d’eXtreme Programming afin de mettre en évidence la façon dont nous avons pu les mettre en place, tout en montrant les différents problèmes que nous avons pu rencontrer et comment nous les avons résolus.

Discussion ouverte : Que tester dans une application ?

Que doit-t-on tester dans une application ? Que ne doit-t-on pas tester ?
Quels types de test devons-nous faire ? Des tests orientés GUI ? Des tests unitaires ? Des tests orientés données ? Exploratoires ? Aléatoires ?
Allons-nous mettre en place des mocks ou non ? Tester la base de données ?
Les tests me permettent-ils vraiment de vérifier l’application ? Ou tout simplement de la designer ? De la documenter ?

Ecrire un test est très simple, mais amène vite de très nombreuses questions.
C’est donc bien une session sous la forme « d’Open Space Discussion » que nous voudrions « faciliter » ici, afin que notre expérience et la votre permette de répondre tous ensemble à quelques unes de ces questions.

Vous êtes intéressés par d'autres sujets ?

Un Open Space est prévu à la fin de la journée, et pour plusieurs heures. Avec Norman nous resterons un moment pendant cet open space. N'hésitez donc pas à nous contacter, nous serons très heureux de discuter avec vous de tout sujet traitant de l'agile, XP, Scrum, les tests, l'intégration continue, ...

oct. 21

Once again, agile methodologies is doing his tour in 2009. And once again you can find lots of dates all over the world, mainly in France. And this year it again stops in Lille the 30th of October and it's free !. For more info, check the website to have all the details !
I was very busy last year and so I missed it but this year it was not possible for me not to go there.

You want to speak about testing, agile methodologies, continuous integration, .... Join us there ! With my agile speaker partner Norman Deschauwer, we'll give two sessions:

Return of Experience : Is XP applicable only on small projects ?

We often have the image of XP in small projects. And if we look to some figures (15 guys for 8000 men days), our project is directly in the metrics of traditional projects and seem to present a work volume overwhelming the bareers of agile project.
Nevertheless, we have made it a real XP project, with from time to time some adaptations to the method.

We would like here to show that a critical project (in the financial domain), even when lasting more that 5 years, can be done in XP. And maybe is this the solution to follow ?

During the session, we will speak about the different valus and practices of XP to show how we have put them in practice while showing the different problems we met and how we solved them.

Open Discussion : What to test in an application ?

What shall we test in an application ? What shall we not test ?
Which kind of test shall we do ? GUI oriented tests ? Unit tests ? Data oriented tests ? Exploratory tests ? Random tests ?
Shall we use mocks ? Shall we test the database ?
Do the test really allow me to check the application ? Or to design it ? To document it ?

Writing tests is very simple, but quickly brings lots of question. We want to have an Open Space Discussion with all of you to share experiences and try to answer to some of these questions.

Interested in any other subject ?

An open space is planned at the end of the day for a few hours. With Norman, we'll stay a while during this open space so feel free to contact us, we would be very happy to discuss of any subject around agile, XP, Scrum, testing, continuous integration, ...

oct. 20

A few years ago, when I discovered AOP, Didier Danse told me about an AOP framework he was liking for .NET : PostSharp by Gaël Fraiteur. So I started to try it, and simply felt in love with this tool.

I do not want here to explain how to use it (I will try to post some examples about that in the future) but for now, I just want to tell you my story about PostSharp, and why I really started to use it.

The context

A few years ago, I was writing data oriented tests : typically, I was inserted some data, checking the behavior of my web app and then cleaning my data. And so my tests started to look like this :

[TestMethod]

public void Mytest()

{

   try

   {

      InsertSomeData();

      InsertSomeOtherData();

 

      DoMyTest();

   }

   finally

   {

      CleanMyOtherData();

      CleanMyData();

   }

}

It was working, but was a bit too verbose and my test code was "lost among noise".

Kind of AOP using the .NET framework

I was not knowing AOP at that time but I was sure I was able to do something different. I read the book of Jason Bock called "Applied .NET Attributes" and I discovered the ContextBoundObject and I turn my code to this :

[TestMethod]

[InsertSomeData]

[InsertSomeOtherData]

public void Mytest()

{

   DoMyTest();

}

Much better and elegant. My attributes were doing the stuff of inserting and deleting and there were no more noise in my test.
But dealing with messages and sinks is not so simple and has a lot of limitation. Above all, all this stuff is done at runtime and impose you to inherit from ContextBoundObject. Possible for my tests, but no further application for my production code.

The revelation

It's at this moment that one of my colleague has done a thesis about AOP and that I met Didier Danse. He told me about PostSharp and I started to test it. And quickly I had migrated all my attributes into PostSharp. And of course I had in the meanwhile extended their capabilities for keeping my test very declarative:

[TestMethod]

[InsertSomeData]

[InsertSomeOtherData]

[ExecuteThisTestSeveralTimeAs("user1", "user2", "user3")]

[IgnoreThisTestIfDbVersionIsInferiorTo(35)]

public void Mytest()

{

   DoMyTest();

}

I was no longer injecting (asking PostSharp to inject) code into my test, but also modifying its metadata attributes ! I was indeed adding some IgnoreAttribute to my code at postcompilation if my test was not relevant to my current test context. This was alllowing me not only to reduce the number of test I had to write, but also to keep a very simple test result file without any inconclusive test.

My present

And I started to see so many possible applications in my code - without any performance penalty as every aspet I was thinking to would be woven at compilation time. (Well indeed there is a small performance penalty as PostSharp inject some additional method call but this is practically negligeable in practice. Note moreover that PostSharp 2.0 will just remove this extra overhead !)

My next step was when I wanted to do some performance investigation in my code. Usually, I add some Stopwatches in my code to capture the execution time and log that to a file. But in my case, I wanted to instrument many many methods that were calling each other. Ok... Let's do an assembly attribute and work with "OnMethodInvocationAspect" and using some filtering on my class names and method names !
In a few lines of code, I had instrumented thousands of methods (but only the one I wanted to). Pretty awsome.


What about now ?
Postsharp is now a key feature of my designs. How could I make a clean INotifyPropertyChanged without it ?

I would not say PostSharp is transparent to use. There is of course a learning cost and a vocabulary, specially if you do not know AOP by itself. But this learning cost is quite small compared to the productivity you can obtain in your development.
In my view, it's the best way to create some cross-cutting functionality in a very elegant and efficient way ! And when you want to enforce some design rules in your code, working declaratively is a dream ! Specially when you can work at interface level !

Tags: |