Bryan Helmkamp, who maintains the handy little library webrat, did a talk recently at GoRuCo 2008 which explains his experiences using RSpec plain-text stories to build ruby-on-rails applications in a manner he calls ‘Story Driven Development’:
Before code is written, the team produces executable scenarios for a user story.
The talk is very much grounded on the assumption that you’re working within the rails framework, but it clearly illustrates that driving your application through automated acceptance tests that can easily be understood by your customer / product owner / business analyst / stakeholder (delete as applicable in your world) and easily maintained by you is very possible with this technology. Even if you’re working in another framework, it should give you plenty of ideas about how you’re approaching your delivery of user stories.
Personally I think we may end up calling this ‘Scenario Driven Development’ – a phrase I first heard Jason Gorman use – as it seems to me that it’s the scenarios that you build within a story that really help you to shape the software.
Find the slides here.
And watch the talk itself here.
Ok my (latest) understanding of all this is:
1. TDD = helps you write the code right in regard to technical issues (SRP, SOC for instance).
Now we all know we’re writing software for actual customers (that’s not the case on a project I worked in the past but I digress) so we have :
2. “”””””Functional Requirements”””””” Driven Development = helps you write the right code in regard to actual requirements.
Both of those to be “*DD” seem to imply that there is some form of automation too. For TDD we have NUnit and CCNet, for the other kind we have Selenium, Fitness (now knowing what Fitness is I don’t think I will bother), and others.
I find it really interesting that some are now including “”””””Functional Requirement”””””” Driven Development (BDD, “Story Driven Development”) as being part of TDD as in this book in progress:
So is the Agile world gone mad and simply re-inventing the wheel ? That is there should be equal focus in technical requirements (code quality, low coupling, sometimes performance) and functional requirements from day one of any project.
Am I mad doctor ?
PS: your website looks funny with Firefox 3.0.1
I don’t think that the DD necessarily means you have to automate anything, although it obviously helps in practice.
The point is more what Dan North calls ‘outside in’ development – you only bother writing code because you have a concrete example – expressed from a user / stakeholder point of view – that the current code doesn’t satisfy. Without such an example, you don’t touch the code.
I agree it’s not exactly revelatory to be giving equal focus to functional requirements as well as technical quality, but this is the first time I’ve seen a relatively painless way of expressing what the code should and does do in a way that programmers, stakeholders, and the build server can all understand.
Leave a comment