[Rspec-devel] RSpec on Rails

[Lachie]

just a quickie, i've implemented the generators to override model and
controller generators

i'll give em a burl and submit a patch later

more on this later, but i think that if we go the rspec generator
route, how would the overridden generators work?

On 6/6/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> 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
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>


-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/