Tuesday, 27 January 2009

How much longer does TDD takes?

When I introduce TDD to new people, one of the first question they ask is "how longer does it take?". Dale has a nice post about the real answer to this. To sum up his post the answer is that when taking everything into consideration doing TDD makes development goes faster. this can be backed up by several case studies (found here)

The one thing to add to this is that like any new skill, at start it does take longer. I remember that for me it felt I was going so slowly that in times I thought about forsaking it altogether. (for me the turning point was when I started to feel the power of higher quality but that's another subject) Point is that if you're now evaluating TDD take into consideration a learning curve that will take a few month but at the end doing TDD just make things go faster.

Signs of a Death March

A "Death March" project is a project which is destined to fail. The term "death march" in this context was discussed at length in Edward Yourdon's book Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects.

I had the "pleasure" of leading a death march project and for me it was one of the most depressing experiences I had so far. In my case the death march was caused by the wrong decision to commit to an impossible schedule to get a funding for the project. We all knew the schedule was unrealistic but we thought that its better to get the money now and worry later. It goes against the notion of "Fail Fast" but at that time I was unaware of this notion. (Actually I've learnt about the whole death march thing only after the project was terminated).

Being inside a death march is not fun. I think that doing a death march has a huge negative effect on the people involved that usually outlast the project itself (if the team is lucky enough to survive this project). The funny thing is that I've seen companies that intentionally put their team into a death march in order to drive the team to achieve more. The logic behind that is that if you set a high enough goal and do your best to get there you will achieve more if you just aim and reach a reasonable goal. I feel that this logic is flawed on so many level that I don't know where to start.

Signs of a death March

I think that one of the biggest issue with a death march is that in many cases the participants are not even aware of doing it. In many cases people ignore the warning signs, waiting too long to take action. In that sense admitting the problem is half the solution.

Here are some signs of a death march

"Schedule is tight but if everyone works harder and things will go smoothly we can make it" - This is the first sign of trouble. The longer until the due date the more likely you are doing a death march. How many times does things goes smoothly? Isn't the team working hard now? Where did all the margins disappeared?

"We charted out most of the big things but some things are still missing" - Another sign meaning there is still work which is yet to be scheduled in. It also indicate that someone is does not even have the time to fully understand what is really necessary to get the release on time. Where will the time be taken to actually do the work? this time the closer it is to the due date the

"We don't see people working until 22:00 in fact not even until 20:00" - The project due date is in 4-6 months. Do we really expect people will work 12:00 hours a day until then? and if they do will the be effective at that for such a long period of time? 12 hours per day is not Sustainable Pace, If that's what will save the project the project is doomed.

"We are trying to cut everything that is not a must for the release" - Put differently "Its most likely we wont finish all the necessary work, I don't even want to think on the thing that are not absolutely mandatory"

"I'm really sorry, but something important came up" - The manager gives an excuse on why he cant attend the meeting which has been scheduled and accepted by him. Is it that important that it cant wait a couple of hours? or do you just have too much work as it is? and usually a stressed manager will most likely means a very stressed team.


And last, in most cases - you can just see in the eyes of the people involved that they lost their belief.

So what other signs have you encountered?

Friday, 23 January 2009

How to Mock a Static Method

More and more i encounter places and people that still insists that static methods cant be mocked and therefore makes unit testing code which uses them harder.

Here's a very short example on how a static method CAN be mocked using the proper toolset in .Net, Java and C++. The ability to mock static methods is part of the mocking libraries I am using (Isolator for .Net, PowerMock for Jave and MockItNow for C++).

Design wise, I do NOT claim that using static methods is a good practice. In fact I am NOT a design expert, and therefore I don't have any sort of claim on what are good design practice and what are bad design practice. What I do claim is that unit tests can be written to code even if it does use static methods.

In all the examples I'll be using a class which looks something like this:

public class ClassWithStaticMethod
public static int StaticMethodReturnFive()
return 5;


public void MockStaticMethodToReturnSix()
Isolate.WhenCalled(() => ClassWithStaticMethod.StaticMethodReturnFive()).WillReturn(6);

int actual = ClassWithStaticMethod.StaticMethodReturnFive();
Assert.AreEqual(6, actual);


public void MockStaticMethodToReturnSix()

    int actual = ClassWithStaticMethod.StaticMethodReturnFive();
    Assert.assertEquals(6, actual);


Mocker mocker;

ClassWithStaticMethod* fake = new ClassWithStaticMethod();

int actual = ClassWithStaticMethod::StaticMethodReturnFive();

Monday, 19 January 2009


A new (well relatively new) video prepared by Hamid from Axosoft does an excellent job at introducing SCRUM. Its a little less then 10 minutes, and fun to watch. There's also a blog post on its making which I found to be interesting.

Thursday, 15 January 2009


Looking back at the previous post, I really like the term. I'm sure it would come handy I wonder if I can make this one stick???

Zephyr - Another Test management system

About a week ago I was approached by a guy from Zephyr company which develops

The World's Most Flexible Test Management System.

Apparently they stumbled upon this blog (which is about testing) and since they just release a new version of their software tool they thought it might be a good idea to let me review it and say a few words about it. Well since they asked so nicely, I took some time and looked into it. a moment of honesty, everything that follows is based on a very short and initial impression that I got from seeing their demo and browsing through there site. but anyway...

The Good

On the good side I must admit that on the visual side they look very good. The general look and feel of the tool are good and the ability to change skins (which I did find a little out of place) also has some added value.

2 things that I found worthy, is the inherent support for a distributed team, including an option of hosting the actual data on their servers which can be accessed through the web. The other is the extensive report system they seem to have. I was impressed both by the amount of out of the box reports, and by the technique in which one can dive deep from one report to another getting more and more details on the project.

The Bad

First there's the price, 65$ per person per month seems a little too pricey for my taste. Second, it seems to me that the Zephyr system tries a little too much to be a little of everything. Besides managing tests plan and test schedule it has a built it IM system and a place to store users information (which looked to me like some sort of address book). Last I didn't see any place for customizing Zephyr, it might be there but I couldn't see it mentioned anywhere.

And the Irrelevant

The really sad news for me was that yet again the Zephyr tool is clearly an "old school" product. It reflects no Agile concept whatsoever, on the contrary it generally encourage a command and control kind of system. It is build around a lead which defines the work and assign task to all other testers, the tasks are then put on a timeline (which looks a lot like a GANTT chart to me). If you ever thought about managing a testing using Agile concepts this tool is not for you.

In short Not that I have anything against the tool, but if you approach a blogger which is run by an AGILE consultant, do try to at least look a bit agile. Asking him to review a "waterfoolish" tool can be a bit out of context.

Wednesday, 14 January 2009

VB .NET Mocking

Typemock has released a new version yesterday (5.2) in which they included a new API for VB developers. unlike previous version this time the VB API was specially planned and designed in VB, for VB developers. Hopefully using special constructs of the VB language will result in an easier and more intuitive API. With my limited experience using the VB language i cant say I can be a good judge for that.

For blogger's out there, Typemock is also offering a chance to win a free license you can check it out here.

beside the VB API the new version also continue on improving the C# AAA syntax adding to it capabilities such as true indexers, better repeating mechanisms and some more.

One important thing to watch out from, is that default mock creation has changed (taken from Typemock Blog):

Another change in this version is the default behavior for creating fake objects. It has been changed to Members.ReturnRecursiveFakes when creating a  fake instance without any parameters.

Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Walgreens Printable Coupons