It gives you greater familiarity with the Rails source, which is very
well written. It also helps you verify and prove that the problems you are experiencing
are actually problems with Rails.
Most patches should include tests. Especially for bugfixes, test-driven development
is a good philosophy to use. A test-driven methodology would incorporate
the following basic steps:
1. Before writing any application code, write a test that verifies the correct
functionality. Run the test; it should fail.
2. Write code to fix the bug until the test passes.
3. Verify that all other tests pass, not just the test in question.
Most areas of Rails are well-tested; however, there are some components (such
as the generators and CGI processing code) that are not very easy to test. When
writing nontrivial patches for those areas, the burden of proof is higher to ensure
that there are no regressions of other functionality.
The basic procedure to create a patch against Rails is simple:
1. svn up to grab the latest version of Rails.
2. Make the appropriate changes to the source.
3. Run rake to ensure all of the tests pass.
292 | Chapter 9: Incorporating and Extending Rails
4. Check the output of svn st as a sanity check for missing files, merge conflicts,
or other junk.
5. svn diff > my_patch.diff to create a unified diff of the changes.
6. Manually inspect the generated diff to verify that there are no extraneous
changes and that all necessary changes are included.
Pages:
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443