[rspec-devel] Spec a spec generator
dchelimsky at gmail.com
Mon Oct 30 04:23:41 EST 2006
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
> 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.
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.
> 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.
> 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!
> rspec-devel mailing list
> rspec-devel at rubyforge.org
More information about the rspec-devel