Factory Girl defines a function “convert_human_hash_to_attribute_hash” to process the Gherkin table steps. This needs to be available to RSpec examples as Turnip creates them from your Gherkin scenarios. So start by creating a file “spec/support/factory_girl_step_helpers.rb” and add “config.include FactoryGirlStepHelpers” in your “RSpec.configure” block. The contents of the file are in this gist. I have not needed to modify this module from the one that in the default Factory Girl step definition file.

The step definitions themselves require more significant modification. Lets look at how they are defined for Cucumber:

Given /^an? #{human_name} exists$/i do
  FactoryGirl.create(factory.name)
end

The conversion of this one into a Turnip step is straightforward:

step "a(n) #{human_name} exists" do
  FactoryGirl.create(factory.name)
end

The steps that handle a table with both the pluralized and singular versions is more complicated. The Cucumber step definition is:

Given /^the following (?:#{human_name}|#{human_name.pluralize}) exists?:?$/i do |table|
  table.hashes.each do |human_hash|
    attributes = convert_human_hash_to_attribute_hash(human_hash, factory.associations)
    FactoryGirl.create(factory.name, attributes)
  end
end

Initially I tried to use Turnip’s ability to figure out “is/are” and “exist(s)” which looked like:

step "the following #{human_name}/#{human_name.pluralize} exist(s):" do |table|
  table.hashes.each do |human_hash|
    attributes = convert_human_hash_to_attribute_hash(human_hash, factory.associations)
    FactoryGirl.create(factory.name, attributes)
  end
end

This didn’t work, it caused the table that was passed to the block to not be correct.
The only solution was to create 2 different step definitions, one for pluralized form and one for the singular form.

The final file that creates the step definitions for every defined factory is listed in this gist.
Simply place this file in “spec/acceptance/steps”

Now you can easily use steps like:

  Given 20 things exist
  Given the following things exist:
    | name  |
    | Ruby  |
    | Rails |
    | Blog  |

Now enjoy easily setting up your test database using your factories from within your Turnip feature files!

The post Adding Factory Girl steps to Turnip appeared first on Web Development Advice and Tips.

Let me tell you why I still think you should write controller tests:

• They are very easy to write
• They are mostly the same
• Because they are mostly the same, we can refactor and make them even easier to write

We all refactor our code, but it’s just as important to refactor our tests. The goal of refactoring is to facilitate reuse and increase clarity. Refactoring let’s us develop new abstractions upon which we can build complex logic. Our controllers are so lean and mean because they are benefitting from a very convenient abstraction: RESTful web services.

Chances are most of the controllers in your app have a lot of shared behaviors. They find, create, and update your models, set flash messages, redirect or render templates, and set status codes. Let’s take advantage of the shared behaviors to refactor our tests.

Put the following file into spec/support/controller_helpers.rb

module ControllerHelpers
  extend ActiveSupport::Concern

  module ClassMethods
    def self.define_action(action)
      define_method action do |*args, &block|
        options = args.extract_options!
        options[:http_method] = action
        options[:controller_method] = args[0]
        args[0] = [action.to_s.upcase, "#" + options[:controller_method].to_s].join(" ")
        args << options
        context(*args, &block)
      end
    end

    define_action :get
    define_action :post
    define_action :put
    define_action :delete
    define_action :head
    define_action :options

    def it_should_flash(type, message)
      it "should set the flash" do
        do_request
        flash[type].should eq(message)
      end
    end

    def it_should_redirect_to(&block)
      it "should redirect" do
        url = instance_eval(&block)
        do_request
        response.should redirect_to(url)
      end
    end

    def it_should_render_template(template)
      it "should render the #{template} template" do
        do_request
        response.should render_template(template)
      end
    end
  end

  def do_request
    params = if respond_to?(:params) then send(:params) else nil end # of story
    send(example.metadata[:http_method], example.metadata[:controller_method], params)
  end
end

RSpec.configure do |config|
  config.include ControllerHelpers, :type => :controller
end

Now we can write our controller specs easily. For example:

require "spec_helper"

describe FoosController do
  get :new do
    it_should_render_template :new
  end

  post :create do
    let(:params) { "foo" => { "bar" => "baz" } }
    let(:foo) { stub }

    before { Foo.stub!(:new).with("bar" => "baz").and_return(foo) }

    context "successful create" do
      before { foo.stub!(:save).and_return(true) }

      it_should_set_flash :success, "Created foo."
      it_should_redirect_to { foos_url }
    end

    context "failed create" do
      before { foo.stub!(:save).and_return(false) }

      it_should_render_template :new
    end
  end
end

Enjoy!

The post Using RSpec Macros and Metadata appeared first on Web Development Advice and Tips.

Testing the Index

This one is super simple. It’s just minitest and capybara:

  test "See the index" do
    visit root_path
    assert_see "Blog Posts"
  end

You’ll notice I threw in “assert_see”. It’s a simple method that wraps some capybara code:

  def assert_see(content)
    assert(page.has_content?(content), "Expected page to contain \"#{content}\", but it didn't")
  end

Testing Create

Now we’re getting into some real data business. These were my goals:

1. Delegate filling in the form to a reusable helper
2. Make the assertion in helper
3. Deal with models like models, not like attribute hashes

Here is my test code:

  test "Create a new post" do
    BlogPilot do
      create(
        Blog.new(:title => 'a blog title', :body => 'a blog body')
      )
    end
  end

I delegating filling out the form to BlogPilot#create_blog. I also did it by passing in a blog object to be created. You’ll note there are no assertions. This was a personal choice. I wanted to write out my steps such that they are assumed to succeed. Any step that fails will fail the test.

So, what’s with this pilot business? Let’s check it out:

class BlogPilot < TestPilot::Core
  def create(blog)
    visit root_path
    fill_in "Title", :with => blog.title
    fill_in "Body", :with => blog.body
    click_button 'Create Post'
    assert_on root_path
    assert_see blog.title
    assert_see blog.body
  end
end

That’s pretty straightforward! It’s just a capybara helper. You’ll note the step makes assertions. The only way the test can proceed is if this step passes. That way, we’ve also abstracted the notion of “successfully creating a blog” to a single place. So if we switch between divs, tables, and lists to display our blog, we only change our expectations here.

So what’s this TestPilot::Core business? There are two reasons I had to make TestPilot:

1. I didn’t want tons of flat helpers (i.e. create_blog, create_comment, create_user)
2. I didn’t want to have to instantiate the pilot and keep calling it. I wanted “BlogPilot do … end”

TestPilot

Two things should be going through your head right now:

1. Wait a minute, he said more simple! How is introducing some new framework going to make this simpler?
2. HOW DO I GET THE GOODNESS IN ME

Luckily, the answer to both questions is the same. This is test pilot:

module TestPilot
  class Core < ActionDispatch::IntegrationTest
    def initialize ; end # override new from inherited class
    def self.inherited(subclass)
      TestPilot::Dsl.send(:define_method, subclass.to_s) do |&block|
        subclass.new.instance_eval(&block)
      end
    end
  end
  module Dsl ; end
end

It’s not a gem. It barely deserves to be in lib. This could go right in your test_helper.rb. What’s going to break? There are two lines of real code in there. And if it breaks, guess what? It’s right there in test_helper, not in some gem you have to maintain your own fork of so you can have “Nick’s raspberry flavored test::pilot”.

Where am I going?

So what was my goal with this? My goal is to write code like this all day:

test "a logged in user can comment on another user's post" do
  joe = Factory :user
  bob = Factory :user
  UserPilot do
    log_in joe
  end
  PostPilot do
    @post = create(Factory.build(:post))
  end
  UserPilot do
    log_out
    log_in bob
  end     
  CommentPilot do
    create(@post, Factory.build(:comment))
  end     
end

Notice I left out any assertions. I think it would be cool to have the pilot steps themselves assert a successful action, since you probably want to check for it every time anyways.

I enjoy that this gives me one of my favorite benefits of cucumber: reusable steps. But, I can carry around instance variables in a highly visible manner, and call specialized factories without creating a one-off step that obfuscates my codebase.

So what do you think? Would you rather code cucumber, rspec, raw test unit, test pilot? Or have I inspired you to roll your own?

Code: test-pilot-demo.

The post TestPilot – Rails Integration Testing Pattern appeared first on Web Development Advice and Tips.

So, I figured with a little capybara and a little therubyracer, I could test my javascript with real route calls. Let’s check it out.

The Javascript I want to test:

var dataObject = {};
var getRemoteData = function() {
  $.getJSON('/remote_path.json', function(data) {
    dataObject = $.parseJSON(data);
  });
}

We will pretend that hitting /remote_path.json returns the following response in JSON:

{ "my_information": "my response data" }

I want to test:

1. That /remote_path.json is accessible and returns information
2. That dataObject is populated with a Javascript Object containing the params I pass down

Here is my commented testing code:

  test 'get some information via ajax' do
    # Create a new JS Context. :with => self means that
    # the global namespace is the current context
    js = V8::Context.new(:with => self)

    # Load up our JS file
    js.load(File.join(Rails.root, 'public', 'javascripts', 'application.js'))

    # Define a mock method for getting JSON data
    def getJSON(url, callback)
      # When the JS wants some data, get it for real w/ capybara
      visit url
      # And call the JS function passed in (ruby => js)
      callback.call(page.body)
    end

    js.eval %{
      /* Mock out jQuery */
      var $ = {};

      /* Setup the mock in the right place (JS => ruby) */
      $.getJSON = getJSON; 

      /* Mock out jquery parseJSON to call ruby JSON.parse
         Since the args are the same, it is plug and play!
         (JS => ruby) */
      $.parseJSON = JSON.parse;

      /* Trigger our JS */
      getRemoteData();

      /* Assert what we expect (JS => ruby) */
      assert_equal(" ", dataObject.access_key);
    }
  end

This is not an example of an incredibly useful test, but I found the ability to bind back and forth easily between ruby and javascript to be mind-blowingly incredible. I mean, look at that last line, where I call assert and pass a javascript object to it!

Huge thanks to Charles Lowell (cowboyd) for his hard work on therubyracer.

Enjoy the weekend!

The post Testing AJAX with Test::Unit appeared first on Web Development Advice and Tips.

Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.

Documentation is hosted at RubyForge. The source code is hosted at GitHub.

Updates include:

Maintenance

• Fix various timezone-related issues. Notably, when traveling to a DateTime
  instance specified in a non-local timezone, convert provided DateTime
  instance to a local instance and return that from DateTime.now.
  Code contributed by Michaël Witrant [piglop]
• Fix bug that would not allow Timecop to be used when Ruby’s ‘date’
  library had not been previously loaded.
  Code contributed by Tuomas Kareinen [tuomas]
• Fix bug when traveling to a DateTime across a DST boundary that
  resulted in DateTime’s being off by an hour.
• Migrate argument parsing into Timecop::TimeStackItem to reduce the
  responsibility of the Timecop class.

The post Timecop 0.3.4 Released appeared first on Web Development Advice and Tips.

Timecop is a RubyGem providing “time travel” and “time freezing” capabilities, making it dead simple to test time-dependent code. It provides a unified method to mock Time.now, Date.today, and DateTime.now in a single call.

Documentation is on RubyForge. The source code is hosted at GitHub.

Updates include:

API

• Completely remove Timecop#unset_all (deprecated by Timecop#return in 0.2.0)
• Return Time.now from #freeze, #travel and #return — code contributed by Keith Bennett (keithrbennett)

Maintenance

• Fix bug that left Time#mock_time set in some instances
• Upped build dependency to jeweler ~> 1.2.1
• Don’t pollute top-level namespace with classes/constants

Documentation

• Clearer examples in the README, better description in the gemspec
• Improve RDoc

The post Timecop 0.3.0 Released appeared first on Web Development Advice and Tips.

I wanted to preview my HTML emails without having to fill up my online email inboxes with tons of email (and then I’d have to make filters too). I also didn’t want to manage actually sending real email. So, I set up my machine for local delivery. Read on for instructions.

I am running Ubuntu 9.04, however these instructions should be fine at least back to 8.04.

Step 1 – Install Postfix

sudo aptitude install postfix

During the install, choose “Local Delivery Only”

Step 2 – Configure Evolution for Receiving Locally

Open up Evolution “Applications->Internet->Evolution Mail”

Set up a new account and choose local delivery. When it asks you for a path, put in:

/var/mail/<username>

Note that this path may not exist if you’ve never received mail.

Step 3 – Configure Sanitize Email

In your rails test environment.rb put:

config.action_mailer.delivery_method = :sendmail

Then, in the initializer where you set up sanitize email:

ActionMailer::Base.sanitized_recipients = ["@"]
ActionMailer::Base.local_environments = %w( test )

If you need to know your username or hostname, just open up a terminal. The command “whoami” will give you your username, and “hostname” will give you the hostname.

Step 4 – Run your tests

Now, run your rails tests. You should have a test for every email you send, and that should trigger them to be sent locally. You may have to tell Evolution to Send/Receive. Keep in mind your tests will probably fail because they will expect email to be in test mode.

Step 5 – Set it back

Remember, when you’re done previewing your email, reset config.action_mailer.delivery_method!

The post Using Sanitize Email to Preview HTML Emails Locally appeared first on Web Development Advice and Tips.

So what about rails applications? Often, test data only contains a small amount of data. Over time more users use the site and generate more data. A page that usually renders in 100ms could be taking 3-5 seconds, or more!

I present, SlowActions. The goal was to analyze a standard log file to detect actions that render slowly. It had to be easy to use and also not require modification of rails’ logging mechanism. Observe:

  $> slow-actions --actions development.log
             Cost    Average Max
  - UsersController : game_history (22 entries, 0% Error)
    Total:   11275.447 3642.437 12728.0
    Render:  7.20300 2.32700 17.2450
    DB:      10.5020 3.39200 10.0000

  - QuestionsController : refresh_index_table (89 entries, 0% Error)
    Total:   908.494 202.348 307.000
    Render:  0.00000 0.00000 0.00000
    DB:      32.5880 7.25800 10.0000

More info after the break ….

So, what are we looking at? These are the top two (because I cut off the rest) results for looking at all the log entries times sorted by their Cost. The first line is the Controller followed by the Action. In parenthesis is the number of entries in the log file and the percent of those entries that had an error.

The second line is the total time from request to the data being sent to the user. There is a column for Cost, Avg, and Max. Max is the maximum time this action ever took. Avg is the average amount of time the action took (not counting errors). Cost = Avg * Math.Log(# entries).

The Cost can be thought of as that action’s share of the slowness of the site. An action that is only run once a month and takes 5 seconds is not as bad as an action run 200 times per day that takes 1 second. The Log helps smooth things out a bit.

There are a bunch of filters that you can put on the command:

$> slow-actions (--actions | --controllers | --sessions) log_file [log_file ...]
    You may also specify:
      --min-cost=FLOAT
      --min-avg=FLOAT
      --min-max=FLOAT
      --start-date=YYYY-MM-DD
      --end-date=YYYY-MM-DD

You can choose to output the actions and/or controllers (in a tree format) and/or the session ids (to see which users have it the worst, this is great to find out what is causing a slow action). You can also specify multiple log files, in case you rotate your logs.

You can choose a cutoff cost/avg/max, which means that you could make nice short little emails to yourself every night from your app.

You can also specify a date range, because after you fix a bug, you want to see what kind of effect it had.

I took care to put in some basic RDoc to help people use slow-actions in their own tests or tasks. For example, you could run this in irb:

require 'rubygems'
require 'slow_actions'
@sa = SlowActions.new
@sa.parse_file('/path/to/my/log')
puts @sa.print_actions

Have I convinced you? Then get SlowActions off GitHub and download it and run it on your app, you’ll be surprised!

The post Slow Actions in Rails Projects appeared first on Web Development Advice and Tips.

As a Ruby programmer, I’ve come to love test-driven programming. As such, I’ve made an effort recently to build a test-based workflow into this existing codebase (not always the easiest thing to do, applying a test-base to a large existing codebase). Today I found myself in dire need of being able to test private functions in C++. As a testament to the poor state of testing in other programming languages, many message boards/threads simply told me that I was testing the wrong thing (you should test the public API, not the private implementation). Well, needless to say, this left me a bit uncomfortable. The fact is, the majority of my code is tucked into private methods, and I’d be left with huge long-running end-to-end tests if I strictly followed this heuristic.

However, I came across one golden nugget, one of the most clever hacks I’ve seen in some time. By utilizing pre-processor directives, we can temporarily override the meaning of private and protected in C++ code, essentially aliasing it to public.

 #define protected public
 #define private   public
 #include "TheClassHeaderUnderTest.h"
 #undef protected
 #undef private

See what this is doing? We wrap the class that we’ll be testing in pre-processor directives to interpret protected and private as an alias for public, essentially loading that class (when including the header file) as entirely public. This allows me to access everything! Private methods, private variables, you name it. And now, just like in Ruby, it’s no holds barred, allowing me to poke and prod my objects without being wrapped on the wrist by the compiler.

Even better, these directives simply wrap your includes in your test files. In other words, I don’t have to change my implementation to achieve this.

A clever hack, no matter the language or technology, is a clever hack. And I absolutely love this hack.

Credit: I discovered this technique as a comment on this wiki.

The post TATFT: Test Private Methods in C++ appeared first on Web Development Advice and Tips.

Expected response to be a <:redirect>, but was <500>
<"No HTTP_REFERER was set in the request to this action, so
redirect_to :back could not be called successfully. If this
is a test, make sure to specify
request.env[\"HTTP_REFERER\"].">

What a lovely error message to send me on a goose chase trying to set HTTP_REFERER directly on the @request as instructed.

Did Not Work

@request.env["HTTP_REFERER"] = '/'
post upload_path, { :file => fixture_file_upload("worddoc.docx", "application/msword") },
  { :html => {:multipart => true} }
assert_redirected_to '/', 'index'

This continued to spit out the same error. I finally stumbled across a post back from 2006 that held the answer. The HTTP_REFERER is not set the same way in an integration test:

Success!

post upload_path, { :file => fixture_file_upload("worddoc.docx", "application/msword") },
  { :html => {:multipart => true}, :referer => '/' }
assert_redirected_to '/', 'index'

Hope that saves anyone else some time if you encounter this error.

The post Properly Setting HTTP_REFERER in a Rails Integration Test for a File Upload appeared first on Web Development Advice and Tips.