Stubbing Global Methods in JS Specs with Sinon

In your Rails app, your JS should be tested too! Setting that up is a topic for another post. When testing your JS, a lot of the same philosophies apply. One of those is mocking methods other than the one you're testing. How do you do this for methods in other libraries, such as vanilla JS or jQuery?

Vanilla JS (the confirm method):

 sinon.stub(window, 'confirm')  

jQuery (the fadeOut method):

 sinon.stub(jQuery.prototype, 'fadeOut')  

Cleaning out server assets in development

Depending on your server settings (config/environments/development.rb), some of your assets (css, js, images, etc.) may end up being cached by the server and won't reflect your changes. Fortunately, there is a command to clear all of these out so they will be regenerated. With the server shut down, run rake assets:clobber and all of your asset caches will be removed. The next time you run the server and navigate to your app, the assets will be regenerated with the current version of the files.

Using self.included to Include Dependencies

As part of a project I'm working on, I created a mountable engine for extracting all authentication concerns for the app. I created a TestHelper module that includes methods for mocking various aspects required for authentication. These methods require Devise::TestHelpers to function properly, and my goal was for the calling app to not know or care about this dependency. To solve this, I used self.included to automatically include the helper when necessary (in my case, only in controller specs).
Here is the code:

 def self.included(receiver)  
  if defined?(receiver.metadata) && receiver.metadata[:type] == :controller  
   receiver.send :include, Devise::TestHelpers  
  end  
 end  

Testing Multiple Attributes of an Input Field

Sometimes in a view or feature spec, you want to test multiple attributes of an input field (or some other field). For example, you might want to test that the input field is a checkbox and is checked, as well as testing that the field has the id #rawr. This is how you would do that in a view spec (feature spec is similar):

 expect(content).to have_css("input[type='checkbox'][checked='checked']#rawr")  

Updating a Rails Model with a Non-default Primary Key

In my last post, I talked about creating a Rails model with a non-default primary key. You can create new instances of the model with no problem, but what happens when you want to update an instance of the model?

 TypeError: nil is not a symbol nor a string  

Oh no!!!!

Fortunately, there is an easy fix. You just have to specify the column name of the primary key from within the model.

 class BearHabitat < ActiveRecord::Base  
   self.primary_key = 'bear_id'  
 end  

Now you should be able to update your model within your code with no problem. Why does this happen in the first place? My guess is that somewhere within ActiveModel, it assumes that the primary_key field is set. Since your migration set id to false, this value gets defaulted to nil. If you don't manually set it, ActiveModel gets sad. Now you can make ActiveModel happy again.

Creating a Rails Model with a Non-default Primary Key

One of the main Rails philosophies is "convention over configuration". This works great most of the time, but sometimes it's best to do something outside of convention. One example is the primary key for models. Sometimes you want the key to be something other than ID; maybe you want it to be the ID of a related model.

This is possible to set up in a migration, you just need to do a few important things:

• Set id: false on the create_table line
• Set your new primary key to null: false
• Add a unique index on your new primary key

Here is an example:

 class CreateBearHabitats < ActiveRecord::Migration  
   def change  
     create_table :bear_habitats, id: false do |t|  // prevents a default ID column from being created
       t.belongs_to :bear, null: false //creates a bear_id column that can not be null
       t.string :habitat  
     end  

     add_index :bear_habitats, :bear_id, unique: true // ensures that the bear_id column is unique
   end  
 end  

This BearHabitat model will now use bear_id as a primary key instead of the standard id.

Testing Controllers in Rails Engines

Testing your controllers in a Rails engine requires just a few extra steps compared to testing in a Rails application.

For example, you're working on an engine called Animals, and you have a BearsController with an index action that returns all the bears you've registered.

With a controller like this:

 // app/controllers/animals/bears_controller.rb  
 module Animals  
   class BearsController < ApplicationController  
     def index  
       // return all bears  
     end  
   end  
 end  

and a routes file like this:

 // config/routes.rb  
 Animals::Engine.routes.draw do  
   get '/index' => 'bears#index'  
 end  

you will need to update your dummy routes file to look like this:

 // spec/dummy/config/routes.rb  
 Rails.application.routes.draw do  
   mount Animals::Engine => "/animals"  
 end  

and in your controller spec you will need to add one extra line compared to normal:

 // spec/controllers/animals/bears_controller_spec.rb  
 RSpec.describe BearsController do  
   // this is the key line!  
   routes { Animals::Engine.routes }
  
   describe 'GET :index' do  
     it 'does the thing' do  
       get :index
       // test that all bears are returned  
     end  
   end  
 end  

and now your controller test will go to the appropriate routes :)