Category Archives: test

Addiction

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…
RedGreenRefactor
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.

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.Goto("Shopping/ShopOnline.aspx");
shopper.WaitFor(ShoppingOnlinePageLoadWait);
shopper.For(UnitPriceField).ShouldSee("5,00$");
shopper.For(NumberOfItemsField).Enters("2");
shopper.For(ProceedToCheckoutButton).Clicks();

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!')
clickOn(button)
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.