[Rspec-devel] RSpec on Rails

[aslak hellesoy]

On 6/5/06, Lachie <lachiec at gmail.com> wrote:
> just a quickie, i've implemented the generators to override model and
> controller generators
>

great. i'm reorganising the source code a bit towards a gem/generator
structure - i'll commit something in a couple of hours.

> 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?
>

i don't know yet - i'm writing my first generator now, and don't know
enough about the internals yet.

but it's ruby so there must be an easy way ;-)

aslak

> 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/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>