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 on irc.
freenode.org, and there is good discussion about Rails internals there. Most contributors
also subscribe to the rubyonrails-core mailing list at Google Groups (http://
groups.google.com/group/rubyonrails-core), which has more visibility and permanence
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 functionality
of one module may depend partially on another, so they can never be completely
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.
Pages:
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446