Brains working towards machine consciousness

 Over at TestFirst.org there is a nice (early stages) learning resource which I believe will be useful for helping people learn to program.  Using the Ruby language, and the RSpec gem as the basis for test driven design, the learning materials provide specifications which the learner then writes short programs to satisfy.

 Personally, I have never been particularly good at Test Driven Design (or Development), at least not with any particular degree of formality.  I do test all code as I write it, and doing Integration Testing, but I never got into the habit of using test suites; basically I don't end up with the paper trail which sows that my code works.  This is something a novice programmer would be well advised to get into the habit of doing, and TestFirst's materials encourage this.

 As a learning method, it can be quite an interesting challenge.  I took the approach, initially, of treating the specification as a 'black-box'.  I would run the spec, see the failure messages (or errors) and write some code to fix it, doing as little as possible each time.  Generally speaking, when programming, I would take a slightly different tack, and implement as much of the simple framework code as I could while in the editor.  But anyway, in some of the cases I found I actually had to go and look at the specification itself, in order to work out what the spec was actually looking for, but that is something which slight changes to the specs will make a difference to.

 My pattern was essentially

• Run specification
• Fix failures and errors if I knew how
• Check on internet for 'tricky' bits I needed help with, or as last resort, read the specification to get hints.
• Repeat until no Failures

Now, that is quite a nice learning pattern, as well as being the basics of the BDD pattern.  At this level it does rely on someone else having written sensible, working specifications - but that isn't too different to the real world either.  Essentially, the course leader can write specifications which lead the learners through how to add increasing levels of complexity to their program design.

It does make me realise just how little separation between design and implementation we generally put into our teaching of programming and design.  Something, perhaps, to change in the future?