Slides from RailsConf

David — Mon, 16 Jun 2008 10:10:38 -0400

Here are the slides from my session at RailsConf on Integration Testing With RSpec’s Story Runner.

RSpec-1.1.4

David — Tue, 27 May 2008 01:07:00 -0400

We released RSpec-1.1.4 today. It’s mostly a maintenance release but there are a few of cool new features that you may want to know about and take advantage of.

hash_including

One thing that has always been a drag is having to specify every key/value pair in a hash that is received as an argument. This is especially painful in Rails controller examples because Rails adds some data to the hash and the examples really don’t care about that extra data.

Enter hash_including().

This is a mock argument matcher that let’s you expect a hash including certain key/value pairs regardless of anything else that shows up in the hash. So instead of:

account.should_receive(:deposit).with({:amount => 37.42, :date => anything()})

you can just say:

account.should_receive(:deposit).with(hash_including(:amount => 37.42))

and keep the example focused on what you’re really interested in

Thanks to Rick DeNatale who submitted this feature request and the patch to implement it.

The heckler returns

RSpec wasn’t correctly supporting heckle for a while but the spec-heckler is back in action. For those unfamiliar, you can read about heckle at zenspider’s blog.

Here’s how you heckle your Animal model in your PetStore app:

spec spec/models/animal_spec.rb --heckle Animal

Thanks to Antti Tarvainen for resurrecting this one.

stub_model

This is for rails developers who like writing view examples with mock_model() but are sick and tired of having to stub every single attribute that gets referenced in a view.

Instead of creating a mock object like mock_model() does, stub_model() creates an instance of a real model class, but cuts off it’s connection to the database, raising an error any time it tries to connect to the database.

This is inspired by projects like unit_record and NullDB, but let’s you do things at a more granular level – allowing you to hit the db in some cases (where you think you really need it) and not in others.

Of course, you may prefer to the sort of “protection” you get from those projects, which ensure that no code touches the DB at all. If you do, have at it. This is just another option for you.

All this and more

These are just a few of the issues addressed in 1.1.4. For more information, check out the changelog and lighthouse.

Presenting at RailsConf 2008

David — Sat, 26 Jan 2008 12:15:59 -0500

I’m going to be presenting at RailsConf 2008 on RSpec’s Story Runner. I’ll be talking about how I approach writing for the Story Runner and address several related issues including:

plain text stories vs pure Ruby (when is which appropriate?)
extending the RailsStory with custom helpers
testing forms using webrat within the Story Runner
finding a balance of domain and UI scenarios
duplication between stories/scenarios and model/view/controller/helper examples

That’s probably already more than I can cover fairly in a 45 minute presentation, but feel free to make other suggestions if you have them.

See you in Portland!

David Chelimsky: Tag railsconf