Testing ActiveSupport concern modules

Using modules to share code between classes in Ruby is a commonly used method to add re-usable behaviour without blocking the inheritance chain, the Rails ActiveSupport::Concern adds some convenience methods to do so. What (at least in my opinion) should not be forgotten is to test the usage of such modules on your classes, this can actually be achieved fairly easily creating a module with test code that you can then again include in your tests.

Take this very contrived example module which adds an instance method to the classes it is included in:

module ReverseName  
  def reversed_name 
    name.reverse    
  end               
end                 

It’s function could be tested with the following test:

test 'reverse name' do                             
  assert_equal 'htimS nhoJ', @name_reversable.reversed_name 
end                                                

This can be poured into a module using ActiveSupport::Concern that can be included in test cases of other classes like so:

module Concerns                                          
  module ReverseNameTest                                 
    include ActiveSupport::Concern                       
                                                         
    included do                                          
      test 'reverse name' do                             
        assert_equal 'htimS nhoJ', @name_reversable.reversed_name 
      end                                                
    end                                                  
  end                                                    
end                                                      

In Rails projects I usually put shared test code inside the directory test/test_helpers, to have these loaded when running tests you will have to add the following line to your test_helper.rb:

Dir[Rails.root.join('test/test_helpers/**/*.rb')].sort
                                                 .each { |file| require file }

To now use this test module on a class that can make use of it we can include the test module in that model’s test like so:

require 'test_helper'                                             
                                                                  
class ContactTest < ActiveSupport::TestCase                       
  include Concerns::ReverseNameTest                               
                                                                  
  setup do                                                        
    @name_reversable = Contact.new(first_name: 'John', last_name: 'Smith') 
  end                                                             
                                                                  
  test 'name' do                                                  
    contact = Contact.new(first_name: 'John', last_name: 'Smith') 
    assert_equal 'John Smith', contact.name                       
  end                                                             
end                                                               

If you want to verify that the test gets executed for your model you can purposely break the test(s) to see them fail like shown below:

Running ActiveJobs inline temporarily

Pushing execution of code that take a long time to complete to ActiveJob can be great to increase the (feeling of) responsiveness for any Rails application. Sometimes it can be desirable to run triggered jobs inline instead though (in certain rake tasks for example), you can do this by overriding the queue adapter with the inline adapter like so:

ActiveJob::Base.queue_adapter = ActiveJob::QueueAdapters::InlineAdapter.new

If you want to ensure that the adapter is switched back to its original setting after you are done (because more code is executed around the part where you want to run the jobs inline) you can that using ensure like in the below example rake task:

desc 'My rake task'
task my_task: :environment do
  old_queue_adapter = ActiveJob::Base.queue_adapter
  ActiveJob::Base.queue_adapter = ActiveJob::QueueAdapters::InlineAdapter.new
  # your code here
ensure
  ActiveJob::Base.queue_adapter = old_queue_adapter
end

Note that if you are using different queueing backends for specific jobs (as documented in the Rails guide here) you would have to override each one of those too in the same way (if you would want to run those inline that is).

Vim tip: excluding files and paths from searches with Grepper

Grepper is a plugin for Vim to search your project asynchronously using your preferred search tool. By default Grepper will search Vim’s current directory and its subdirectories, in many projects that I work on this includes things I generally do not want to search in (with directories container vendor libraries such as node_modules).

You can pass extra options for the tool of your choice to the Grepper commands, ripgrep (which is what I use) supports a glob argument which you can use to exclude paths (and files) like so:

:GrepperRg --glob '!vendor' --glob '!node_modules' --glob '!public' --glob '!test/vcr_cassettes' 'Hello Word'

To prevent yourself from typing a ton of globs each time you want to search you can add a command to your vimrc for common combinations like so:

command! -nargs=+ -complete=file Search :GrepperRg --glob '!vendor' --glob '!node_modules' --glob '!public' --glob '!doc'

The above snippet adds a Search command to vim which excludes paths I generally do not want to search within in Rails projects which you can use like so:

:Search 'Hello World'

Rails: ActiveRecord descendants in development mode

Single table inheritance (often referenced to as STI) is a feature offered by Rails’s ActiveRecord (which is documented here) that allows you to subclass models to store data for multiple similar models in one database table. This can be a very useful feature under the right circumstances.

When working with Rails in development mode classes are not preloaded (unlike is done in production mode). If you use the descendants method to get a list of the subtypes of your model (to for example display them or to populate a select box) it is possible that sometimes an empty or partial list is returned rather than a list of all the defined subtypes (unless you have actually used one of them so far).

If you are working in a team this can be an especially devious little problem that can linger for a long time. Different developers may have different sets of data in their development system. Loading a list of STI models will load the subtype classes making them available in the application from that point on. If the database however does not contain records for the subtype’s class and you are not directly referencing it you will not see it. This can then result in one developer experiencing issues while the another does not.

In this article I will demonstrate the issue and offer a solution that you can implement.

Continue reading “Rails: ActiveRecord descendants in development mode”

Prepend to an existing rake task

Rake is a commonly used tool in Ruby projects to provide command line tasks, Rails comes with a number of rake tasks included for example. It is quite well documented how to write rake tasks, a while ago however I needed to prepend something to an existing rake task. One way to achieve this is to write a new rake task that executes the code that you want to execute and then calls the existing rake task. The (perhaps obvious) downside to this method is that you have to execute another rake task than you usually would.

It turns out that there is another way, you can use the enhance method on an existing rake task. In this article I will briefly explore how you can use this method.

Continue reading “Prepend to an existing rake task”

Splitting commits using git rebase

We have all been there before: you’re working on a big feature branch, committing all over the place and then at some point you need to extract something out to merge it back to the main (or develop) branch. My usual to method is to split off a new branch and then use git rebase to keep only the commits of the parts that I want to extract out and merge that back after which I then rebase my feature branch on the target branch again.

But what if you find that some commit halfway through the changeset needs to be split up? That’s what I will be diving into in this article.

Continue reading “Splitting commits using git rebase”

Using bundler inline

A little while ago someone showed me a pretty cool feature of Bundler that I didn’t know about: you can use it inline in a Ruby script without having to create a separate Gemfile. This is very convenient for writing little utility scripts.

To use bundler this way you start with a require bundler/inline followed by a gemfile block that contains the content that you would have put in the Gemfile if you would have had to create one. When you then execute the script with Ruby Bundler will first install the required gems (if needed) before executing your code.

Here’s an example that uses the HTTPClient gem to check your external IP address (using the same endpoint I made for my article on obtaining your external IP address from the command-line):

require 'bundler/inline'

gemfile do
  source 'https://rubygems.org'
  gem 'httpclient'
end

client = HTTPClient.new
puts client.get('https://ip.5ec.nl').body

If you execute this script for the first time it will pause a moment to install the HTTPClient gem, the next time you execute it will work without delay.

This and other features of Bundler are well documented on the official Bundler documentation pages, it’s well worth having a look around there.

If you have feedback on this article or have questions based on its contents then feel free to reach out to me on Twitter or through e-mail.

Capybara with Selenium and Vagrant (without Rails)

Once upon a time I wrote a blog post about using Capybara with Selenium and Vagrant (which you can still find on the previous incarnation of my blog here) … things have changed a bit since then however: it got easier to run headless browser tests for example (no longer requiring an Xvfb setup) and nowadays Rails even ships with Capybara by default for its systems tests taking away a lot of the complexity of setting it up for developers using the framework.

Capybara with Selenium is still an amazingly good combination for automated testing of web applications in a real browser, so in this article I will revisit running automated browser tests with it on a Vagrant box with the same perhaps somewhat unimaginative little Sinatara application as I did back in 2012.

Continue reading “Capybara with Selenium and Vagrant (without Rails)”

Using OpenSSL to verify downloads

Hashes are commonly offered by download pages for you to verify the integrity of your downloaded files. I typically verify these hashes using OpenSSL which supports many types of hashing algorithms and is available on many unix-like systems (and can often be installed on them easily enough if it is not yet present).

The basic method for verification works as follows: after downloading a file enter the command openssl {hashalgorithm} {/path/to/downloaded.file} to calculate a hash based on the file’s contents. If the hash shown matches the hash on the download page the file is as intended.

Continue reading “Using OpenSSL to verify downloads”

Committing parts of your changes via the git command-line interface

If you have ever used made extensive use of GUI interfaces for git you may have come across the ability to stage and commit only parts of your changes to files rather than committing everything that you changed in said files at once. Recently I learned that the command-line interface to git supports the same feature using the -p flag when staging or even committing files which is what I briefly want to go through in this article.

Continue reading “Committing parts of your changes via the git command-line interface”