rspec users - Aug 2007 - howto regressions on environment.rb in Rails projects

How would one write a spec on environment.rb in a rails app?

I was requiring a gem in environment.rb, but received a  
"MissingSourceError".  Generally, ruby raises a LoadError when it  
can''t find a gem, but rails overrides this to raise a  
MissingSourceError (since rails is expecting a required file to be in  
lib/...).  How would I write a spec to override this behavior, such  
that a more friendly error message would be raised (such as:  
LoadError, "you must install the xyz gem!") ?

Regards,

Scott

Seems that the assertion itself is just obvious

lambda { ... }.should_not raise_error ...

But given the fact environment.rb is loaded well before examples are 
run, is it worth the effort it may take to spec out Rails bootstrap process?

Sorry if I do not get your question.

Scott Taylor wrote:
> How would one write a spec on environment.rb in a rails app?
> 
> I was requiring a gem in environment.rb, but received a  
> "MissingSourceError".  Generally, ruby raises a LoadError when it
> can''t find a gem, but rails overrides this to raise a  
> MissingSourceError (since rails is expecting a required file to be in  
> lib/...).  How would I write a spec to override this behavior, such  
> that a more friendly error message would be raised (such as:  
> LoadError, "you must install the xyz gem!") ?
--
MK

On Aug 26, 2007, at 7:22 PM, Michael Klishin wrote:
> Seems that the assertion itself is just obvious
>
> lambda { ... }.should_not raise_error ...
>
> But given the fact environment.rb is loaded well before examples are
> run, is it worth the effort it may take to spec out Rails bootstrap  
> process?
No, it probably isn''t.  I just like to do everything test-first : )

Scott

Hi BDDers

Quick background: I''m working on the Hobo plugin for Rails which,  
amongst many things, automates a great deal of controller code for you.

Hobo has a built in security mechanism, and the generic controller  
uses this to ensure that POSTs and PUTs only change the DB in ways  
you''ve permitted.

I''m writing some rspec examples that test for holes in this security  
mechanism. My feeling is that this really is testing rather than  
specifying. I don''t want to use mocks/stubs because I want to be  
absolutely sure that changes have not happened to the DB.

For example, with stubs, I might say "Post.save should not be  
called", but there are other paths through AR that can result in that  
post being inserted into the DB. So I really want to say

   Post.find_by_title("test post").should == nil

(where Post is the real thing, not a mock/stub)

And my questions are.....

This is clearly not a spec as such, or a unit test. What is it? A  
functional test? An integration test?

Where then does it belong?

Should I be using rspec at all? (I want to because I spec other parts  
of Hobo and the whole rspec environment is step up and ready to go)

(Note that I don''t have any problems here as such - I''m
writing these
tests in rspec style and it''s all working fine. I''m just
fearful of
what the BDDPD might say if they catch me! Well really I''m just  
curious as to what "good form" would be)

Thanks muchly

-Tom

On 8/31/07, Tom Locke <tom at hobocentral.net>
wrote:
> Hi BDDers
>
> Quick background: I''m working on the Hobo plugin for Rails which,
> amongst many things, automates a great deal of controller code for you.
>
> Hobo has a built in security mechanism, and the generic controller
> uses this to ensure that POSTs and PUTs only change the DB in ways
> you''ve permitted.
>
> I''m writing some rspec examples that test for holes in this
security
> mechanism. My feeling is that this really is testing rather than
> specifying. I don''t want to use mocks/stubs because I want to be
> absolutely sure that changes have not happened to the DB.
>
> For example, with stubs, I might say "Post.save should not be
> called", but there are other paths through AR that can result in that
> post being inserted into the DB. So I really want to say
>
>    Post.find_by_title("test post").should == nil
>
> (where Post is the real thing, not a mock/stub)
>
> And my questions are.....
>
> This is clearly not a spec as such, or a unit test. What is it? A
> functional test? An integration test?
>
> Where then does it belong?
>
> Should I be using rspec at all? (I want to because I spec other parts
> of Hobo and the whole rspec environment is step up and ready to go)
>
> (Note that I don''t have any problems here as such - I''m
writing these
> tests in rspec style and it''s all working fine. I''m just
fearful of
> what the BDDPD might say if they catch me! Well really I''m just
> curious as to what "good form" would be)
The subject of this thread says it all: ''testing for
confidence''.
That''s what all of this is about. It''s all about YOU, the
developer,
feeling confidence to take the next step. Driving with examples, if
done with discipline, means you automatically get 100% code coverage.
That gives you a lot of confidence to make a change, because you''re
sure to get feedback if you screw it up.

Since these have a different feel in your mind, I''d certainly consider
moving them to their own directory. You might consider the new Story
Runner (trunk only, so far), that is designed to be more customer
facing and in direct support of requirements, running things end to
end (no mocks). The Story Runner comes from RBehave - so you can see
what it looks like here:
http://dannorth.net/2007/06/introducing-rbehave.

If you were doing a BDD project (kind of like an XP project), you''d
have User Stories that say specific things about security, and you''d
represent them in Story Runner. Then you''d deal with the individual
objects using the Example Runner (i.e. describe it). In that world,
you''d use mocks to isolate things. Although, even that tends to be
abused. The most visible model is Rails, which couples everything
together so much that you have to use mock models to avoid hitting the
DB from your view specs. But in non-rails projects, it''s quite common
for mocks to appear and disappear in process - using them as discovery
tools, but then using the real objects as they appear. You can read
more about that at http://mockobjects.com.

Hope this all helps.

Cheers,
David
co-Captain
BDDPD
>
> Thanks muchly
>
> -Tom
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>