[rspec-devel] Spec a spec generator
jeff at jefdean.com
Mon Oct 30 16:56:59 EST 2006
I just tried to run rake spec:plugins from trunk and got the following error
message. I have the 0.6.4 gem installed.
c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec"
`gem_original_require': no such file to load -- controller_mixin
Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib"
Do I have to uninstall the gem to make this work?
On 10/30/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> 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
> > > that if you are running rspec_scaffold_resource that you are already
> > > edge, or should I try to check for it somehow? On a related note -
> > > 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
> 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
> > > Third, I'm not too experienced with patching, but I assume that the
> > > TortosieSVN's "create patch" and specifying all of the new/modified
> > > 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
> > > 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
> > > not to write it twice (if the directory changes will affect the sample
> > > 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
> rspec-devel mailing list
> rspec-devel at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-devel