[Rspec-devel] RSpec on Rails

[aslak hellesoy]

On 6/5/06, Lachie <lachiec at gmail.com> wrote:
> On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 6/3/06, Lachie <lachiec at gmail.com> wrote:
> > > me too! (said with all the weight of being on the list for 2 whole days :)
> > >
> >
> > OK, it's checked into trunk/vendor/rspec_on_rails.
> > The plugin lives under trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
> >
> > As far as testing goes, I think it's sufficient to follow the route of
> > 'acceptance testing', i.e. write more exhaustive specs for the demo
> > app, and fix the plugin accordingly if it breaks.
>
> Sounds like the best way to me. A nice feature might be to set it up
> to use a sqlite3 file or memory database, to alleviate the dependency
> on an external database. Though, that wouldn't really allow for
> testing transactions or the like.
>

Right now it's using sqlite3 on file - not memory. Not sure what's
needed for in-memory. Patches welcome.

> > I have written up some docs under trunk/src/documentation/rails.page
> > It's currently lying, since the plugin isn't yet published.
> >
> > What is the best way to publish it? As a separate gem? Just 'pure' svn? Both?
>
> Well, the rails plugin system works in a fairly specific way -- an
> installed gem wouldn't be automatically hooked by the system.
>
> A crash course in rails plugins (apologies to those who already know it):
> I would install my plugin using the following command:
> script/plugin install
> http://lachie.info/svn/projects/rails_plugins/rspec_on_rails/
>

I'd rather not use the default plugin mechanism, as it's not
particularly well suited for moving target code such as rspec. The
user will always get head (unless we start tagging) - and
incompatibilities between various versions of the plugin, rspec and
rails itself is a potential can of worms.

So I think we should go for a gem/generator approach. Any gem ending
with _generator is automatically picked up by rails. If we package
this as a gem called rspec_generator, users would be able to do:

gem install rspec_generator
script/generate rspec # => puts the spec_helper.rb in place and
creates empty directories.

We should provide generators that will replace all the test stuff. For
example for models:

script/generate rspec model customer
or
script/generate rspec_model customer
or simply
script/generate model customer (as before - if we can hijack the
builtin generators)

(See more on this below)

> This:
> * downloads it using http, svn externals, svn export or svn checkout
>   it goes into PLUGIN_ROOT=RAILS_ROOT/vendor/plugin/rspec_on_rails
> * runs PLUGIN_ROOT/install.rb
>

I know, but I'd rather not because of potential versioning problems.

> The default way for it to download is via http... it can use svn
> directly, but the user must have svn on their machine. Can rubyforge
> provide a plain http listing of the files under svn?
>

Only the svn:// protocol is supported afaik

> When the rails app loads, it runs PLUGIN_ROOT/init.rb which pulls in
> the rspec_on_rails libraries.
> The generate script looks for generators here.
> Rake pulls in any tasks defined in PLUGIN_ROOT/tasks
>
> I think that an installed gem would just sit inert on the disc, unless
> the user did a symlink to PLUGIN_ROOT
>
> The "official" place to publish it is in the rails wiki... please feel
> free to change my rpsec on rails entry in the testing section to point
> at the http/svn path you've set up.
>
> http://wiki.rubyonrails.com/rails/pages/Plugins
>
> (The plugin script's discover command actually scrapes this page for
> plugin sources)
>
> You'd need to publish the path right down to the plugin:
> /trunk/vendor/rspec_on_rails/vendor/plugins/rspec_on_rails
>
> > > Though, obviously there's a lot of scope for refactoring, and a few
> > > things to add, such as spec generators.
> > >
> >
> > That would be great!
> > It would also be great to override the behaviour of the general
> > generators, so that tests are not created, but specs instead (when the
> > user does script/generate model).
>
> I was thinking the same thing... I'm sure its possible, but it might
> start out being quite hacky.
>

See the various alternatives above. We should pick whatever makes most
sense from a user's perspective, provided it's not too hacky. I'd
prefer to let everything remain the same for the user, i.e.

script/generate model customer

will create:

spec/fixtures/customer.yml instead of test/fixtures/customer.yml
and
spec/models/customer_spec.rb instead of test/unit/customer_test.rb

-provided the user has previously configured his rails project to be
rspec-based (using simply script/generate rspec).

Let me know what you think of the generator-as-gem approach instead of
http/svn based plugins.

Aslak

> > The fixtures should also go under spec/fixtures, and not test/fixtures.
>
> oops...
>
> --
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>