# Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

# January, 2010

 This blog has moved to blog.cellfish.se.
Posts
• #### Using Smilies to Reduce Story Cycle Time

The title I'm using was the title of an email I received on one internal mailing list. It was about a team where they tried to get more focus on completing stories. Also known as reducing cycle time, i.e. the time it takes from a story is started until it is completed. Anyway. The team was opposed to more statistics and graphs so this one guy came up with the idea of using smilies. The background is that this team wanted to complete all stories within three days. So when a story was started it got a happy face. On the second day it got a flat face and on the third day an unhappy face. If a story takes longer it gets an angry face (different levels of anger for each day going forward). Whenever a story is completed it keeps its face but also get a happy face with a trophy.

So did this work? Apparently it worked very well. In the daily stand-up meeting it is now common to hear things like "No you must help us complete this story so we don't get an unhappy face" when somebody indicates they will pick up new work. I think that is exactly the behavior you want. I might have to steal this idea...

• #### Team coding dojo 9

This time we decided to go back to the basics. Simple straight forward TDD using a really simple problem; FizzBuzz. Or we actually did a variant of it where I presented only one requirement at a time;

1. Create a program that writes numbers from 1 to 100 using a special printer class.
2. If a number is divisible by three, print Fizz instead of number.
3. If a number is divisible by five, print Buzz instead of number. If number is divisible three and five, print FizzBuzz instead of number.
4. If the number is more than 3 and not Fizz, Buzz or FizzBuzz; print lots.
5. If the number is 11, 42 or 47 disregard all other rules and print Cowabunga.

Since nobody (except me) had seen this kata before it was interesting to see how a simple design evolved into a pretty big and chunky thing that could be refactored into something nice. It is truly amazing to see how such a simple problem can take so long to solve (in little over 2 hours we actually only implemented 1-3 but considering the design 4 and 5 should probably only take another 10 minutes. But I guess that is what makes this a great kata. The problem is so simple but yet can be solved in so many ways.

And the reason to have the printer class was to force the use of an interface we could fake in the tests. Maybe an overkill but and we never used that class in our tests at all. Just the way it should be, wrapping and faking all external dependencies. This is what the external dependency implementation looked like:

```
1:      public class Printer
2:      {
3:          private Random _random = new Random();
4:
5:          public Printer(int device)
6:          {
7:              if (_random.Next(10) == 0)
8:                  throw new ArgumentException("Unable to lock device", "device");
9:          }
10:
11:          public void WriteLine(string line)
12:          {
13:              Console.Out.WriteLine(line);
15:          }
16:      }
```
• #### Fun Driven Development and Result Driven Development

I decided to add a few double Ds to my old list. First up is FDD as in Fun Driven Development. FDD is when you only focus on what is fun at the moment. This may sound great but probably also leads to a number of unnecessary features just because they were fun to implement. You should have fun developing but don't let the fun drive you...

Second is RDD; Result Driven Development. This is a technique I've started to use lately that works very well for me when writing tests. Actually it works well for all code but I tend to forget it as soon as I'm done writing a test. Have to focus better I guess. So what is Result Driven Development? The idea is to always start with the result when you write a new function. That is; the first line you write in a new function should be the last line of the function returning the desired result. This does not mean a hard coded value (as you might assume if familiar with TDD) but rather to write the desired code.

For unit tests this is pretty straight forward. You first write the assert you want. And then you start filling in the missing pieces. When implementing the function being tested you do the same; start with the desired result and then fill in the blanks. For example consider a function that is supposed to return a new price after applying VAT and discounts. The first line you write should look something like this:

```
1:  double CalculatePrice(double price)
2:  {
3:      return price * (1+vat) * (1-discount);
4:  }

```
Then fill in the blanks:
```
1:  double CalculatePrice(double price)
2:  {
3:      Customer customer = this.Customer;
4:      State state = States.customer.State;
5:      vat = state.VAT;
6:      discount = customer.Discount;
7:      return price * (1+vat) * (1-discount);
8:  }

```
I think this method helps me writing code that is easy to understand and focusing only on the things I need.
• #### Handling different versions of the database

The only way to handle database changes I've used before was either a number of SQL scripts which usually was a pain since it was almost impossible to remember what version of the database you had so you never knew which of the scripts to run. A better method I've used was to use a migration tool that identified differences between two databases. Basically a merge where I merged all changes in one database to another.

Since I've been protected from database work for a while and (shame on me) never took the time to look at Ruby I did not discover Migrations up until recently. And for everybody who do not want to use the ruby version, there is a port for .Net which I definitely will have in mind the day I'm back to working with databases again. The idea is to create one class for each change and including a version number in that class. The rest is handled by the framework.

• #### Results of a simple TDD experiment

Well, I wish it was my own report this time but it isn't. Instead I'd just link to this little experiment. As mentioned in the comments it is not a statistically proved result but I still think it's good that somebody took their time to add one more data point to the overall statistics. Hey, it inspired me to do that too. Well I probably can't do the same detailed story point per hour thing but I should be able to at least count the number of bugs found in different areas of the code and compare that to complexity and test coverage. No idea if that is interesting but it might be something. Just hope people with more data publish it even if not what they want.
• #### Mocking framework comparison

As you may know I think mocks should be used quite carefully. But as I've pointed out before I think you should use the best tool available and that means to use a mocking framework sometimes. One thing I've never really liked with the typical mocking framework is how it requires you to learn a new API to setup the test double. And if you don't know the API I think a typical mock setup can be very confusing if you see the code for the first time. However if you choose Stubs as your framework you get the benefit I'm looking for (primarily not having to hand roll my test doubles). You avoid a powerful framework that can mock things you shouldn't really mock (making your code easier to test by design rather than by use of framework). And also you do not require the user to learn a new API; Stubs uses standard language features (delegates and closures) to setup the stub.

There is actually a great project where you can compare different mocking frameworks (including Stubs) called mocking-frameworks-compare where you can study a number of different tests written with different frameworks. Here is one example from that project using Moq:

```   1:  public void TouchHotIron_Yell()
2:  {
3:      var hand = new Mock<IHand>();
4:      var mouth = new Mock<IMouth>();
5:      hand.Setup(x => x.TouchIron(Match<Iron>.Create(x => x.IsHot))).Throws(new BurnException());
6:
7:      var brain = new Brain(hand.Object, mouth.Object);
8:      brain.TouchIron(new Iron { IsHot = true });
9:
10:      mouth.Verify(x => x.Yell());
11:  }
```

If you're not used to Moq I think there are a number of things that stand out as weird. First of all there is no assert in the test. Second the setup is not obvious. And it is not obvious that we are verifying Yell is being called or if Yell is going to be called by the verify method. Now, let's look at the same test using Stubs:

```   1:  public void TouchHotIron_Yell()
2:  {
3:      var hand = new SIHand();
4:      var mouth = new SIMouth();
5:
6:      hand.TouchIron = (iron) =>
7:      {
8:          if (iron.IsHot)
9:              throw new BurnException();
10:      };
11:      bool yelled = false;
12:      mouth.Yell = () => yelled = true;
13:
14:      var brain = new Brain(hand, mouth);
15:      brain.TouchIron(new Iron { IsHot = true });
16:
17:      Assert.IsTrue(yelled);
18:  }
```

You might notice that the test is a little longer and feels more verbose. But that is not necessarily a bad thing. On the contrary I think that is a good thing. Also the only framework specifics you need to know is to use the stub-class and know it has a property to define behavior. Apart from that there is also a performance benefit from using Stubs which you can read more about here (note that the support for partial mocks that is mentioned as not yet supported is now supported). All this things considered I think Stubs is the best mocking framework choice you can do today.

Preemptive comment answer: But Stubs is not a mocking framework! Well I think it is because I can create mock objects, fakes and stubs (i.e. any kind of test double) with it. So the same thing as Moq or RhinoMocks for example. Same, same, but different...