Advanced Rails - Building Industrial-Strength Web Apps in Record Time

Contributing to Rails | 293

Rails contributors use ticket status and resolutions as a way to deal with the

large volume of incoming tickets. It is common for a ticket to be opened and

closed a few times before being accepted or rejected. Don’t worry if your ticket is

closed as untested; that just means it needs tests (or, alternatively, a very good

reason why it can’t or shouldn’t be tested). Then it can be sent back.

Also, don’t be discouraged if your patch is ultimately rejected. There are many fea-

tures that used to be in core Rails that have been removed or turned into plugins in

Rails 2.0. The Rails core team is focusing on keeping Rails smaller and more

agile; most frameworks tend to accumulate features without limit unless their

growth is kept in check. The Rails plugin system was designed so that almost

anything in Rails can be changed at runtime. In this way, the core can be kept

simple without hampering the development of new features.

Many Rails contributors spend time in the#rails-contrib IRC channel onirc.
freenode.org, and there is good discussion about Rails internals there. Most contribu-
tors also subscribe to the rubyonrails-core mailing list at Google Groups (http://
groups.google.com/group/rubyonrails-core), which has more visibility and perma-
nence than the IRC channel. Both are good places to look for patch reviewers, and it
is a good idea to ask around on IRC and the mailing list before diving into any major
new feature work; there may be people who have started (or even completed) similar
work, and it is good to find other developers who may have ideas about your plans.

Rails Unit Tests

The Rails framework is built in a modular fashion; Rails 2.0 comprises ActionPack,
ActiveRecord, ActionMailer, Active Resource, ActiveSupport, and RailTies. As such,
each component is tested separately. This causes a few minor issues (as the full func-
tionality of one module may depend partially on another, so they can never be com-
pletely independent), but for the most part it increases flexibility, and the benefits
outweigh the drawbacks.

Unit tests for most components are self-contained. Each component has a Rakefile
defining its testing strategy and any other Rake tasks it requires. With the exception
of ActiveRecord, all Rails components can be tested by changing to their directory
and executingrake. If all is well, you will see a large number of periods (representing
successful tests), and it will end with no failures or errors:

Finished in 1.444231 seconds.

704 tests, 5475 assertions, 0 failures, 0 errors

ActiveRecord is a bit more difficult to test, due to its dependency on many external
databases. The default task, if no task is provided torake, is to run the tests for
MySQL, PostgreSQL, SQLite (version 2), and SQLite3.