How to debug FitNesse.Net tests

FitNesse is the tool we use to specify our Acceptance Criteria.

To debug a FitNesse test where glue code is written in C# or any other .Net language, there are several possible options:

• Specify FitNesse TestRunner.exe as an external program in the debug properties of your glue code project. See this blog post: Debugging FitNesse Tests
• Put a “Thread.Sleep(5000);” in your glue code so that you have 5 seconds to attach your Visual Studio to the process that executes your tests (FitServer.exe)
• Use the plug-in written on TestDriven.Net. You may have to recompile it depending on the version of TestDriven.Net you use, but it works.
• Use GFlags.
• …

My favorite option so far to debug FitNesse tests is using GFlags because it’s really simple and doesn’t require any code changes.

All you need to do is to make 2 registry files, for example:

• AttachDebuggerToFitserver.reg, containing:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\fitserver.exe]
"Debugger"="vsjitdebugger.exe"

• DetachDebuggerFromFitServer.reg, containing:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\fitserver.exe]
"Debugger"=""

If you want to debug FitNesse, execute the first file. When you run the tests in the Wiki, a debug window will pop-up, and you can attach your Visual Studio Solution containing the glue code.

If you want to disable the debugging again, just execute the second file.

I saw this possibility for the first time on TechEd Barcelona 2006 in a Hardcore Debugging session by Ingo Rammer. Ingo used it to debug a Windows Service which failed at startup.

Final tips:

• Also commit this 2 files into your code repository, so that your colleagues can use them. Don’t keep these precious things for yourself.
• Add this 2 little reg files to your Launchy catalog. Then you can start/stop debugging FitNesse by hitting <ALT>+<ENTER> and typing for example “debugfit” or “stopdebugfit”.

Just try it, it’s really simple and effective.

Retrospective: The Safety Exercise

In many teams the retrospective has always the same format where the team members are asking these 3 questions over and over again:

What went well? What didn’t went well? What are we going to change?

They probably don’t get the most out of that. They end up with telling the standard things, maybe even those things that managers want them to change instead of the things that really help them move forward. Just asking these 3 questions, wont let them think deeply enough to really improve their work. Another option is that they end up with a gigantic list of impediments, not prioritized, not taken action upon. Doing the same meeting over and over again will even get them bored! And maybe they will question if they still need to do the boring retrospective meeting.

That said I would like to refer to the book “Agile Retrospectives: Making Good Teams Great” by Esther Derby and Diana Larsen. The book describes a set of practices that you can apply in your retrospectives to make them better.

In our retrospectives we apply practices such as the TimeLine, Prioritize with Dots, Mad-Sad-Glad,… All practices described in the book.

In our latest retrospective we tried a new practice “The Safety Exercise”. One which is not in the book, but talked about on the Agile Toolkit Podcast.

The Safety Exercise is really important with a new team. It's a way to loosen up, or at least assess how comfortable a team feels.

Especially where there are managers in the room or their Scrum Master is their former Project Manager. Team members are not sure of their place, they're not sure how much they can really say. And you don't know how safe people feel.

A way to do it, is passing out index cards to each team member, and let them put a score 1 to 5 on the card indicating how safe they feel.

The Safety Exercise gets a temperature reading on that, the numbers meaning:

• 5 Oh well, I'll talk about anything!
• 4 I'll talk about most things, but there are a few things I wont talk about.
• 3 I'll talk about the easy, non controversial stuff. Nothing negative.
• 2 I'll agree with what everybody else says.
• 1 I just don't want to talk!

One of the team members will thereafter collect the cards, shuffle them and read the numbers out loud. Write them on the board. Throw the cards away. You can also make an average number if you want to.

It gives a really anonymous reading how comfortable the group feels.

If you've got a lot of fours and fives, you probably got a group that feels rather comfortable with each other.
If you have a lot of twos and threes, it will probably be hard to talk about a lot of the stuff. Probably for good reasons for things that happened in the past.

If it’s really bad, maybe you need to have a retrospective without having the managers around. Be aware: the feelings of the managers can be hurt. :-) Why are they hiding from us? Why are they afraid from us? Do I allow my team to be self-organising?

Maybe it just needs some time. The good thing is that it creates awareness by the managers and the team.

In our retrospective, we got a lot of fours, a couple of fives, and a few threes. And we will apply the practice again in one of our next retrospectives.

Trying out the Pomodoro Technique

[Starting a new Pomodoro timer of 25 minutes. My task is to write this blog post.]

A while ago i picked up on Twitter a lot of enthusiasm for the Pomodoro technique. It is a time management technique which is very well suited for Agile Software Development.

Staffan Nöteberg is writing a illustrated book on the Pomodoro Technique, which I enjoyed reading a lot.

Basically, you have 5 steps in applying the technique and a bunch of rules.

Step 1: Start your day with planning

You need to maintain an Activity Inventory where you list up and estimate your tasks. Estimations are expressed in number of pomodori, being time units of 25 minutes. (Max 7 per task)

Every morning you select a number of tasks and write them on your To Do Today Sheet. That’s your commitment for today.

Step 2: Tracking: subsequent Pomodoro of 25 minutes each.

Choose a task to complete and whenever you’re up to it start a Pomodoro timer for 25 minutes and focus on finishing that task.

So until the timer rings… work focused on the task! Don’t start other tasks.

[I just remember that I need to answer a SMS message on my cell phone. But I’m in the middle of a Pomodoro, so I can’t do this now! I put it on the bottom of my To Do Today sheet so that I don’t forget this and mark the internal interruption with an ‘X‘ near my task.]

If you finish the task before the timer rings, continue reviewing the task, and draw a line through the task on your sheet when the Pomodoro rings.

Step 3: Recording

Recording is about listing up your daily observations such as the number of pomodori you completed that day. (your Pomodoro velocity).

You can record also the number of interruptions, number of voided pomodori,…

Step 4: Processing

Processing is about abstracting the raw data from the recording into information such as calculating averages of pomodori spent…

[RRRRIIIIING –Pomodoro is over... let me just complete that sentence] 

…on a task or the sum of pomodori you complete in a week.

[Now I take a break of 5 minutes. I’ll take a thee and answer that SMS message now. Back again and rewinding the Pomodoro timer to 25 minutes. Time is ticking again…] 

Step 5: Visualizing

In this last step you hold a personal daily retrospective to optimize your day. You can make for example a daily what I’ve learnt mind map. Or you can think about how to handle internal and external interruptions. Goal is continuous improvement.

The Rules:

1. Once a Pomodoro begins, it has to ring!
2. If a task takes more than 5–7 Pomodoros, break it down.
3. If the task takes less than one pomodoro, add it up, and combine it with another task.
4. The next pomodoro will go better :-)
5. Don’t use the Pomodoro Technique for activities you do in your
   free time. Enjoy free time!

[go back, reading over and polishing the text a bit...]

This cheat sheet will help you getting started with the Pomodoro technique. Just give it a try!

[RRRIIIIIIING. Ok, let’s post this to my blog and draw a line through the task on my To Do Today sheet. And let’s take another break before I pick my next task.]

Agile Retrospectives Mindmap

A while ago I've read the book Agile Retrospectives in the Pragmatic Bookshelf series, and made following mindmap while reading the book (click to enlarge):

Book review: Bridging the Communication Gap

Recently I bought "Bridging the Communication Gap" written by Gojko Adzic. It is certainly a 'must read' for all those working on agile teams trying to deliver what the customer really wanted.

 

In Gojko’s view, the reason for most project failures is a breakdown in communication between the technical and non technical roles. The book shows how important and difficult it is for a team to reach common understanding and communicate about requirements, design and acceptance criteria.

 

Agile Acceptance Testing, the subtitle of the book, is not just for testers! In fact it affects all of our jobs starting with the customer and functional analyst. But everyone in the team must be involved in achieving Executable Specifications. This is done in Specification Workshops, which take place in the beginning of each iteration. These topics are discussed in depth in the book.

What I really like about this book is that teams can actually start implementing the practices based on the books content.

I’ve recommended the book too five people so far and if you are concerned about delivering what a customer really wanted, I recommend it to you too.

Scrum @ Adobe

This presentation is presented at the 2009 Scrum Gathering in Orlando.

Always interesting how a big company like Adobe transitions to Scrum, how they do it, what progress they make.

Some facts from the presentation:

• Adobe = 25% Scrum (and growing), 75% Non Scrum
  
• 25 Scrum teams, 300 people
  
• Started in 2005 with Scrum
  
• Introduced an Agile Coach role in 2008
  
• 48% of the code written by the agile teams is covered by Unit Tests
  
• 13 products of Adobe are build with Scrum today
  

Also interesting to know is that they are doing company wide surveys to adapt their Scrum implementation, let's call it a retrospective.

Belgium Agile Open - Spring 2009

I've just participated in the Belgium Agile Open - Spring edition 2009.

It was a great event and I learned quite a lot.

1. How to handle changes to existing user stories:

- in scrum, 3 of the most important events fall together: review, retrospective and planning... and thats not good at all. I have to learn more about Kanban / Lean :-)

- the user story format "as a" ... " i want to"... "because" .... is really adding value.

- the only valuable feedback is when you have a piece of software in production. That's all that matters!

2. Agile Testing:

- keep into account the cost vs the value when automating tests, applying the Moscow-principle

3. Agile Documentation:

- get feedback from your online help (monitoring what users type in the help search box)

- use a FAQ for users

- update your informatice workspace during development.

- apply 'Telling a Story" from the book "Working Effectively with legacy code"

4: Agile Consortium:

- it's a Benelux consortium, which probably will have a lot of influence soon.

- they will provide certifications, we'll need have to have in our curriculums

- they can make it easier for us to "sell" Agile

- it's a marketing thing :-)

5. Manufacturability of software:

- what do they mean by manufacturability?

- a good software design is simple

- a good archtecture is testable, loosely coupled

- the harder it is to 'disassemble' your software is, the higher the cost to maintain and change it 

6. Dimensional Planning:

- there is a big difference between incremental and iterative development. Xavier has made a great blogpost on the subject.

- dimensional planning adds another dimension to planning, which is Depth.

• dirt road: This level is the manual work around
• cobblestone road: This level is the bare minimal implementation
• asphalted road: This level is the sober implementation
• highway: This level is the full implementation

- Scrum does not encourage the Depth dimension. You can do it with Scrum, but it's not encouraged.

- Inxin has some presentations on Dimensional Planning.

7. Fit/Fitnesse:

- a great advantage of using a tool like Fit /Fitnesse is that it encourages communication between customers, testers and developers.

- Gojlo Adzik published Bridging the Communication Gap and it got a lot higher on my wishlist. :-)

It was the first event I attended that correctly applied the Open Space Technology. Congratuliations to our hosts: Peter, Koen and Patrick, and thanks to everyone who contributed.