Behaviour Driven Development with RSpec

January 6th, 2007 at 3:11 pm (Agile, Rails, Ruby, Software Development)

I’ve started using RSpec in my Rails projects. Besides serving the purposes of testing my application, it has also become an extremely useful design tool. Comparing the DSLs for Test::Unit and RSpec, the latter expresses the intention of the tests much more clearly and quickly. Luke Redpath does a great job of explaining the basics of Behaviour Driven Development using RSpec on Rails. Its a must read if you’re interested in exploring BDD for your Rails development.

Technorati Tags: , ,

Comments

Introduction to ActiveResource

December 18th, 2006 at 11:45 am (Rails)

Rick Olsen, a member of the Rails core team has a good writeup on working with ActiveResource. It seems that Beast is taking advantage of ARes to provide a RESTful API while keeping all the heavy lifting transparent to the user of the resource.

The documentation on ActiveResource is really scarce at the moment and posts like Rick’s are hugely useful to Rails developers who are looking to leverage ARes in their applications. Speaking on which, I would be refactoring an internal app used within my agency for ARes soon. I just have to implement the remaining user stories and take it to 1.0 first.

More on that as I get deeper into development.

Comments

Have full disclosure for code vulnerabilities

August 11th, 2006 at 10:45 am (Rails)

The Rails core team released 1.1.6 of the framework today, a day after 1.1.5 was released. This was to fix a serious vulnerability in the Routes module. The core team has been extremely prompt in publicising the hole and in releasing fixes.

However(you know there had to be one), I take issue with how the first fix release (1.1.5) was handled. It appears that this release did not fully rectify the problem, hence the need for 1.1.6. While DHH revealed the reasons for 1.1.5, he did not detail exactly what was wrong, opting for a security through obscurity approach.

In retrospect, a full disclosure policy would have been a better move. This would have given developers more information in deciding whether to shut down their sites, in view of the implications(data loss/theft et al) of having it compromised.

That said, if you’re running a rails web application in the wild, UPGRADE NOW.

EDIT: mixed up my rails versions, doh!

2 Comments

Automatically creating files for file_column models in Fixtures

May 17th, 2006 at 11:57 am (Rails)

I wanted to be able to have my testing regime automatically create files associated with model fixtures defined in the fixture files. Coincidentally, I'm using Sebastien Kanthak's file_column plugin for managing files in models.

After looking at the Fixture class and the FileColumn module, I realised that I needed a way to store the model attribute(s) that were passed in the call to file_column. What FileColumn did was create the methods according to the attribute passed into the method but the attribute itself is not actually stored anywhere.

Time to extend FileColumn:

PLAIN TEXT
RUBY:
  1. require File.join(RAILS_ROOT, 'vendor', 'plugins', 'file_column', 'lib', 'file_column')
  2.  
  3. module FileColumn
  4. module ClassMethods
  5. @@file_column_attributes = {}
  6. alias :aliased_file_column :file_column
  7. def file_column(attr, options = {})
  8. aliased_file_column(attr, options)
  9. klass = self.name.constantize
  10. @@file_column_attributes[klass] ||= []
  11. @@file_column_attributes[klass] <<attr
  12. end
  13.  
  14. def file_attributes
  15. @@file_column_attributes[self.name.constantize]
  16. end
  17. end
  18. end

As the name implies, the methods in ClassMethods are class methods on the including class. So in order to store the file_column attributes, we need a class variable, @@file_column_attributes. This variable is a hash with the model class name as the key and an array containing the attributes.I'll also implement a class method so that I'll be able to do Model.file_attributes and know what attributes have been file_columnised.

Next, we'll need to change the way fixtures are populated to the test database. This involves extending the Fixtures class.

We'll do this in test_helper.rb

PLAIN TEXT
RUBY:
  1. require 'fileutils'
  2. class Fixtures
  3. SAMPLE_FILE = File.join(Test::Unit::TestCase.fixture_path, 'files', 'sample.pdf')
  4. include FileUtils
  5.  
  6. alias :original_insert_fixtures :insert_fixtures
  7.  
  8. def insert_fixtures
  9. original_insert_fixtures
  10. create_files(@class_name, values) unless @class_name.constantize.file_attributes.nil?
  11. rescue NameError
  12. # workaround for HABTM fixtures
  13. end
  14.  
  15. def create_files(klass, values)
  16. model_dir = File.join(Test::Unit::TestCase.fixture_path, 'media', 'uploads', klass.downcase)
  17. values.each do |fixture|
  18. klass.constantize.file_attributes.each do |attr|
  19. create_file(fixture, attr, model_dir) unless attr.nil?
  20. end
  21. end
  22. def create_file(fixture, attribute, parent_dir)
  23. attribute = attr.to_s
  24. dest_dir = mkpath(File.join(parent_dir, attribute, fixture['id'].to_s))
  25. file_dest = File.join(dest_dir, fixture[attribute])
  26. cp(SAMPLE_FILE, file_dest) unless fixture[attribute].nil? or File.exists?(file_dest)
  27. end
  28. end

The extended insert_fixtures method first invokes original_insert_fixtures, then checks whether the model has any file_column attributes. If it does, the files defined in the fixtures will be created if they don't already exist.

EDIT: Running functional tests with rake test:functionals fails miserably even though running the tests individually is just fine.

2 Comments