For those not up on the lingo, TDD stands for Test Driven Development and is an approach to developing which focuses on writing test for how code should function before you implement the code. The basic premise is that most developers (guilty) focus on writing functional code first and subsequently aim to add unit tests to ensure that the code runs as it should. Particularly where environments encourage results quickly, this approach often leads to tests being unwritten, incomplete or lacking decent coverage.
Since I came across the approach a couple of years ago, I’ve been a major fan. However, I haven’t found it easy to modify my behaviour to write tests before writing the code. In fact, I’ve found it quite painful. This post, as a result, caught my eye. The author has set himself a challenge of writing a single piece of code a day for the next 12 days and forcing him to use a TDD approach. I’ve decided that I’ll join in, provided the amount of time for each challenge doesn’t impact my family life over this (very much required) break.
All my code will be available within a BitBucket repo available at https://bitbucket.org/CraigHawker/12-tdds-of-christmas with a folder for each set of code.
Today’s challenge is a simple one:
Your task is to process a sequence of integer numbers to determine the following statistics: o) minimum value o) maximum value o) number of elements in the sequence o) average value For example: [6, 9, 15, -2, 92, 11] o) minimum value = -2 o) maximum value = 92 o) number of elements in the sequence = 6 o) average value = 21.833333
You’ll find today’s set of code within a folder named “Dec26″. Note that you’ll find my actual NumberAnalyser.Analyse method rather sparse (in fact, everyone will say I cheated if they look at the code) but my focus is on the process of TDD, not the actual method I’m implementing. I couldn’t care less that the internals of my method use Linq to work out the min/max/count/average and, actually, neither should you.
So, what’ve I learnt? The main thing so far is that I often find with testing that it’s hard to know where to start and stop, particularly where you’re writing something that works with numbers. For example, I’ve got methods that test for an expected exception, and methods that check for expected min/max/count/average values for arrays with a single item and a second set that tests arrays with multiple items, but where do you stop? I found this hard with TDD as it wasn’t obvious which tests made sense to start with and implement the method out in stages. I’m hoping that comes more naturally over time.
Anyone else fancy joining me?
Items in this series:
- 12 TDDs of Christmas (day one: Calc Stats)
- 12 TDDs of Christmas (day two: Number Names)
- 12 TDDs of Christmas (day three: Mine Field)
- 12 TDDs of Christmas (day four: Monty Hall, day five: FizzBuzz and day six: Recently-Used List)
- 12 TDDs of Christmas (day seven: Template Engine)
- 12 TDDs of Christmas (day eight: ranges)