[rspec-devel] Spec a spec generator
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.
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
> > 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
> 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!
> > 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
More information about the rspec-devel