Hi, my name is Mathieu and I am a test addict

I wasn’t always like this. It all started a few years ago. I was working on a graphic application and there was a fluke. I only saw it once. The colors kept flickering: red-green-red-green-red-green. I was mesmerized, I could not look away.

I was staring at the screen, trying to figure out what went wrong when I felt something… snap… inside my head. I didn’t know what it was and went home, but it kept haunting me. I could not sleep that night, so I went to see the Guru, a little guy standing high on his ebony chair, on the last floor of the highest building in town. I talked about the colors, and like I felt something was missing from my life.

“Unit test you shall” was his answer.

I did some research and found what he was talking about. Testing frameworks, stubs, mocks. A new world opened to me. I read about all this weird stuff all night.

The morning after I started to test, I was wondering what it would feel like.

Red – hm mm, OK
Green – nice, something works!
Refactor – change this, and this… and the code still works!

I felt peace inside, a feeling that nothing could go wrong with my life, ever again…
I was hooked.
RedGreenRefactor, RedGreenRefactor

Over and over, faster and faster

The light kept flickering. I couldn’t get enough.
I felt… strange. I felt… alive.
Corporate drones kept coming close, attracted to the light like little bugs, but they had to shield their eyes – the light was too strong. A few people went blind and were set to maintain the mainframe, deep under the Earth’s crust.

But one particular mindless Cobol Zombies was attracted by the light . I handed him the keyboard and as he started to code, I could see flesh forming all over his rotten body. He was alive!

The addiction could spread. I was amazed. I had just saved a life!

But I cannot do all the work alone. I need your help. Help spread the word, help save the world!

Disclaimer: This is a mostly true story. Some events and places have been slightly modified for my own enjoyment.
No Cobol Zombies were injured during the writing of this story.

How to be Agile in a Day

I read a few articles lately that claim Agile is basically a magic bullet that will allow you to have greater productivity in a few weeks. Well a few weeks is too long… Here is my magic recipe to be Agile in a day. It just requires a little preparation:


  • Hire a good mix of junior and senior programmers.
  • Hire passionate, pragmatic programmers that care about their craft.
  • Make sure your team is co-located.
  • Have a definition for a work item that is ‘done’. Were coding standards followed? Is the feature tested? Is it documented? Is it installed in a demo machine?
  • Plan the release of the product with the main features and an approximation of how big the whole thing is going to be.
  • Plan the work for two or three weeks at a time.
  • Make the team take responsibility for the work to be done in the next iteration.
  • Test everything you do thoroughly (unit tests, end to end tests, and anything you feel is required in between).
  • Know the difference between a stub, a mock and a fake for tests. Know when to use each one.
  • Have a continuous integration build.
  • Name your classes with words the customer will understand as much as possible. Programmers and customers understand each other better if they speak the same language (DDD).
  • Have a good knowledge of object oriented design.
  • Fix your bugs as soon as you find them.
  • Refactor early, refactor often.
  • Pair program when you can.
  • Organize code reviews.
  • Have a customer on site (or at least readily available) so you can question him about the requested features.
  • Demo your product at the end of each iteration to get customer feedback.
  • Ship! Release your software to some users early and often to get even more feedback.
  • Integrate the feedback into your next development cycle. If the customer changes his mind because what he saw is not what he expected, do not be afraid to recode entire features (but make sure the customer knows he will not get new features in the meantime).
  • Hold a retrospective at the end of each iteration. Identify the biggest problem you currently have and take steps to solve it.
  • Follow up the retrospective with concrete actions to obliterate your problems. Retrospective are useless if you talk about the problems but do not solve anything.
  • Always strive for higher productivity. “We always did it like that” is seldom a good reason not to improve.
  • Allow failures. Expect the team to fail from time to time. Never failing might mean the team is aiming too low.
  • Do all of the above for a few sprints. The longer the better. If you can do all of the above for a year and still continue to ship valuable software for a customer while maintaining clean code, there is a good chance you can continue to do it for a long time.

That’s it for the preparation. Now, here’s how to be Agile in a day:

  • Read a book about Agile methodologies. Realize you’re already pretty good but you still have a lot of room to improve. Claim that you are now Agile.

There’s no shortcuts, no magic bullet. Software development is hard. Agile software development even more so. Do not expect every programmer you meet to thrive in a dynamic environment where everyone must take responsibility for their work. Agility is not for everyone. I believe it is the most enjoyable way to build software, but I’m aware that a lot of work lies ahead.

So can you be Agile in a few weeks or less? Well if you are already doing almost everything in the list you probably can. If you do not understand why the list is important, you’re far away… Claiming you can be Agile in a few weeks might be a nice commercial gimmick but that’s about it…

Book Review: Six Thinking Hats

Thinking is a skill. Like any other skill it can be improved.

Six Thinking Hats aims at making your thinking process more effective by removing something that I rather enjoy but which makes any decision longer to come: arguments.

People do not use arguments because it is the preferred way. They simply do not know any other way.
– Edward de Bono, Six Thinking Hats

I admit, I’m guilty… I’ve been in a few useless debates before. I’ll try to change now that I know another way…

Instead of arguing back and forth over an idea, it might be worth it for everyone in the meeting to gather information over a single axis at a time.

So when you explore an idea, you might want to wear a different hat to be sure to explore all sides. This can be done in group meetings or if you are alone thinking about a problem. Colors are used because they offer a neutral language which is easy to remember:

  • Blue: overall view, control of the thinking process
  • White: cold facts and information
  • Yellow: hopes, positive outcomes, advantages
  • Black: caution, warning, disadvantages
  • Red: emotions, feelings, hunches
  • Green: creativity, new ideas

The premise is that it is difficult to view all sides at once. In a meetings it gets worse because someone might be focused on finding what is good about an idea while someone else is focused on the drawbacks. Disagreement follows and it becomes a willpower contest.

A brief example

You do not have to use every hat for each decision. You might for example start with a blue hat to define the problem and the desired outcome. The you might gather as much information as you can about the problem (white hat). Then talk about the advantages of a particular solution (yellow hat). If the advantages are not what you expect, then just drop the idea and explore something else. No need to argue over a bad idea…

On the other hand if the idea looks good, then request everyone to put on their black hat and explore the hurdles that might encountered during the implementation.

Power of the team

So I invite you to think about the principles behind the book and try to find alternatives to arguments to solve problems. I know it can be fun, but arguments just are not that effective…

By focusing on each side separately, everyone is sure to have a global view and the decision is probably going to be easier to reach. Everyone is focused in a single direction at a time. Everyone is working together instead of against each others. If you’re a software development team, it might be time to act like one…

Clearer Intents using Selenium

If you’ve ever had to write Selenium tests, you know it’s a pain. Tests are very verbose, so you probably create your own methods as a library on top of Selenium. And when the next project comes, you start again from scratch…

Two colleagues started a project called Fluent Selenium to ease the pain. They wrote their own DSL (Domain Specific Language) over Selenium to make the tests more readable. The DSL is in C# and uses Selenium RC to control the web site. The project is still in its infancy – only basic features are implemented. However I think it looks promising.

Here is an excerpt from one of their sample code. The API is changing fast so it might not be accurate, but it should be enough to give you an idea:


shopper is an instance of the User class, which is the actor that drives the web site. You probably guessed that the test drives an online shopping and checkouts two items.

What I really like about Fluent Selenium is that it makes it clear what is the intent of the test. The framework suggests to put xpaths out of the way (using Locators like UnitPriceField above) and to really concentrate on what you want to test from a user’s perspective. Reading the test reads almost like you would read a sentence!

So next time you need to write Selenium tests, remember to make it Fluent!

Clarify Your Intent

A maintainable unit test suite is essential in making software that will stand the test of time.
However after a while, some tests might get hard to read.
I was working on a flex application lately and was using fluint as my unit test framework. When we could we used the framework to test GUI components.
At some point we had a component that was composed of a text input and a button. For the sake of simplification, let’s say that when clicking on the button, a label gets updated.
At first, the test looked like this:

component.input.text = "hello, world!"
component.button.dispatchEvent(new MouseEvent(MouseEvent.CLICK))
assertEquals("hello, world!", component.label.text)

When I read the test this is what went in my mind:

Set the text of the 'input' of the component to 'hello, world!'
Dispatch a mouse event of type click to the component's button
Make sure 'hello, world!' appears in the component's label text

That gave me an headache…
Next I changed the code to:

enterText("hello, world!')
assertLabelEquals("hello, world!")

Let’s read it outloud again:

Enter text "hello, world!"
Click on the button
Make sure the label equals "hello, world!"

Now whenever someone looks at the test, the intent is a lot clearer. Whenever possible, try to make the test readable for a human being. Tests are part of your code. Written clearly, they document the intent and are a pretty good reference on how to use a class. However it’s pretty important to make the test read like a possible user of the class would use it.
The API of the class being tested might be clear enough that you don’t have to do anything. If it is not, don’t be afraid to create another API in your test to make the intent clearer.

Iterate your Way to Success (and have fun doing it)

I’ve been interested about Agile methodologies for a while but until recently I’ve never been on a project that really embraced iterations and change. e did try a few techniques (daily meeting, poker planning, task board for the iteration) but it did not really work at the time, possibly due to a lack of successful evangelism on my part.

I just finished working on a third sprint in a Scrum project. And this time, it just worked.

The team was interested in the new process, the client was often coming to see what was going on, the ScrumMaster was great at explaining the process, the artifacts (product and sprint backlogs, burn down chart), the meetings and why we were doing each of them (daily, demo, retro). Some people were not familiar with the process but a quick and clear explanation of the next step kept everyone interested and in focus.
Here is what went right in this project:

  • Preparation – the client and a few team members prepared a product backlog, rough drafts for the look of the user interface and a little bit of useful documentation.
  • Collocation – everyone was sitting a few feet away from each other
  • Quick wins – first sprint of one week delivered a bit of functionality while developing the build tools and test structure. This allowed the team to get a feel of what an iteration feels like (we did the planning, demo and retro as usual) while getting our build, continuous integration and test framework underway.
  • Client involvement – on site two days a week, not changing his mind in the middle of the sprint. Would it have been better if the client had been there five days a week? Maybe, but two days is a lot better than nothing!
  • We shipped! We did have a few hiccups, but overall we did ship working software and the client was happy with it.

And how did people feel about our ways of working? I can’t talk for everyone, but here are a few things that I liked:

  • Commitment– I believe everyone wanted the project to succeed and did their best.
  • Openness – pretty much everything was open to discussion, including the architecture and the features the client wanted.
  • Pride – for me this was a big one. I was proud of what we achieved and proud of the team.
  • Fun – need I say more?

A few things could have been better:

  • Lack of focus – we had a tendency to work on tasks on many stories and closed most of them at the very end of the sprint.
  • Adaptation – our retrospectives allowed us to highlight a few points that we wanted to improve but we did not really address those in the following sprint.

Although not a silver bullet, iterative development sure give you all the tools to run a successful project. A motivated team will perform better and what better way to motivate people than to give them the power to improve and select their own tools and processes?

I’m eager to start on my next Agile project…

Working Agreements

You are in the middle of a great brainstorming session with your new team. Ideas are flying, everyone participates when you hear a ring. You hear in a hushed voice: “Sorry honey, I’m in a meeting, I’ll call you back.” Everyone stops talking to look at the culprit. The flow is broken. It takes a few minutes for the team to pick up where they were before.

Having a set of working agreements with your team can help to prevent this (and other) situations. Working agreements are behaviors that regulate all interaction between team members as decided by the team itself. This is very important: teams that decide their own rules are more likely to follow and enforce them. The act of deciding gives the team a sense of ownership. Working agreements can be discussed during a retrospective or if you don’t do retrospectives (which you should), I guess you can do another meeting for them.

Once a team decided their own working agreements, it becomes easier for everyone on the team to enforce them, not just the project manager, team leader or other authority figure. “I did not appreciate when you were late to our pair programming session earlier today” is not understood as complaint about one’s behavior but as a gentle reminder of the rules the team agreed with.

Here are some examples of working agreements:

  • The time everyone is expected to be at the office (9am-4pm or whatever fits your team). Outside these hours people have to be aware that some might not be available for meetings
  • Usual lunch time (same principle as above)
  • Time of daily meeting
  • Meetings should begin on time
  • Cell phones should be turned down during meetings
  • Only one person at a time can be mad (I really heard about this one, it’s supposed to allow people to vent while preventing others from shouting back…)

Working agreements can also be more fun:

  • The person who makes the nightly build fail has to bring breakfast (pastries, donuts, fruits) for the team
  • The person who makes a build fail is awarded the ‘Cow of Shame’ (or any ugly figurine) until someone else breaks the build

If the ‘Cow of Shame’ is ugly enough, your teammates will run the tests twice on their machine to make sure everything is green before committing their code… and so will you.