Over the course of 2010 I spent most of my off time working on my side project, Just for Bands. Specifically the first application to come from Just for Bands known as LiveShow. The LiveShow application was written in Ruby on Rails with the plan to deploy it to Heroku (a successful plan I might add). But the main point of this post is the idea of doing Test Driven Development (or TDD) in Ruby on Rails and how it allowed my partner and I to build an app quickly.
Testing is Built In
Something to know about testing frameworks and Ruby on Rails, there’s one built in. The built in testing framework in Ruby on Rails is Test::Unit. There are other frameworks that you can substitute in place of Test::Unit, but as far as “out of the box” frameworks go, you could do worse. Having a framework built in allowed me to teach Erick (my partner, who had never worked in Rails before) how to follow the TDD workflow: Write test, run test (seeing it fail), write minimal code to make test pass, see test pass, refactor (bold because people tend to forget this step). Erick had never done test driven development before, and I had never used Test::Unit (or written a Ruby on Rails app) before, so sticking with the built in framework allowed us to minimize the number of things we needed to learn from the get go.
Delegation of Responsibilities
Erick and I had a pretty strict division of responsibilities with regards to the work needed on the application. Since I’ve been developing code professionally for almost a decade, I was the developer. Erick was the sweeper, going between design and development duties where ever needed. And we hired a graphic designer, John to handle the more complex design work. Having such divisions allowed us to separate out the work. But it left me in a position where I felt I couldn’t develop a ton of code because I didn’t have any screens to wire up. This came from a lack of deep understanding of the MVC (Model View Controller) pattern that Rails is based on. To keep it quick, this pattern means there’s separation between the UI, data, and processing layers.
Testing Allows Coding Without The User Interface
Because the MVC pattern is designed with separation of various application elements in mind, I was able to develop the backend code without any screens. The idea of testing functionality as you develop using the built in test framework allowed most of the major functionality to be written and built while the design was worked out else where. This was crucial to our ability to get the product built and launched in one year’s time, while learning new languages and tools. Once the functionality was done, it was just a matter of tying it together with the user interface once we had a design we were happy with. Of course there were things that didn’t work quite like expected when we got the interface wired up, but it was less work than doing it from scratch, and having to wait would have meant delaying the product.
Also, with the tests we were able to see if it was the UI not working correctly or if it was really our functionality. In a couple of places we were testing for the wrong thing, or had an error in our test that caused a false positive. But those were much quicker to iron out with the tests in place. Having unit tested as we developed, we were able to save tons of time on the backend of the project fixing bugs.
If you’re ever had the privilege of reading “The Pragmatic Programmer” then you know that they recommend that programmers learn at least one new language a year. Around this time last year, I made the decision to begin following that practice and chose Ruby/Ruby on Rails as my programming language for 2010. While not directly related to my day job, I wanted to build something in the language. With the help of my friend we were able to build our first 
Michael Koby 