Forum: RSpec can't get (r)spec to work in non-rails project

Hi

I can't seem to get rspec and autotest to work in a small test
project. The spec command doesn't load the implementation file. I
found some info about non-rails projects with rspec, but these did not
solve my problem.

I have the following files:

project_map/
  lib/todoist.rb
  spec/todoist_spec.rb

in todoist.rb I have a Todoist class, in the spec I have a describe
Todoist with one example

Autotest runs and does reload files in /lib and /spec, it's the spec
(spec spec/todoist_spec.rb) that crashes with 'uninitialized constant
Todoist'.

Backtrace:
  ./spec/todoist_spec.rb:3: uninitialized constant Todoist (NameError)
  from /Library/Ruby/Gems/1.8/gems/rspec-1.1.3/lib/spec/runner/
example_group_runner.rb:14:in `load'
  from /Library/Ruby/Gems/1.8/gems/rspec-1.1.3/lib/spec/runner/
example_group_runner.rb:14:in `load_files'
  from /Library/Ruby/Gems/1.8/gems/rspec-1.1.3/lib/spec/runner/
example_group_runner.rb:13:in `each'
  from /Library/Ruby/Gems/1.8/gems/rspec-1.1.3/lib/spec/runner/
example_group_runner.rb:13:in `load_files'
  from /Library/Ruby/Gems/1.8/gems/rspec-1.1.3/lib/spec/runner/
options.rb:84:in `run_examples'
  from /Library/Ruby/Gems/1.8/gems/rspec-1.1.3/lib/spec/runner/
command_line.rb:19:in `run'
  from /Library/Ruby/Gems/1.8/gems/rspec-1.1.3/bin/spec:4
  from /usr/bin/spec:16:in `load'
  from /usr/bin/spec:16

rspec 1.1.3 (run as gem)
standard Mac OS X Leopard ruby (1.8.6)

Any solutions?
Regards

On Feb 16, 2008 8:51 AM, Ivo Dancet <ivo.dancet@gmail.com> wrote:
>         lib/todoist.rb
>         spec/todoist_spec.rb
>
> in todoist.rb I have a Todoist class, in the spec I have a describe
> Todoist with one example
>
> Autotest runs and does reload files in /lib and /spec, it's the spec
> (spec spec/todoist_spec.rb) that crashes with 'uninitialized constant
> Todoist'.

Are you requiring the implementation file from the spec file?

That was very quick, thanks!

No, I was not (and it works when I require the file), I thought rspec
would have some method to load the implementation file (as I followed
the naming convention) like it does in rails.

Op 16-feb-08, om 14:59 heeft David Chelimsky het volgende geschreven:

On Feb 16, 2008 9:10 AM, Ivo Dancet <ivo.dancet@gmail.com> wrote:
> That was very quick, thanks!
>
> No, I was not (and it works when I require the file), I thought rspec
> would have some method to load the implementation file (as I followed
> the naming convention) like it does in rails.

What mislead you to believe such a thing?

Op 16-feb-08, om 15:13 heeft David Chelimsky het volgende geschreven:

> On Feb 16, 2008 9:10 AM, Ivo Dancet <ivo.dancet@gmail.com> wrote:
>> That was very quick, thanks!
>>
>> No, I was not (and it works when I require the file), I thought rspec
>> would have some method to load the implementation file (as I followed
>> the naming convention) like it does in rails.
>
> What mislead you to believe such a thing?

such a thing as in: rspec in rails doesn't work the way I thought, or
as in: why would it work the same way or as in: 'naming convention?
there is no such thing'!

I guess the answer on all three possibilities is: I don't really know
much about the internals of rspec... I'm working with it for about two
months now and I really love it. With rails it just works, but now
that I want to use rspec outside of rails, I couldn't find what I
really need to do easily and I may have jumped to conclusions...

On Feb 16, 2008 11:07 AM, Ivo Dancet <ivo.dancet@gmail.com> wrote:
> > What mislead you to believe such a thing?
>
> such a thing as in: rspec in rails doesn't work the way I thought, or
> as in: why would it work the same way or as in: 'naming convention?
> there is no such thing'!
>
> I guess the answer on all three possibilities is: I don't really know
> much about the internals of rspec... I'm working with it for about two
> months now and I really love it. With rails it just works, but now
> that I want to use rspec outside of rails, I couldn't find what I
> really need to do easily and I may have jumped to conclusions...

The rspec/rails plugin works because there are generators which create
the files for you, not because of any auto-loading facility. The
generated files have require statements that get you the right stuff.

We could conceivably add generators for other-than-rails apps. The
reason we have them in rails apps is because there is already a
generation facility that is easy to hook into.

If we were to add generators, how do you think they should work? Where
should they live? Part of the spec command? A new shell command? A
separate plugin?

On Sat, 16 Feb 2008 13:06:00 -0500, David Chelimsky wrote:
> should they live? Part of the spec command? A new shell command? A
> separate plugin?
> 

I would think just have the spec_helper.rb file for the specs try to 
load
config/rspec.rb or something along those lines. Similar to how rspec for
rails just loads the rails env. It would then be up to the user to do 
the
necessary loading in that file. There's really no way to know what crazy
way someone might layout their projects.

Steve

Op 16-feb-08, om 19:26 heeft Steve het volgende geschreven:

>>
> rails just loads the rails env. It would then be up to the user to  
> do the
> necessary loading in that file. There's really no way to know what  
> crazy
> way someone might layout their projects.
>
> Steve

I second that. On the other side, autotest makes some assumptions
about the layout of a project (that's how things got mixed up for me),
why shouldn't rspec use the same conventions (and still keep the
possibility to override conventions in config/rspec). Or it doesn't
use conventions but it has a generator that makes a config/rspec file
with some standard config in it.

On Feb 16, 2008 1:56 PM, Ivo Dancet <ivo.dancet@gmail.com> wrote:
> >> We could conceivably add generators for other-than-rails apps. The
> > load
> I second that. On the other side, autotest makes some assumptions
> about the layout of a project (that's how things got mixed up for me),
> why shouldn't rspec use the same conventions (and still keep the
> possibility to override conventions in config/rspec). Or it doesn't
> use conventions but it has a generator that makes a config/rspec file
> with some standard config in it.
>

I'd be more open to generators than convention-enforcement. The 1-1
mapping promoted by autotest is a very good convention, but is often
abused. This is something we discussed a lot in RSpec's early days.

As for generators, there are several project-bootstrapping gems out
there these days like newgem, mr bones, hoe that will set up a project
w/ the basic directories and all the files including the right stuff.
Hoe doesn't support rspec out of the box, but newgem and mr bones do.
So maybe we don't need one built into RSpec?

> I would think just have the spec_helper.rb file for the specs try to load
> config/rspec.rb or something along those lines. Similar to how rspec for
> rails just loads the rails env. It would then be up to the user to do the
> necessary loading in that file. There's really no way to know what crazy
> way someone might layout their projects.

+1. Something along the lines

require File.join(File.dirname(__FILE__), 'config.rb') if
File.exist?('config.rb')

would be sufficient, no?

--
"One day, when he was naughty, Mr Bunnsy looked over the hedge into
Farmer Fred's field and it was full of fresh green lettuces. Mr
Bunnsy, however, was not full of lettuces. This did not seem fair."
  -- Terry Pratchett, Mr. Bunnsy Has An Adventure