Yurii Rashkovskii's Blog

RSpec 0.8.0 is finally released

I’ve been adopting Railsware projects to new release since 0.8.0 RC1 and I should say I like 0.8. It is a really good improvement over 0.7.

Thanks to one of the Caches.rb users, I’ve got to improve it today a bit.

Now Caches.rb makes use of some kind of pluggable storages, which makes it pretty simple to use different storage techniques. What for? The primary intention is to support database-wide ActiveRecord model method caching. All models of the same class and the same ID will share the same caches.

 
  >> article = Article.find(1)
  >> article.expensive_method
 => some work + result
  >> article.expensive_method
 => cached result
  >> Article.find(1).expensive_method
 => cached result
 

As far as I remember, #find has started caching model instance in Rails recently, so there is less value in my today’s Caches.rb improvement. Though I’m sure it makes some sense. At least it was interesting for me to play with it.

You can try out new caches.rb by getting its trunk (rev >= 49). Warning: it’s a very early code, use it with caution. If you’re not sure you want to have some experimental code inside your app, please stick with rev48 or so.

P.S. Documentation is not updated yet to reflect changes. I will do this after (and if) this code will be considered stable enough.

Hello, rspec 0.8 early adopters. I’ve fixed rspec-ext to work with 0.8.0RC1. You can try 0.1.0 pre-release gem

I’ve created rspec-ext gem, which is supposed to simplify experimenting with some rspec hacks I was doing with the help of others.

Try it by installing

 
  sudo gem install rspec-ext
 

It includes specify_negatively and aspects now.

Hi! Sorry for no articles for a while, I’m pretty busy with Railsware activities currently. Anyway, while doing some internal product, I’ve come to a need in aspects for rspec.

Why do I need this? There are contexts in rspec already, you can say. True. But what these context are intented for? Lets cite rspec documentation: It is a metaphor for the context in which you will run your executable example – a set of known objects in a known starting state. Right. And there are plenty of specifications that run against given context. But if you have a relatively large project, you’ll find that your specifications become messy even within one context.

That’s why I’ve tried to add aspects. They are usually 1-2 words describing primary aspect of functionality you’re testing. It could be “printing”, or “versioning”, or “tracking changes”, or “validations”. Let me show how it looks now:

 

  context "New Document instance" do

  setup do
    @document = Document.new
  end 

   aspect "versioning" do

    specify "should have no versions" do
     @document.should_have(0).versions
    end

   end
 end

Easy? I bet! I’ve done quick-n-dirty implementation for this feature and started improving structure of my tests. This implementation requires ActiveSupport at the moment but could be easily ported to pure Ruby. I’m just too lazy tonight.

Any thoughts?

Update Thanks to Michael, I’ve updated algorithm to support nested aspects. You can use new version to enjoy nested aspects.

I’ve updated specify_negatively a bit. Now it will report your specification name as “NEGATIVE: #{your description here} (NOT YET IMPLEMENTED)”. You can change NOT YET IMPLEMENTED to whatever reason using specification options:

 
  specify_negatively "should accept spam comments", :reason => "BUG" do
  end
 

You can find updated sources here

P.S. Now I see some advantages of specify_negatively over solution proposed by rspec crew