For this plugin you won't need the file vendor/plugins/yaffle/lib/yaffle.rb so you can delete that.

rm vendor/plugins/yaffle/lib/yaffle.rb

Editor's note: many plugin authors prefer to keep this file, and add all of the require statements in it. That way, they only line in init.rb would be require "yaffle"
If you are developing a plugin that has a lot of files in the lib directory, you may want to create a subdirectory like lib/yaffle and store your files in there. That way your init.rb file stays clean

Testing Setup

Testing plugins that use the entire Rails stack can be complex, and the generator doesn't offer any help. In this tutorial you will learn how to test your plugin against multiple different adapters using ActiveRecord. This tutorial will not cover how to use fixtures in plugin tests.

Update a core class: Adding "to_squawk" to String

To update a core class you will have to:

Write tests for the desired functionality

Create a file for the code you wish to use

Require that file from your init.rb

Most plugins store their code classes in the plugin's lib directory. When you add a file to the lib directory, you must also require that file from init.rb. The file you are going to add for this tutorial is lib/core_ext.rb

First, you need to write the tests. Testing plugins is very similar to testing rails apps. The generated test file should look something like this:

Your test should fail with no such file to load -- ./test/../lib/core_ext.rb (LoadError) because we haven't created any file yet. Create the file lib/core_ext.rb and re-run the tests. You should see a different error message:

1.) Failure ...
No tests were specified

Great - now you are ready to start development. The first thing we'll do is to add a method to String called to_squawk which will prefix the string with the word "squawk! ". The test will look something like this:

Now that test should pass. Since your plugin is going to work with field names, you need to allow people to define the field names, in case there is a naming conflict. You can write a few simple tests for this:

Adding directories to the load path makes them appear just like files in the the main app directory - except that they are only loaded once, so you have to restart the web server to see the changes in the browser.

Adding directories to the load once paths allow those changes to picked up as soon as you save the file - without having to restart the web server.

Storing plugins in alternate locations

You can store plugins wherever you want - you just have to add those plugins to the plugins path in environment.rb

Since the plugin is only loaded after the plugin paths are defined, you can't redefine this in your plugins - but it may be good to now.

You can even store plugins inside of other plugins for complete plugin madness!

Plugin Loaders and Plugin Locators

If the built-in plugin behavior is inadequate, you can change almost every aspect of the location and loading process. You can write your own plugin locators and plugin loaders, but that's beyond the scope of this tutorial.

Custom Plugin Generators

If you are an RSpec fan, you can install the rspec_plugin_generator, which will generate the spec folder and database for you.