I attended the GLSEC pre-conference tutorial on Ruby On Rails on Wednesday. The host was Chad Fowler and based upon the 1 day I think I can recommend anyone take his 4 version of the course. There is a tonne of clue locked up in his brain and he is good at teaching which is a rare combination. I’ve got literally pages of notes, but they likely won’t make too much sense if you were not there, but here are the ones I think will help others who are testing RoR apps.

  • To ‘merge’ all existing migration files into a single one, use rake db:schema:dump

    which will dump the database. You would then reset the schema version in the db. This sort of thing was a big problem at Points.

  • Rails (developers) tend to be fast and loose with db rules, so make sure they are properly constrained in the Models or Controllers
  • scripts/console will give you an interactive session (a la the Python interactive console) but with the entire Rails environment loaded so you can play with ActiveRecord directly
  • There doesn’t seem to be a ‘Ruby Lint’ type thing aside from CheckR but its not active and has no real progress it seems. Anyone know of a static analysis tool for Ruby?
  • Raw sql is given to an ActiveRecord object trough the :conditions symbol. So, if you find a #{blah} (like %s in python) in the conditions value you have yourself a SQL Injection issue. There is a proper, safe, way to use :conditions. That is not it.
  • Password hashing for storage in the database belongs in the model
  • Pretty URLs are nicer than Ugly URLs (and easy to do with Routes)
  • In Rails-speak
    • Unit Tests – are for models
    • Functional Tests – are for controllers
    • Integration tests – are multistep tests that involve more than one controller but noone uses them because there is no scaffolding done for you (and there shouldn’t be)
  • ActiveRecord has a number of built-in validations; use them
  • The default rake task is to run all the tests. Yay!
  • Tests don’t actually commit anything into the database as they run inside a transaction which is rolled back. So, if you have 2 records in a table and you run a test that inserts 100 rows, at the end of the test there is only 2 records in the table.
  • If you have to do some really ugly SQL, it should be put in the appropriate model with a nice name which is then referenced by the controller
  • Some built-in helpers
    • Mocks – are really stubs; used for removing calls to things like the technorati ping service
    • Fixtures – help you data drive your tests
  • The components stuff is deprecated, so just delete the directory in new projects to prevent its usage
  • Including the default JS libraries it ridiculously easy, so make sure that the app is only actually importing the ones it needs (in the views/application.rhtml)
  • In Rails 2.0, helpers will become first class unit testing objects. Unit testing them now is possible, but not easy.
  • Sessions should be as dumb as possible in Rails
  • Assume that your session could go away at any time. Can the application handle that? Gracefully?