rails symphonies

autotest is a great tool to easily test your Rails application. autotest runs in the background and continuously test your app, and notify you of the results, thus leaving you to build your app with the confidence of knowing that it isn’t going to break without your knowledge, and as soon as possible. It makes writing your tests easier, and the easier it is, the more likely you’ll end up doing it.

Note: I have only used autotest with RSpec, and all details are based on that. I also assume that your plugin is installed in vendor/plugins

I have been working on a plugin that uses RSpec to help me test the plugin’s integrity. After a while I got a little tired of continuously running a rake task to test it out.

Sadly by default, autotest doesn’t test your plugin directory. What a shame, but it also provides a challenge!

Enabling autotest on your Rails plugin

Now go into your plugin directory and create a folder called autotest.
cd vendor/plugins/secret_sauce/
mkdir autotest

Inside the autotest directory, create a file called discover.rb and dump this little gem inside:

While your in the root directory of your plugin, in my case its secret_sauce, just run autotest.
autotest

Boom! You are now autotest-ing your Rails plugin! Sweet.

Using your Application’s RSpec Options

You’ll notice that your autotests lack a bit of color… Or perhaps you want it to run the same options as your application. Have no worry soldier! First go to your spec directory in your plugin, and create a symbolic link back to the original spec.opts file.

Using your application’s RSpec options:
cd vendor/plugins/secret_sauce/spec
ln -s ../../../../spec/spec.opts

Note: This only works for Unix-like operating systems, thats Mac OS X, Linux, and FreeBSD to name a few. For you Windows folks, you will have to just create a spec.opts file, or change your OS.

If you want to run under another set of options, just create a spec.opts file in the spec directory of your plugin, and fill in the details.

One shortcoming

Sure one shortcoming is that it’s not integrated when calling autotest in your application root directory, but something is always better than nothing.

One thing I keep forgetting to do when deploying a Rails application is to remove any Firebug JavaScript console calls I use for debugging.

You know, those:

Or something like that.

When committing back to the repository, you simply forget to remove them. Thus when deploying your new code, for those people who don’t have Firebug installed, the script will end in a premature death.

Oh noes!

This definitely isn’t cool, and its just a minor thing you forgot to do…and its causing a hell lot of problems.

Lucky for us we can hook into the Capistrano after update code callback to comment/strip out those lines from the JavaScript file.

To Comment Out:

To Strip Out:

So instead of removing those debugging calls from the file, just leave them there and let Capistrano and sed strip them out for ya!

Talk about an easy life :3.

Note: This only works in the top level javascripts directory.

Note:

• I recommend installing Ruby on Rails via RubyGems
• As long as you have Ruby installed, you can install Ruby on Rails, just skip the step about installing Ruby.
• I have instructions if you are interested in Installing Ruby On Rails on Ubuntu.

Plan of Attack

This is a quick down and dirty guide to getting Ruby and Rails working in Fedora 7. You may notice this is installed into /tmp , I do this because its universal on all Fedora and Linux distributions.

• Install Ruby
• Install RubyGems via source
• Install Ruby on Rails using RubyGems
• Test Rails installation

• Certain commands need to be executed as root. Lines requiring to be run as root, begin with a hash (#). To enter root execute su - .
• If a line begins with a dollar sign ($), those can be run as a normal user.
• If a line begins with a hash or a dollar sign, do not enter the starting hash or dollar sign into the terminal

rails /tmp/railstest
cd /tmp/railstest
./script/server