Writing tests: RSpec's reason for Lambda

Most of my tests have been using the standard test format:

it "should add the thing to the db" do
  post :message, :content => "yadda yadda", :id => @user.user_id
  response.should change(Message, count).by(1)
end

However I'm now learning about Lambda's, which there have been some great posts recently about (i.e. Blocks v Procs v Lambdas). Lambda's themselves are a mathematical convention for improving readability of a formula. In the case of RSpec, Lambda's allow me to test the function, and not the response, for a change in my database.

My previous example actually says that the response would be the reason that the count changed. But if I have an empty db, or want to display data in my db temporarily to demonstrate that the function is correct, I can use a Lambda to my benefit. It essentially wraps my code in the before/after, so I can just do the following:

it "should add the thing to the db" do
  lambda do
    post :message, :content => "yadda yadda", :id => @user.user_id
  end.should change(Message, count).by(1)
end

Overall, the 2nd version is checking that I created a Message based on the action inside the Lambda, versus the 1st version is looking at the response to change the action.

Rails default JS files in application.html.erb to avoid defaults.js 404 error

Although Rails cannot let you post a DELETE action, it can pretend to do so with javascript. JQuery is the default js lib of choice for what I've studied so far, and in this post, a simple change in the application.html.erb allows my js file to be called correctly.

My Gemfile does have:
gem 'jquery-rails'

I tried updating my application.rb with a config.action_view.javascript_expansions[:defaults] = %w(jquery rails), but that caused Zeus to puke. No good :(

Instead, I made a slight change to my application.html.erb and was able to now magically have JS destroy for me (WIN!).

<%= javascript_include_tag "application %>

did the trick!

Rails 4.0.0, local CI with RSpec, Zeus, and Guard, using PostgreSQL, deployed to Heroku

This post is an initial rambling about what I've been doing on some side projects. Aside from learning about Sinatra, and remembering my SQL-fu commands, I'm getting well acclimated to Heroku, re-enjoying Git, and having a blast working around concepts in RoR.

This is just a mini post about my experience with Hartl's exercises, but using Ruby 1.9.3-p194, rvm, Rails 4.0.0 to build the micro-post blogging engine.

Really, in summation, there were a few tricks that made this experience more painful than necessary.

I should also mention that due to other client work, I'm now on Xcode5 DP3. This is only relevant for the time being. Once iOS7 is out of beta and Xcode5 is RC, then maybe the command line tools will work better. For now, the nokogiri gem refused to install, and that's because the libxml2 and libxlts gems refused to install because something in the gcc from Xcode5 DP3 did not like playing well. That said, I could not run capybara or webrat to utilize have_selector("attribute", "value") in any of my rspec's. It was rather unfortunate, but kept me on my toes.

Basically, my gemfile (after the jump), has a couple of gems commented out b/c of the aforementioned Xcode differences. I did not use webrat (or capybara) or annotate-models. I did use PostgreSQL, which I found easier to manipulate, and though it required some config changes, allowed me to deploy to Heroku with no problems. Because of Heroku, and resetting the db, I had to put the faker gem in the normal list, and not development, b/c Heroku tried to use Faker for resetting the db :(

The one gem I did not anticipate ever having to add was the protected_attributes. Rails 4 removed the mass assignment of attributes for security, and there is plenty of good reason for it (just google 'rails protected_attributes, or 'rails 4 attr_accessible'). To follow Hartl's Rails 3 example in Rails 4, I used the protected_attributes and devise gems.

source 'https://rubygems.org'

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.0.0'

# Faker for dev and heroku
gem 'faker'

# Strong protection
gem 'protected_attributes'
gem 'devise', '3.0.0.rc'

# gravatars
gem 'gravatar_image_tag'

# Pagination
gem 'will_paginate'

# Use postgres as the database for Active Record
gem 'pg'

# Use SCSS for stylesheets
gem 'sass-rails', '~> 4.0.0'

# Use Uglifier as compressor for JavaScript assets
gem 'uglifier', '>= 1.3.0'

# Use CoffeeScript for .js.coffee assets and views
gem 'coffee-rails', '~> 4.0.0'

# See https://github.com/sstephenson/execjs#readme for more supported runtimes
# gem 'therubyracer', platforms: :ruby

# Use jquery as the JavaScript library
gem 'jquery-rails'

# Turbolinks makes following links in your web application faster. Read more: https://github.com/rails/turbolinks
gem 'turbolinks'

# Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder
gem 'jbuilder', '~> 1.2'

group :doc do
  # bundle exec rake doc:rails generates the API under doc/api.
  gem 'sdoc', require: false
end

# Use ActiveModel has_secure_password
# gem 'bcrypt-ruby', '~> 3.0.0'

# Use unicorn as the app server
# gem 'unicorn'

# Use Capistrano for deployment

group :development do
  gem 'rspec-rails'
  gem 'guard'
  gem 'guard-rspec'
  gem 'zeus'
  gem 'factory_girl_rails'
  #gem 'annotate-models'
  #gem 'webrat'
end

group :test do
  gem 'rspec'
  gem 'zeus'
  gem 'factory_girl_rails'
  #gem 'webrat'
end
# gem 'capistrano', group: :development

# Use debugger
# gem 'debugger', group: [:development, :test]