Specifying Behaviour vs Specifying Implementation

At the JRubyConf in Columbus, Ohio last October, Jim Weirich presented "Testing – Why Don't We Do It Like This?". At the end of the presentation he suggested asking two questions to ensure our tests are specifying behaviour rather than implementation:

1. If I wanted to use this software in my project, what behaviours are important to me?
2. Could I write this software from scratch using only the tests/specs as guidance?

These are definitely useful questions to ask, rather than blindly writing specs to simply get 100% test coverage. Check the entire presentation below:

Testing – Why Don't We Do It Like This? – Jim Weirich from Engine Yard on Vimeo.

Recent Project: Wayne Gretzky Estates

Not all projects need to be complicated! This was one of the simpler, low stress projects (yes they do exist!) of the year, working with creative director Bob Beck at Dynamo. I'm not a huge hockey fan, but who wouldn't want to work on a project with The Great One's name on it. For the tech geeks, Wayne Gretzky Estates is an online store developed using Spree, a Ruby on Rails e-commerce platform. Screen shots below.

Catalog

Gallery

News Index

News Article

ShoeDazzle featured on TechCrunch

I had the pleasure working with ShoeDazzle in Los Angeles this summer when they re-developed their shopping platform. ShoeDazzle offers a personalized style service with a celebrity flair. For a monthly subscription fee, you have a choice of a pair of shoes, handbag or jewelry from you own, personalized catalog, handpicked by celebrity stylists. Fun!

This month ShoeDazzle is featured on TechCrunch and described by Jeremy Liew "the most underrated [company] in his portfolio". Checkout the interview below with Brian Lee.

Truncate HTML in Rails

After a bit of searching for a truncation helper for HTML, I found this great gem: truncate_html. It maintains the HTML tags (i.e doesn't strip them out) and supports word boundaries. Nice! Oh, and supports Rails 2.x and 3.x.

The Mocking Debate Continues

Nick Gauthier recently blogged about "Everything that is wrong with mocking, bdd, and rspec". Nicks' a smart guy, you just need to check out his presentations to understand that. In his post he attempts to demonstrate the brittleness of mocking. While his arguments appear sound at first glance, Pat Maddox presents a well articulated argument. Reading his points on collaborators and protocols gave me a clearer understanding of BDD. I repeat here, but encourage you to check out the comments check out the comments. It's a great debate.

The mock-based example specifies the interaction with the collaborator. It demonstrates that you can pass in any object that responds to #puts(str) and expect it to work.

Your refactoring is valid -- when the output object responds to #puts, #write, #print, and #<<, and implements them all in basically the same way.

You are free to change the internals of a method however you want, but remember that certain changes will have broader-reaching effects than others. Changing how you build up the string to, say, an array of strings that then get joined, should certainly be encapsulated. Changing how you call collaborators is a totally different thing -- you're changing the contract, potentially in a way that's incompatible with existing clients.

Focused examples (or unit tests, or microtests, or whatever) help answer the question, "what do I need to know to use this code?" When there is a collaborator involved, one of the key things to know is the protocol that the collaborator must adhere to. An interaction-based example makes that protocol explicit. Moreover, it establishes a checkpoint. Should you decide to call #write instead of #puts, you have to consider the possible implications to existing code.

I understand where you're coming from. When you run the program, there is no externally visible difference in behavior. That is why we tend to separate the duties of checking program behavior into acceptance tests. Your unit tests then become a place for you to check an object's correctness, which includes its own logic and its interactions with other objects. Don't assume that because the external behavior of the program stays the same, that the behavior internal to objects has stayed the same as well.

Avoid a bloated slug on Heroku by configuring Bundler

This tip was outlined in Heroku's December email newsletter, and wanted to repeat here. It's a must know. You don't need your development and test gems in production, so configure your Heroku application accordingly:

Smaller slug, faster installation and compile times, nice.

Recent Project: "Aldo's Let's Dance" Fall Campaign

By the lack of blog posts this month, you might have guessed that I've been busy. You're right! I even failed to blog about a launch early this month. But here it is...

I had a great time working with Dynamo, located in the old port of Montreal, on Aldo's fall campaign, "Let's Dance". The concept is simple: upload a video of yourself dancing to Think About Life's Sweet Sixteen and let Internet groupies vote via Twitter, Facebook and/or YouTube. The entries have been fantastic, the traffic through the roof, and voter participate off the charts. It's definitely the most fun I have had all year. Check out the screen shots below and some technical details for those inclined, but better yet visit the site before 6th December to get the full experience before voting ends.

Thanks to Alex (Interactive Director), Jenna (Senior Designer) and Marie (Front-end Integrator) from Dynamo who made this such an enjoyable project to work on.

Home Page

Gallery

Video

Registration

Technical Details

"Let's Dance" is built using Ruby on Rails, tested with Cucumber and RSpec and deployed on Heroku. The application integrates several different services via Oauth: Twitter, Facebook and YouTube. By using Oauth we are able to track unique votes, as each vote is captured with the voters Oauth ID, but still allow visitors to share videos as many time as they wish.

Video uploads and approvals are managed using YouTube Direct and deployed on Google App Engine. While this saved development time, the open source application does not currently support Internationalization. It was possible to "hack" this in, but it was more time consuming than it should have been. Having said that, it was great to be able to off load all video processing and management to YouTube.

Deploying on Heroku is a huge help with the sudden influx of traffic. With campaign sites, there's no ramp up with traffic, so the application has to handle large amounts from day one. We monitor performance using NewRelic (on-demand application management), to ensure the application has the resources it needs for fast response times.

Need help with you Ruby on Rails application?

Please contact Nicholas Henry at Firsthand Web Design.