[rspec-devel] Spec a spec generator

Jeff Dean 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.

D:\rails\rspec\vendor\rspec_on_rails>rake spec:plugins
(in D:/rails/rspec/vendor/rspec_on_rails)
c:/ruby/bin/ruby -I"D:/rails/rspec/lib" "D:/rails/rspec/bin/spec"
"vendor/plugins/rspec/spec/context_factory_spec.rb"
"vendor/plugins/rspec/spec/controller_isolation_spec.rb"
"vendor/plugins/rspec/spe
c/opts_merger_spec.rb"
"vendor/plugins/rspec/spec/expectations/should_be_spec.rb"
"vendor/plugins/rspec/spec/expectations/should_have_rjs_spec.rb"
"vendor/plugins/rspec/spec/expectations/should_have_t
ag_spec.rb"
"vendor/plugins/rspec/spec/expectations/should_not_have_rjs_spec.rb"
"vendor/plugins/rspec/spec/expectations/should_not_have_tag_spec.rb"
"vendor/plugins/rspec/spec/expectations/should_not
_render_rjs_spec.rb"
"vendor/plugins/rspec/spec/expectations/should_render_rjs_spec.rb"
"vendor/plugins/rspec/spec/expectations/should_render_spec.rb"
"vendor/plugins/rspec/spec/generators/rspec_resou
rce_scaffold_spec.rb"
c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`gem_original_require': no such file to load -- controller_mixin
(MissingSourceFile)
        from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from
D:/rails/rspec/vendor/rspec_on_rails/config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:400:in
`require'
        from ./vendor/plugins/rspec/spec/../../../../spec/spec_helper.rb:3
        from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from ./vendor/plugins/rspec/spec/spec_helper.rb:1
        from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from ./vendor/plugins/rspec/spec/context_factory_spec.rb:1
        from c:/ruby/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
`require'
        from D:/rails/rspec/bin/spec:14
        from D:/rails/rspec/bin/spec:8
rake aborted!
Command failed with status (1): [c:/ruby/bin/ruby -I"D:/rails/rspec/lib"
"D...]

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
> 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
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20061030/b216a785/attachment-0001.html 


More information about the rspec-devel mailing list