Test First, Code Second

• Posted February 23rd, 2007
• By Sean Ransom (bio)
• Filed under: How We Do It, Technology

Hello, my name is Sean Ransom and as the VP of Technology at BatchBlue, it’s my job to make the decisions in regards to the technology we use and how we use it. My goal with this blog is to share insights and ideas we find along the way as we develop the BatchBook product.

Today I want to talk about the cornerstone of our application: testing.

One of the great things about working for a brand new company is that you are starting with a clean slate. Ideas you had for previous projects that were impossible to shoehorn into the existing codebase or that were not in scope are now possible. One of these ideas has been Test Driven Development (TDD), a programming technique that enables the developer to define what the desired outcome will be before writing a line of code.

At my previous place of employment, unit testing was just not part of the culture. I was always of the impression that unit testing was a good idea but not effective in relation to time lost on a project writing tests. Boy, was that a misconception.

Fortunately, we’ve made a conscious decision to start writing tests from the start. Our framework of choice for the BatchBook is Ruby on Rails and the most excellent RSpec fits nicely into the Rails framework. At this time Rspec seems to be becoming the leader of Ruby testing frameworks and we really like it. Rspec uses a flavor of TDD called Behaviour Driven Development. The idea is that you define your test as an expectation of what your code should do and then you build to that specification.

We’re finding this to be a very powerful technique and one that also helps in some areas one would not expect, such as documentation. BatchBlue is a virtual company and the development team can sometimes go days without face-to-face meetings to go review code. This can make it at times hard to get a handle on what your co-workers code is doing. TDD takes cares of this. You want to know how to apply a Tag to a record? Just head to the test directory, find the test written for adding tags and you have your answer. In my opinion this is the most powerful aspect of TDD and makes for a productive and collaborative development environment.

TDD is helping us build a very solid application. The ability to build to explicit specifications rather than just something in your head has made our development cycles quicker and enabling us to deliver better, well-thought out code. The only bad thing is I can’t believe it has taken me this long to fully embrace TDD. We love it and if you are not using it at your company you should give it a look.