Factorial Bug Hunt

by Andy Masters 25. March 2011 16:06

I was playing around with TDD again. It highlighted to me just how bad a very simple and correct looking function can be.

In maths, Factorial(n) is written n!, so Factorial(10) is the same as 10!.

1! =1
2! =1*2=2
3! =1*2*3=6
n! = n * n-1 * n-2 * ... * 1

I wrote this function without TDD to calculate the nth Factorial number recursively:


public static long FactorialRecursive(int index)
{
   if (index==1)
   {
      return 1;
   }
   return index * FactorialRecursive(--index);
}

I then rewrote the function using TDD. I discovered 4 quite serious bugs in the above code, see if you can find them (answers in my next post, although I expect there will be others that I've missed too). I also tried a radically different approach to writing the function, how would you write it?

 

The benefit of unit-testing is that seemingly correct code should get smoked out.

The benefit of TDD is you get a better design, and just enough tests to prove it is correct.

 

 

Tags:

Development | Ideas | Testing

Amazon EC2 - Short Term Use Tip

by Andy Masters 11. November 2010 07:37

I just recently left one of my EC2 compute instances running for a week without meaning to - this gave me an extra $20 bill. Not the biggest in the world, but still annoying if you don't need to pay for it.

For my automated build server, I only need EC2 instances a couple of hours at a time never more than a day. So as a precaution:

  1. add a scheduled task running daily to automatically shut it down at 3am. (The command 'shutdown /s' can be run to achieve this on a Windows Server 2008 box)
This way, if I forget to shut down an instance it won't run for more than 24 hours before it shuts itself down :)

Tags:

Development | Ideas

Google Sets as a way of generating test data.

by Andy Masters 27. May 2010 07:17

As TDD and unit testing becomes increasingly popular, the need to generate Test Cases and test data has grown.

It it is possible to do this yourself, however:

a) I don't have much imagination when it comes generating test data. This lack of variation is bad news for test coverage.

b) It takes time to think up examples.
c) Its easy to use you own and colleague's names etc for test data, as they are easy to recall. From a confidentially perspective this is something to avoid. 
d) Using 'funny' test data might lighten your day, but unfortunately has an uncanny ability to turn up in live systems!


So enter google sets: http://labs.google.com/sets

In case you've not used it before, you give a few examples of things in the set that you want to generate

(e.g. Red, Green, Blue) and it generates you a much extended list of members of this set (Colours):

  • red
  • blue
  • green
  • black
  • white
  • brown
  • pink
  • yellow
  • purple
  • orange
  • gray

This is great for generating test data. If you just want quick and dirty data, then just use google sets direct. However to take things one step further Google sets has an API - James Simmonds has written 'DataWang' that does this in a C# wrapper for you.

You could also use this approach to scrabble your confidential live database data into a 'mashed' version that is safe to distribute to vendors for support purposes.


Tags: ,

C# | Development

Powered by BlogEngine.NET 1.5.0.7
Theme by Mads Kristensen