Testing Times

Testing testing

Quick round up: we've built a development environment, got version control working, set up some project management, but we still aren't ready to dive in.  No, we are missing the most vital component of our development tool chain.  Testing. Really good code is code that we know works.  Mostly, code written for the 'job in hand' is poor.  Top down imperative coding is wasteful, counter-productive, and generally very expensive.  OK so I'm generalizing, and viewing the world from a very narrow perspective.  There are plenty occasions when imperative is fine.  Here we define a problem and write lines of code that solve the problem.  The code executes from the top of the script, runs procedurally to the bottom, and finishes by spewing out some result.  Its a hard wired solution that rarely holds up to scrutiny.  We want to be writing test driven functional code (more formerly, test driven declarative code.  So where does testing fit in, and why the big deal anyway?

Imperative vs. declarative coding.  Its all about structure, and testing.

When you are learning to program what you want to be able to do is write code that performs a task, solves a problem and returns a result all in isolation from the rest of the program.  That way your elementary instruction won't topple your program if it fails.  It will also be easier to maintain and test, and will lend itself to code reuse.  To implement this style of code we need to declare functions that solve discrete components of our problem, in isolation.  Therefore central to declarative, or functional programming, is the skill of being able to reduce a larger problem to bite sized chunks. We need to be focussed on building self contained functions, rather than the ordering of task execution, which is the concept that drives imperative programs.  The really neat thing about a self contained function, is that it is suited to testing.  In fact, when we consider a problem that we are going to solve with a function, we should be asking ourselves how do we know if our function is returning the right answer.  Better still, lets write the rules to test our function, before (or at least at the same time) as we build the function.  That is, writing a function is dependent up on the test.  Successful testing guarantees workable functions,  not the other way around.  When we code using this paradigm, we are subscribing to the notion of Test Driven Development.

Its about time we wrote some code.  So next time we'll produce the Hello World program.  But rather than the classic one-line, we'll undertake a full development cycle, making it a bit more interesting!

Here's the tools list we will need:

1. Project structure - we'll use redmine to specify our program. We'll set objectives, define a  time frame, and the issues
2. Code repository - we'll use SVN to keep our code safe
3. Python environment - we'll use a virtual environment to ring fence our code, and provide a sand pit.
4. Unit testing - we'll use nose, a python test suit to provide the function testing
5. A good sense of humour - not essential, but it might help.