[rspec-devel] Spec a spec generator

aslak hellesoy aslak.hellesoy at gmail.com
Mon Oct 30 08:43:55 EST 2006


On 10/30/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 10/30/06, Jeff Dean <jeff at jefdean.com> wrote:
> > I just created an rspec_scaffold_resource generator and I've got a few
> > questions about what the next steps are.
> >
> > First, this is a total noob question, but how do I run the specs from
> > rspec/vendor/rspec_on_rails/vendor/plugins/rspec/spec from
> > the command line?  I haven't written specs for the generator yet because I
> > don't know how to run them.
>
> Assuming you've checked out the source and have all the dependencies,
> stand in vendor/rspec_on_rails and say "rake spec:plugins" or
> "../../bin/spec vendor/plugins/rspec/spec".
>
> >
> > Second, rspec_scaffold_resource depends on edge rails.  Is it safe to assume
> > that if you are running rspec_scaffold_resource that you are already running
> > edge, or should I try to check for it somehow?  On a related note - since
> > you can't run it without edge, you need to freeze edge or add an
> > svn:externals property to even try it out.
>

For now, just assume edge rails is available.

> This is something I hadn't considered. We don't have any official
> support policy, and given that nobody working on this does so full
> time, any such policy would have to take that into account. The most
> reasonable policy I can think of is that we should do our best to
> ensuring that any rspec release works w/ the latest rails stable
> release at the time. This would, obviously, not pertain to edge rails.
> Maybe some day enough people will use rspec on rails and the rails
> core team will have the good sense to incorporate this functionality
> right into rails (you can say-ay-ay I'm a dreamer.....).
>
> In the mean time, this does present an interesting dilemma. What if we
> were to set up the build so that running "rake pre_commit" will run
> everything but these edge-rails-specific specs against the latest
> stable rails and fail the build if anything fails, but then run
> everything including the edge-rails-specific specs and only report if
> anything fails, but still pass the build? That would keep us
> progressing without turning edge rails into a bottleneck, but would
> also keep edge rails constantly on the radar.
>
> If that makes sense to everyone, I'm sure we can figure out a way to do it.
>

A script that specifies an array of svn tags and trunk. E.g.
['tags/1.1.6', 'trunk']
We'd loop through this array and run rake spec for all of them.

Each spec could have its body in an if block a la:

if(RAILS_VERSION > 1.1.6)
  specify "something that should only work on edge" do
    ...
  end
end

> > Third, I'm not too experienced with patching, but I assume that the
> > TortosieSVN's "create patch" and specifying all of the new/modified files
> > should do the trick.  Is there anything else I should know?  Any
> > incompatibilities I should watch out for?
>
> I've not used TortoiseSVN to create a patch, so someone else will have
> to comment on this.
>

create patch should work. Make sure to attach entirely new files too.
At rubyforge, add a comment to your patches, so we can distinguish
older from newer patches.

> > And last - I know that the directory structure will change soon, and since
> > the generator creates files I imagine I'd want to test that these files are
> > correctly created.  I'd like to write a comprehensive spec, but I'd prefer
> > not to write it twice (if the directory changes will affect the sample rails
> > app).  Any thoughts on how to proceed here?
>
> What that is going to look like is totally unknown right now. There
> are wide reaching implications in our build - for example, almost all
> of the examples on the website, including those for rspec on rails,
> get run with "rake pre_commit". This guarantees that the examples
> actually work, which is an important feature that I'd not be very
> willing to give up. So the existing example app will need to live
> somewhere (so we can use it for the documentation), though it is not
> necessary for it to live in the same directory structure as the plugin
> code.
>
> Also, some of the specs in
> vendor/rspec_on_rails/vendor/plugins/rspec/spec (which specify the
> plugin) use controllers and views that are assumed to be where they
> would normally be in a rails app. In order to move them beneath the
> plugin dirs, we'd have to override all of the underlying rails mapping
> mojo. The more I think of that, the less sense it makes to me - BUT,
> not making that move means that you can't run those specs without
> having the specified controllers, helpers, views, etc in their natural
> homes. Kinda sucks.
>
> All of that said, I'm not sure where this is leading, so the best
> advice I can offer is to work w/in the existing directory structure
> (in trunk) and hope for the best. There's no guarantee any of this
> will move anywhere, so why let that impede your work now?
>
> > Thanks in advance for your time,
>
> And for yours!
>
> Cheers,
> David
>
> >
> > Jeff
> >
> >
> >
> > _______________________________________________
> > 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
>


More information about the rspec-devel mailing list