Tea-Driven Development

A few months ago I was at the peak of my powers.

I was leading a team of ten C# developers building a huge project on Microsoft’s .NET platform. I had been working on the Windows platform for years, and there was rarely a question from the team I couldn’t answer quickly and confidently, drawing on a deep well of past experience.

Continue Reading »

Some people think there is no conference for those of us who care about CI and testing, but oh yes there is.

As an avid reader of this blog, I know that you, like me, realise that continuous integration and testing are to software development what the spirit level and the plumb-line are to the construction industry: powerful tools that will one day be regarded as essential for any professional practitioner.

If you fancy meeting other like minds, come and join me at CITCON, the Continuous Integration and Testing Conference. What could be finer?

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.

Continue Reading »

How many unresolved bugs are there in your system right now?

Yes, yes, smarty-pants: the ones you already know about.

Ten? Fifty? Two hundred? More?!

I find it frighteningly common to see teams let a huge backlog of bugs build up. They set up a trusted system like Jira or Bugzilla and then use it as a dumping bucket for a whole variety of irritations, glitches, missing features, and genuine defects.

Pretty soon the list becomes un-managably large. Nobody dares go in there, because it’s full of bad news. This drains the team’s energy and morale.

Getting on top of, and staying on top of your bug list is hugely important, and I outline my thoughts and experiences on achieving that below.

Continue Reading »

One thing that isn’t documented very well for RSpec is how to test your routes.

I came across an old post on the rspec mailing list which described a great way to do this:

describe TasksController "routing" do
 
    it "should route POST request for /tasks to the 'create' action" do
        params_from(:post, "/tasks").should == {:controller =>; "tasks", :action =>; "create"}
    end
 
end

Very nice.

If you or one of your team-mates uses ubuntu for their desktop, you might want to check out jccray by Ketan Padegaonkar.

It may also be available with the main cruisecontrol source though it doesn’t appear to be there at the moment.

On my last project, some joker took the (much maligned) paper file marked ‘Use Cases’ and gave it the more accurate title ‘Useless Cases’.

We hated that file. It contained so much misinformation, so many gaps.

Take heed though: Alistair Cockburn still thinks use cases are relevant.

We certainly learned on that project that while heavy-weight up-front use cases are a waste of effort, going into a sprint planning meeting with nothing more than a token for a conversation is also similarly irresponsible.

As Alistair says, the key is to get just the right amount of analysis done and no more, just in time. Finding that sweet spot takes practice, and lots of feedback within the team.

For many moons I used to ponder on the challenge of how to get Visual Studio and TFS to stop developers from checking in code when the tests didn’t pass.

Continue Reading »