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.

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.