I've been building web applications in Ruby, on a full-time basis, for a couple of years now. During this time I've been exposed to a number of different testing strategies and approaches. Test-Unit, MiniTest, RSpec, Cucumber, Steak and many more. I've used many of these test frameworks to some extent, but despite the many choices I have in this area, I'm still befuddled by the right tools to building a web application in Ruby using test driven or behaviour driven development. The Rails framework has shipped with Test-Unit for years but the most popular testing framework is probably RSpec.

In order to quell my confusion, I thought I would expand on the three approaches that I have used most often in my time using Ruby.

1. The True Agile Approach

Perceived by some as the holy grail of testing, and in some cases with an equally preachy opinion, is the true agile approach. Being part of an agile team with a customer on hand to flesh out user stories, daily stand ups, retrospectives. Just about everything that embraces an agile approach to building software.

In this approach, test driven development and behaviour driven development tools reign supreme. If your approach is TDD, you'll most likely be using RSpec or Test::Unit for testing all aspects of your web application. If your approach is BDD, then it's Cucumber all the way. This is pretty much a no brainer really. With so many hands available for development, it makes sense to always write tests first.

2. The Solo Developer Approach

The true agile approach is fine when you're part of a team, especially when that team advocates pair programming and you have a customer on hand to flesh out user stories. What if you're a developer with your own product or service though? You understand the business domain enough to eschew the behaviour driven development approach but you still want to test your product?

I had this problem with the early iterations of Journalong. I understand the business domain, so is it really necessary to use a BDD approach? Can I simply just switch to a TDD approach with Test::Unit or MiniTest?

I'm still on the fence about this.

3. The Side Project Approach

This is simple, and I embrace this approach 100%. No testing framework or just enough tests to handle the complicated stuff. Hacking on your own ideas is a good time to really explore the frameworks and languages you are doing. Getting these setup correctly with all the proper test frameworks can be a chore though. If it's just an initial idea or throwaway solution you're working on then why bother investing the time in writing tests?

I want to be a good developer and develop solutions that are thoroughly tested but when was the last time you just hacked on a bit of software to try something out? If I know enough of the framework and language to get by then I don't bother writing tests. It might take me an hour to come up with something or half a day, but if that's all it takes then why bother getting all the correct bits in place to test it.

There's definitely a time and place for testing strategies in development, where you're part of a team building a product or building a revenue generating product or service on your own, testing strategies can give us the confidence we need to ship code on a frequent basis.

For my own ideas though I would rather roll my sleeves up and get into the parts of the code I know or even try new things with a part of the language or framework I haven't used. Kind of like code exploring, filling in the blank edges of the map if you like.