Lately I've had the opportunity to use Jasmine to test drive a whole bunch of Javascript and am loving it. If you haven't had a chance to take Jasmine for a spin, I recommend you take some time to do so.
When I heard that Rails 3.1 was going to include CoffeeScript I decided to work to figure out how I could write both my production code as well as my specs in Coffeescript.
Interestings
"respond_to :not_fun"
When using
respond_to
in a controller in Rails 3, keep in mind that the body of the action will still happen before it doesn't find a
format
it is interested in and bails, possibly causing side effects of the action to still happen (like creating a record) but returning a 406 or other error to the client.
"Time.stub(:now) combined with waits"
Careful when stubbing
Time.now
when using, for example, steps in Cucumber that are "waiting" for things, as the clock will not move, and your tests will run until the end of time...
Rails 3 brings with it ActiveModel.
ActiveModel give you a way to make non-db backed models look like db backed models to your views and controllers. See this post for a good explanation of what using ActiveModel buys you.
ActiveModel gives you a great way to test that your class implements the minimum ActiveModel interface: ActiveModel::Lint::Tests
Check out this gist for the details for using these tests in RSpec:
If you haven't looked at OmniAuth for authentication with sites like Google, Github and Facebook, then you should take a look. It is pretty killer.
This morning we needed to write a Cucumber scenario to test that a user could log into the system using Google Apps.
We did a quick spike on getting OminAuth integrated, which was a super simple process, and poked around in the browser to make sure it was working OK.
Thanks to Jose Valim for providing some guidance, via the Devise test suite, on how to get this all up and running.
The basics can be found in this Gist:
I put that code in /features/support/omniauth.rb and then all I need to do is label any scenarios that need to deal with login with an @omniauth_test tag and we are all set.
As our features count grows, I could see us doing this before/after all Cucumber scenarios.
Note: You need to be using 0.2.0.beta5 of OmniAuth to get this to work. Earlier versions don't have the testing functionality built in.
Also Note: This same functionality can be used in good, old RSpec integration tests or Steak tests as well.
Sometimes your controllers get so full of before_filters, after_filters, and around_filters that it's hard to figure out what order these callbacks are actually executing in. A couple of times recently, I've run into some tricky bugs that ended up being related to callbacks running too soon or too late.
Due to some fancy-pants metaprogramming in AbstractController::Callbacks, it's hard to see what's going on.
In Rails 3, send this to Rails.logger.debug or puts from inside your controller to see the ordered filter callback chain:
_process_action_callbacks.map(&:filter)
A quick gotcha we ran into when using polymorphic path and rspec2 today.
In a controller test we had an assertion:
response.should redirect_to(polymorphic_path(@some_object))
Which resulted in the following error
Failure/Error: Unable to find matching line from backtrace stack level too deep
# ~/.rvm/gems/ruby-1.9.2-p0@gemset/gems/rspec-expectations-2.1.0/lib/rspec/matchers/method_missing.rb:4
It turns out polymorphic path is not available in the controller test (but the usual object_path method is). As to why this throws a stack level too deep and not a method undefined looks like potentially another bug in rspec but the solution seemed to be to do the following in our spec_helper.b for Rails 3:
include Rails.application.routes.url_helpers
For Rails 2.x you'll want to use:
include ActionController::UrlWriter
I've opened an issue for this on github as well https://github.com/rspec/rspec-expectations/issues/issue/46
Back in the day, plugins were an acceptable way to extend Rails because gems were hard to create and publish. It was easier to just put up a public repo and have people pull a plugin from there.
In Rails 3, I think that we've got a good solution to these problems. Bundler allows us to type bundle gem and quickly get the skeleton of a gem. Bundler also also allows us to easily pull in unpublished gems via the :git option from any public git repo. The new rubygems.org allows us to easily publish gems that are ready for prime time.
Yes plugin maintainers will need to take a little time to update their plugins to be gems but I think that time is outweighed by the benefits of less code in Rails (because the plugin architecture code will be removed), possibly increased startup time because less code is running and adhernace to a standard way of loading Ruby extensions via the gem mechanism.
What do people think?
A lot of hard work has gone into modularizing the Rails3 codebase to make it easier to work with and faster.
Do we continue the spring cleaning and get rid of other remnants from the past?
In the continued saga that is the Rails 2.3.10 to Rails 3.0.1 upgrade, I found this little nugget today...you want to add a custom action to a controller that inherits from a Devise controller. Here are the steps that you need to follow:
1) Create a custom controller that overrides some out of the box Devise actions as well as adds a new method.
class RegistrationsController < Devise::RegistrationsController
def update
# do something different here
end
def deactivate_owner
# deactivate code here
end
end
2) You have to tell Devise to use the new controller in routes.rb as well as add the new route to the new action.
devise_for :owners, :controllers => { :registrations => "registrations" } do
post "deactivate_owner", :to => "registrations#deactivate_owner", :as => "deactivate_owner_registration"
end
When we initially implemented this, our route definition looked like this:
post "deactivate_owner", :to => "registrations#deactivate_owner", :as => "deactivate_owner_registration"
devise_for :owners, :controllers => { :registrations => "registrations" }
When it was implemented this way, we kept getting a AbstractController::ActionNotFound exception. Once we passed the block to devise_for seen in #2, everything worked fine.
While helping client upgrade a Rails 2.3.10 site to Rails 3.0.1, I came across a very perplexing problem with our WebDriver based Cucumber tests that all worked fine under 2.3.10.
We were "randomly" getting some very strange errors from Cucumber having to do with timeout problems and other strangeness like Cucumber not being able to find form fields to fill in.
The solution: 1) require => false for the FakeWeb line in the Gemfile 2) add require 'fakeweb' to the top of the test_helper.rb file
or optionally scrap FakeWeb for either Artifice or WebMock
It has something to do with FakeWeb inserting it into the HTTP stack strangely even if you tell it to allow non-local HTTP requests. We weren't seeing it in 2.3.10 because we were using a cucumber environment to run the cucumber tests. Now under 3.0.1 we run the cucumber tests in the test environment.
I wish I had some more details but I was just happy to move past this strangeness so I didn't really look back.
In an effort to continue my contributions to the open source Ruby/Rails ecosystem, I decided to help the factory_girl_rails team move the Rails3 generators from the rails3-generators project into the factory_girl_rails project.
Like all good Ruby/Rails developers, they asked to make sure that I had tests written around the generators. I thought for a bit on how I was going to do this and then I wandered across the Cucumber feature files in the rspec-rails repo and found my answer.
Rspec-rails (and RSpec2 as well) uses a gem called Aruba to easily write Cucumber features around things that happen from the command line.
If you'd like to check out the result of using Cucumber and Aruba to test Rails3 generators, head over to my fork of the factory_girl_rails gem and check out the features/generators.feature file.
Hopefully the changes will be merged into the official factory_girl_rails repo soon and the generators will live closer to home.