Simone Carletti's Blog » activerecord

The Road to Rails 3: make your Rails 2.3 project more Rails 3 oriented

Simone Carletti — Mon, 26 Jul 2010 14:12:21 +0000

Update 2010-08-10: added ActiveRecord::Base#add_to_base section

With the first Rails 3 Release Candidate available in a few days and the final version just around the corner, it’s time to start thinking in The Rails 3 way. Many developers, including myself, already started to work with Rails 3 and many others are tracking the changes, waiting for the right time to upgrade their Rails 2 applications.

There are already thousands of articles talking about the most cool Rails 3 features so I will skip that part in this article. After all, I already introduced a couple of Rails 3 libraries. I’d like this article to be something different, embracing a more practical style.

I have been working with Rails 3 since the first beta version and all my Rails applications, except one, are now running Rails 3 with Ruby 1.8.7 or Ruby 1.9.2. Trust me, upgrading an application to Rails 3 can be a real hassle if you don’t follow the right way, especially for complex applications.

The goal of this article is to feature a list of tips and changes you can already introduce in your Rails 2 application to anticipate the migration and make your code more compatible with Rails 3. The more steps you follow, the less problems you are likely to encounter when upgrading the codebase to Rails 3.

Kudos to this StackOverflow question for inspiring me this post.

Upgrading to Rails 3 screencast

Looking for a Rails 3 screencast? This one hour screencast is a live example of upgrading a real-world application from Rails 2 to Rails 3.

Prerequisites

This section includes some highly recommended prerequisites your application and environment should meet if you want to take the way to Rails 3. If you care about your happiness, don’t try to upgrade to Rails 3 unless all the prerequisites are satisfied.

Tests

I will repeat it until the end of the world: don’t try to work with Ruby or Rails without using unit, functional and integration tests. You have several different choices: Test::Unit, Shoulda, Cucumber, RSpec… pick one and create your test suites as long as you add features or fix bugs.

Don’t try to upgrade to Rails 3 unless you have a reasonable code coverage. And this is not because tests are cool or make you feel cool, but because Rails 3 changes so many aspects of your Rails application that upgrading without using your tests will be really painful.

Also, be sure to test your view helpers. Rails 3 adds string escaping by default and many of your Rails helpers might require a fix.

Ruby 1.8.7 or 1.9.2

Rails 3 no longer works with Ruby 1.8.6. You might also want interested to know that Ruby 1.9.1 is not officially supported and Ruby 1.9.2 is the first (and the only) choice if you want to take advantage of Ruby 1.9 features.

Don’t fall into the trap: Ruby 1.9.1 seem work at a first glance, as long as you don’t use some incompatible features such as the #truncate helper, which relies on ActiveSupport::Multibyte::Chars, which doesn’t play very nice with Ruby 1.9.1.

Mandatory Changes

This section includes incompatible changes in the Rails 3 codebase, new features or deprecated behaviors you should avoid to facilitate the upgrade to Rails 3. I call this section “mandatory” because, skipping one of these tasks might prevent your Rails 3 application from loading or running properly.

Use Bundler to manage your Gem dependencies

Unless you lived in a cave for the last year, you probably heard about Bundler. Bundler is the new way to manage Gem dependencies in Rails 3 applications. Bundler is also quickly becoming the new Ruby standard to package and require external Gems in a Ruby project.

What you might not know, is that you can start using Bundler with Rails 2.3 right now. Just follow these steps to override the Rails 2.3 gem handling and replace it with support for Bundler.

The Bundler website contains all the information you need to know about Bundler and the Gemfile specification file.

Unobtrusive JavaScript

Unobtrusive JavaScript is one of the biggest changes on the frontend side of the upcoming Rails 3 version.

Rails 3 is no longer Prototype-oriented, Rails 3 code is now JavaScript framework agnostic and there are many incompatible changes that require your attention. Learn more about Unobtrusive JavaScript in Rails 3.

Start converting your JavaScript right now and avoid using deprecated helper so that you won’t have to change all your code later when switching to Rails 3.

`Object#returning`

Did you know that Object#returning has been removed in Rails 3? Replace your code with Object#tap as soon as possible.

Beware of HTML code in YAML locale files

Do you use HTML in your YAML locale files? Make sure the key ends with _html or Rails 3 will escape it.

Rails Metal has been removed

Since Rails 3 is closer to Rack, the Metal abstraction is no longer needed. The Rails Metal feature has been removed from Rails 3.
You can read the commit message to have an explanation of what to do with your existing Metals.

Only ActiveRecord fixtures in the `test/fixtures` folder

Commit 8ec085bf1804770a547894967fcdee24087fda87 breaks the usage of the fixtures folder for non-model fixtures. If you were used to place fixture files for your custom libraries in the test/fixtures directory, move them to an other folder (e.g. test/files).

Rails `error_messages_for`, `error_message_on`, … helpers

Commit cd79a4617421f1b66e905f5da84ff28004e2bedd removes input, form, error_messages_for and error_message_on from the framework. The helpers are still available in a plugin called dynamic_form, but I strongly encourage you to update your code in order to avoid using the plugin. Ryan Bates demonstrates a possible approach.

Optional Changes

This section includes changes for which Rails 3 provides a deprecation warning or fallback. For this reason, you are not forced to complete all these tasks before upgrading to Rails 3. However, I strongly suggest you to review all the steps and change the code before upgrading to Rails 3 to reduce the number of warnings in your console and log file.

`RAILS_ROOT`, `RAILS_ENV`, and `RAILS_DEFAULT_LOGGER` constants are now deprecated

Railties, one of the Gems part of the Rails 3 framework, now deprecates the following global constants:

RAILS_ROOT in favour of Rails.root
RAILS_ENV in favour of Rails.env
RAILS_DEFAULT_LOGGER in favour of Rails.logger

Learn more.

Avoid legacy `ActiveRecord::Base#find([:all | :first | :last])` statements

You might have heard about the changes in the Active Record query interface for Rails 3. Here’s an interesting quote.

Currently ActiveRecord provides the following finder methods:

find(id_or_array_of_ids, options)

find(:first, options)

find(:all, options)

first(options)

all(options)

update_all(updates, conditions, options)

and the following calculation methods:

count(column, options)

average(column, options)

minimum(column, options)

maximum(column, options)

sum(column, options)

calculate(operation, column, options)

Starting with Rails 3, supplying any option to the methods above will be deprecated. Support for supplying options will be removed from Rails 3.2. Moreover, find(:first) and find(:all) (without any options) are also being deprecated in favour of first and all.

If you have any code using the legacy #find(:all), #find(:first) or #find(:last) methods, start converting them now into the corresponding #all, #first, and #last alternatives. You can pass the options to the method or use anonymous/named scopes.

1
2
3
4
5
6
7
8
9
10
11
12

# deprecated statement
Post.find(:all, :conditions => { :approved => true })

# better version
Post.all(:conditions => { :approved => true })

# best version (1)
named_scope :approved, :conditions => { :approved => true }
Post.approved.all

# best version (2)
Post.scoped(:conditions => { :approved => true }).all

Simulating the new Active Record API

ActiveRecord in Rails 3 will expose a brand new API. You can try to use a very similar approach in Rails 2.3 using named_scopes.

For instance, here’s a few named_scopes which simulates Rails 3 features.

1
2
3

named_scope :limit, lambda { |limit| { :limit => limit } }
named_scope :select, lambda { |select| { :select => select } }
named_scope :where, lambda { |conditions| { :conditions => conditions } }

You can create a shared module with all the corresponding Rails 3 new methods implemented in Rails 2 and start using the new syntax as soon as possible. Once switched to Rails 3, simply remove the module inclusion to have your code ready for ActiveRecord 3.

Update 2010-07-26: thanks to Ruby5 I just discovered that someone already created a library to simulate Rails 3 API, called fake_arel.

Rails XSS protection

In order to protect the application from XSS attacks, Rails 3 will automatically escape any content that does not originate from inside of Rails itself. This is a very important, non compatible, change which may seriously break your application and the existing view helpers.

Fortunately, you can already experiment the default escaping with Rails 2.3 thanks to the rails_xss plugin. This plugin replaces the default ERB template handlers with erubis, and switches the behaviour to escape by default rather than requiring you to escape. This is consistent with the behaviour in Rails 3.0.

You are encouraged to try it as soon as possible.

Plugin tasks and initialization

Rake tasks in vendor/plugins/PLUGIN/tasks are deprecated, as well the vendor/plugin/PLUGIN/rails/init.rb file. Use lib/tasks and Railties instead. lib/tasks already works in Rails 2, Railties is a Rails 3 feature but you can use it in combination with the legacy init.rb file to preserve compatibility with both Rails 2 and Rails 3 versions.

Deprecated Methods

There are a bunch of Rails 2 methods that are going to be deprecated in Rails 3. Here’s a not-complete list:

ActiveRecord::Base.add_to_base(msg) has been deprecated. Use ActiveRecord::Base.add(msg) insted. This method already works in Rails 2.

Rails 3 upgrade

The steps above are not enough to make your project a real Rails 3 application, they are just a small subset of changes you should apply. The big difference which is also the main advantage compared with all the other changes, is that you don’t have to wait for Rails 3 to adapt the code. The more steps you complete now, the less you will have to change while upgrading to Rails 3.

Upgrading to Rails 3 screencast

Looking for a Rails 3 screencast? This one hour screencast is a live example of upgrading a real-world application from Rails 2 to Rails 3.

Understanding Ruby and Rails: extract_options! from Arrays

Simone Carletti — Tue, 22 Sep 2009 09:18:21 +0000

This is article is part of my series Understanding Ruby and Rails. Please see the table of contents for the series to view the list of all posts.

How many times did you see a method call like the following one in your Rails application?

1
2
3

my_method :arg1
my_method :arg1, :arg2, :argN
my_method :arg1, :foo => true, :bar => 1

What makes my_method quite special is the ability to pass an arbitrary number of parameters (:arg1, :arg2…) followed by a list of keyword/value options.

This is made possible by a really helpful method provided by ActiveSupport called extract_options!. What this core extension does is to extract the options from the given set of arguments. When no options are available, the method returns a blank Hash.

Let me show you an example.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# Use args with the splat operation to allow
# an unlimited number of parameters
def my_method(*args)
options = args.extract_options!
puts "Arguments: #{args.inspect}"
puts "Options: #{options.inspect}"
end

my_method(1, 2)
# Arguments: [1, 2]
# Options: {}

my_method(1, 2, :a => :b)
# Arguments: [1, 2]
# Options: {:a=>:b}

extract_options! is largely used in every Rails project and you probably encountered it countless times. It powers the most part of Rails features you use every day including ActionController filters, ActiveRecord validations and finder methods.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# ActionController filters
class MyController < ApplicationController before_filter :my_method, :if => :execute?, :only => %w(new)
end

# ActiveRecord validations and finders
class MyModel < ActiveRecord::Base validates_presence_of :field, :allow_blank => true

...

def self.my_find
find(:all, :order => "id", :limit => 10)
end

end

extract_options! allows you to easily extract a list of options from an array of parameters, usually coming from a method invocation.

It isn’t a standard Ruby method but a Rails Core Extension and you need to require ActiveSupport in order to use it. Also, beware that this is a “bang” method, hence it definitely modifies the object it is called on.

Testing Rails: How to test Rails ActiveRecord Named Scopes

Simone Carletti — Wed, 17 Jun 2009 07:37:55 +0000

One of my biggest deal when approaching new features in Rails is the correct answer to the question “how should I test this?“.

Someone would probably assert that everything you code can be tested and, even though I perfectly agree with that, I would probably be more interested in how that shiny piece of code can be tested. Rails made the creation of tests a piece of cake, but it’s not always so easy.

Have you ever tried to test the correct creation of a cookie in Rails 2.2? Have you ever written an helper test that involves routing rules in Rails 2.0? Have you ever created a test to ensure your caching strategy works as expected?

If you answered yes to at least to one of those questions, you probably know what I mean.

The first requirement to write effective tests is to know what you are playing with. You can’t really know how to test an ActiveRecord callback unless you don’t know how callbacks works in ActiveRecord and, off course, what your hook is supposed to do.

The second suggestion if you get stuck writing a test is to start reading how that feature or the underlying implementation has been tested in the original framework. So, if you need to write a test for your custom Rails foo_tag helper, you probably want to start reading how the Rails team tested the helpers available with the Rails framework. Believe me, you’ll discover tons of new features just reading the tests.

I don’t want to go deep further on how to write effective tests, I’m already writing something special about that topic. This time, let me show you how to test one of the most recent ActiveRecord features: named_scope.

What are named_scope(s)?

Named scopes have been introduced in Rails 2.1. Ok, this is probably not the very latest feature, but one of those I have been testing in the “wrong” way since a few weeks ago.

Named scopes enables you to define custom ActiveRecord filters to narrow down a database query without explicitly pass conditions or query options. You can also chain multiple scopes to get all the records matching the sum of all the conditions merged altogether.

Look the following example, taken from the great Ryan’s What’s New in Edge Rails: Has Finder Functionality blog post.

1
2
3
4
5
6
7
8
9
10

class User < ActiveRecord::Base
named_scope :active, :conditions => {:active => true}
named_scope :inactive, :conditions => {:active => false}
named_scope :recent, lambda { { :conditions => ['created_at > ?', 1.week.ago] } }
end

# Standard usage
User.active # same as User.find(:all, :conditions => {:active => true})
User.inactive # same as User.find(:all, :conditions => {:active => false})
User.recent # same as User.find(:all, :conditions => ['created_at > ?', 1.week.ago])

How to test named_scope(s) (the wrong way)

Now that you know what named scopes are and how they works, at least on the surface, you probably want to know how to test them.

When I first started writing named scope tests, the most obvious way seemed to me to use fixtures. Unfortunately, my fixture files started to be cluttered by fake definitions quickly enough. Tons of records required just to test a single method.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# The following fixtures are used to test the Airport #best named_scope.
# The value for search doesn't match current number of search instances
# but it doesn't really matter in this case.

<% 10.times do |index| %>
initial_airport_code_ROM_<%= index %>:
search: search_hotels_example
custom_field: initial_airport_code
value: ROM
<% end %>

<% 5.times do |index| %>
initial_airport_code_FCO_<%= index %>:
search: search_hotels_example
custom_field: initial_airport_code
value: FCO
<% end %>

<% 5.times do |index| %>
initial_airport_code_RMA_<%= index %>:
search: search_hotels_example
custom_field: initial_airport_code
value: RMA
<% end %>

Even worse, my code started to be overwhelmed by ugly precondition checks in order to ensure my test didn’t pass just because of inconsistent fixtures.

1
2
3
4
5
6
7
8
9

def test_recent_should_returns_latest_N_records_ordered_by_created_at
# precondition: ensure the test doesn't pass
# just because there are only 3 users.
assert User.count > 3

users = User.recent(3).all
assert_equal(3, users.length)
assert_equal(User.find(:all, :limit => 3, :order => 'created_at DESC'), users)
end

Needless to say, the work to maintain all the fixtures was driving me crazy. I couldn’t believe that was the right way.

Then comes Factory, and developers started to say factories are better than fixtures. I agree, at least you don’t have to deal with messy fixtures.

At this point I quickly decided to change my tests from the old fixture-school to the fashionable factory-style.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

test "named_scope :latest should return all bookmarks ordered by create_at DESC" do
Bookmark.delete_all
bookmarks = (0..3).map { |t| Factory(:bookmark, :created_at => t.months.from_now) }
assert_equal bookmarks.reverse, Bookmark.latest
end

test "named scope :localized" do
Tutorial.delete_all
one = Factory(:tutorial, :language => languages(:italian))
two = Factory(:tutorial, :language => languages(:english))
thr = Factory(:tutorial, :language => languages(:italian))

assert_equal([one, thr], Tutorial.localized(languages(:italian)).all)
end

test "named scope :published" do
Tutorial.delete_all
one = Factory(:tutorial, :published => true)
two = Factory(:tutorial, :published => false)
thr = Factory(:tutorial, :published => true)

assert_equal([one, thr], Tutorial.published)
end

Yeah, this code started to smell less than the previous one. Do you agree?

But there’s still something wrong with those tests. Ok they works and they are definitely better than the previous ones or than no tests at all. But there’s still an unnoticeable smell in the air. No, it’s not you, don’t worry.

The question is: Do you really need to use real active record instances? Do you really need to test against the database? No, you don’t and you probably won’t.

How to test named_scope(s) (the right way)

There’s a better way to test named scopes. You can write your tests to test the conditions generated by the named scope instead of the records returned by the query.

Let’s say you need to test the following named scopes.

1
2
3
4

class Video < ActiveRecord::Base
named_scope :localized, lambda { |language| { :conditions => { :language_id => language.id }}}
named_scope :latest, lambda { |*args| { :limit => (args.shift || nil), :order => "#{self.table_name}.created_at DESC" }}
end

You already wrote these tests using the factory-way.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

test "named scope :localized" do
Video.delete_all

one = Factory(:video, :language => languages(:italian))
two = Factory(:video, :language => languages(:english))
thr = Factory(:video, :language => languages(:italian))

assert_equal([one, thr], Video.localized(languages(:italian)).all)
end

test "named_scope :latest(N) should return latest(N) bookmarks ordered by created_at DESC" do
Video.delete_all
videos = (0..3).map { |t| Factory(:video, :created_at => t.months.from_now) }
assert_equal [videos[3], videos[2]], Video.latest(2)
end

test "named_scope :latest should return all bookmarks ordered by created_at DESC" do
Video.delete_all
videos = (0..3).map { |t| Factory(:video, :created_at => t.months.from_now) }
assert_equal videos.reverse, Video.latest
end

You might be happy to know that there’s a really wonderful method, named proxy_options, that returns the options set by a named_scope.

1
2
3
4
5

p Video.latest.proxy_options
# {:limit=>2, :order=>"videos.created_at DESC"}

p Video.latest(2).proxy_options
# {:limit=>nil, :order=>"videos.created_at DESC"}

Isn’t that cool? Yeah, I know it is!

Now that we know how to get the query filters, we can use them to test our expectations.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

test "named scope :localized" do
expected = { :language_id => languages(:italian).id }
assert_equal expected,
Video.localized(languages(:italian)).proxy_options
end

test "named_scope :latest(N) should return latest(N) bookmarks ordered by created_at DESC" do
expected = { :limit => 2, :order => "videos.created_at DESC" }
assert_equal expected,
Video.latest(2).proxy_options
end

test "named_scope :latest should return all bookmarks ordered by created_at DESC" do
expected = { :limit => nil, :order => "videos.created_at DESC" }
assert_equal expected,
Video.latest.proxy_options
end

I you want to make your test even more cool, I’ve found a nice addition reading the Thoughbot Pacecar unit tests. You can add an initial respond_to? assertion to make sure you actually defined the named scope before testing it.

1
2
3
4
5
6

test "named scope :localized" do
assert Video.respond_to?(:localized)
expected = { :language_id => languages(:italian).id }
assert_equal expected,
Video.localized(languages(:italian)).proxy_options
end

Now that you know how to get access to the named scope options, should probably avoid wasting resources creating new records and running active record queries. Just because you are writing test it doesn’t mean you don’t need to care about performances or execution time.

So far, this is the best way I found to test ActiveRecord named scopes. Do you know a better one?

Validating the format of an URL with Rails

Simone Carletti — Thu, 30 Apr 2009 06:34:39 +0000

Validating the format of an URI is one of those problems that periodically arises when you are validating model attributes in Rails.

There are tons of solutions available on the web, but the 90% of them are usually based on complex regular expressions and they often made custom (and perhaps too restrictive) assumptions. This is a small list of the most common “mistakes”:

Some validators don’t support custom domain names such as http://simone.weppos, absolutely legal if my application is working behind a custom DNS service
Some validators don’t support hostnames such as http://localhost
Some validators focus on specific URL patterns instead of supporting a common validation mechanism
Some validators don’t understand that http://www.google.co.uk esists
Some validators rely on a TLD whitelist that often becomes outdates.

I’m working on a project where I need to validate URLs quite often and I decided to approach the problem from an other point of view. I don’t like to reinvent the wheel, thus I decided to take advantage of Ruby URI library.

This is a super simple validator I wrote. It is based on URI.parse.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

# Validates whether the value of the specified attribute matches the format of an URL,
# as defined by RFC 2396. See URI#parse for more information on URI decompositon and parsing.
#
# This method doesn't validate the existence of the domain, nor it validates the domain itself.
#
# Allowed values include http://foo.bar, http://www.foo.bar and even http://foo.
# Please note that http://foo is a valid URL, as well http://localhost.
# It's up to you to extend the validation with additional constraints.
#
# class Site < ActiveRecord::Base
# validates_format_of :url, :on => :create
# validates_format_of :ftp, :schemes => [:ftp, :http, :https]
# end
#
# ==== Configurations
#
# * :schemes - An array of allowed schemes to match against (default is [:http, :https])
# * :message - A custom error message (default is: "is invalid").
# * :allow_nil - If set to true, skips this validation if the attribute is +nil+ (default is +false+).
# * :allow_blank - If set to true, skips this validation if the attribute is blank (default is +false+).
# * :on - Specifies when this validation is active (default is :save, other options :create, :update).
# * :if - Specifies a method, proc or string to call to determine if the validation should
# occur (e.g. :if => :allow_validation, or :if => Proc.new { |user| user.signup_step > 2 }). The
# method, proc or string should return or evaluate to a true or false value.
# * :unless - Specifies a method, proc or string to call to determine if the validation should
# not occur (e.g. :unless => :skip_validation, or :unless => Proc.new { |user| user.signup_step <= 2 }). The
# method, proc or string should return or evaluate to a true or false value.
#
def validates_format_of_url(*attr_names)
require 'uri/http'

configuration = { :on => :save, :schemes => %w(http https) }
configuration.update(attr_names.extract_options!)

allowed_schemes = [*configuration[:schemes]].map(&:to_s)

validates_each(attr_names, configuration) do |record, attr_name, value|
begin
uri = URI.parse(value)

if !allowed_schemes.include?(uri.scheme)
raise(URI::InvalidURIError)
end

if [:scheme, :host].any? { |i| uri.send(i).blank? }
raise(URI::InvalidURIError)
end

rescue URI::InvalidURIError => e
record.errors.add(attr_name, :invalid, :default => configuration[:message], :value => value)
next
end
end
end

The code is also available as a Gist.

I do have some unit tests, but they are specific to my application and I can’t post them here. I encourage you to build your own.

I found shoulda to be particularly helpful in this situation.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class ModelTest < ActiveSupport::TestCase

VALID_URLS = [
'http://godaddy.com', 'http://www.godaddy.com',
'https://godaddy.com', 'https://www.godaddy.com',
'http://godaddy.host', 'https://godaddy.host',
]
INVALID_URLS = [
'ftp://godaddy.com',
'www.godaddy.com', 'godaddy.com',
'http:/godaddy.com',
]

should_allow_values_for :myattr, *VALID_URLS
should_not_allow_values_for :myattr, *INVALID_URLS

end

Please note that this validator does not claim to be perfect. As I explained in the documentation, it does not validates some requirements that might be mandatory for your specific application.

Simone Carletti's Blog » activerecord

The Road to Rails 3: make your Rails 2.3 project more Rails 3 oriented

Upgrading to Rails 3 screencast

Prerequisites

Tests

Ruby 1.8.7 or 1.9.2

Mandatory Changes

Use Bundler to manage your Gem dependencies

Unobtrusive JavaScript

Object#returning

Beware of HTML code in YAML locale files

Rails Metal has been removed

Only ActiveRecord fixtures in the test/fixtures folder

Rails error_messages_for, error_message_on, … helpers

Optional Changes

RAILS_ROOT, RAILS_ENV, and RAILS_DEFAULT_LOGGER constants are now deprecated

Avoid legacy ActiveRecord::Base#find([:all | :first | :last]) statements

Simulating the new Active Record API

Rails XSS protection

Plugin tasks and initialization

Deprecated Methods

Rails 3 upgrade

Upgrading to Rails 3 screencast

Understanding Ruby and Rails: extract_options! from Arrays

Testing Rails: How to test Rails ActiveRecord Named Scopes

What are named_scope(s)?

How to test named_scope(s) (the wrong way)

How to test named_scope(s) (the right way)

Validating the format of an URL with Rails

`Object#returning`

Only ActiveRecord fixtures in the `test/fixtures` folder

Rails `error_messages_for`, `error_message_on`, … helpers

`RAILS_ROOT`, `RAILS_ENV`, and `RAILS_DEFAULT_LOGGER` constants are now deprecated

Avoid legacy `ActiveRecord::Base#find([:all | :first | :last])` statements