rspec users - Jul 2009 - My very fist spec file (not sure what's wrong..)

Hey Everyone,

I am finally to the point in the rspec book where it describes how to
implement controller specs, so I thought what the heck, I''ll give it a
try. I have an app I have been working on (Inside out) that I needed
to get test specs written for before I continue on with the app. Now
that I have read enough of the book I realize I was doing things a
little backwards in the "rspec" sense of BDD, but I thought I would
try to apply what I have learned so far to my existing code.

Here''s the feedback I''m getting when I run my spec file....

NoMethodError in ''AccountsController POST create should build a new
account''
You have a nil object when you didn''t expect it!
You might have expected an instance of ActiveRecord::Base.
The error occurred while evaluating nil.save
/Users/Chris/Rails/obilling/app/controllers/accounts_controller.rb:
24:in `create''
./spec/controllers/accounts_controller_spec.rb:7:
script/spec:10:


Here''s my spec file...

require File.expand_path(File.dirname(__FILE__) +
''/../spec_helper'' )

describe AccountsController, "POST create" do

it "should build a new account"  do
  Account.should_receive(:new).with("address" => "1201
washington
street")
  post :create, :account => {"address" => "1201 washington
street"}
end


Here''s the create method in my accounts_controller...

def create
    @account = Account.new(params[:account])
     if @account.save
      flash[:notice] = ''Account Record Saved''

    redirect_to(:action=>''edit'', :id => @account)
    else
      flash[:warning] = ''Account Record Did Not Save!''
           render :action => ''new''

    end
  end


Keep in mind I''m a noob to everything (except programming). I have
been reading my brains out trying to get a better grasp on the ruby
syntax and how to apply this to rspec and rails. If someone has a
moment to explain this error. I understand that the @account instance
variable is "nil" in the error, but I don''t understand why.
I''m sure
it has something to do with -- post :create, :account => {"address"
=>
"1201 washington street"}. It must be a syntax problem, or the way
I''m
defining :account.

Thanks!

Chris

Chris Sund wrote:
> Hey Everyone,
>
> I am finally to the point in the rspec book where it describes how to
> implement controller specs, so I thought what the heck, I''ll give
it a
> try. I have an app I have been working on (Inside out) that I needed
> to get test specs written for before I continue on with the app. Now
> that I have read enough of the book I realize I was doing things a
> little backwards in the "rspec" sense of BDD, but I thought I
would
> try to apply what I have learned so far to my existing code.
>
> Here''s the feedback I''m getting when I run my spec
file....
>
> NoMethodError in ''AccountsController POST create should build a
new
> account''
> You have a nil object when you didn''t expect it!
> You might have expected an instance of ActiveRecord::Base.
> The error occurred while evaluating nil.save
> /Users/Chris/Rails/obilling/app/controllers/accounts_controller.rb:
> 24:in `create''
> ./spec/controllers/accounts_controller_spec.rb:7:
> script/spec:10:
>
>
> Here''s my spec file...
>
> require File.expand_path(File.dirname(__FILE__) +
''/../spec_helper'' )
>
> describe AccountsController, "POST create" do
>
> it "should build a new account"  do
>   Account.should_receive(:new).with("address" => "1201
washington
> street")
>   
This is your problem.. you need to return something for ''save''
to be
called on.  i.e.

  Account.should_receive(:new).with("address" => "1201
washington
street").and_return(mock_model(Accrount))

Notice the "and_return" at the end?  That way a mock_model of Account
will be returned from the new call so that the controller can set it to @account
and save it.

To see some examples of RSpec controller specs you can use a generator to
general rspec scaffolding... like so:

./script/generate rspec_scaffold Account

HTH,
Ben

On Mon, Jul 20, 2009 at 11:05 PM, Chris
Sund<chris at silhouettesolutions.net> wrote:
>
> I am finally to the point in the rspec book where it describes how to
> implement controller specs, so I thought what the heck, I''ll give
it a
> try.
Heh.  Points to you for ambition!  You might not have realized this
(because the RSpec book makes it sound like it should *all* be easy)
but starting with a Rails controller spec for your very first spec is
a bit like saying "I was thinking of getting scuba certified...
Ooooh, CAVE DIVING!  Let''s start with that first!"*

On the upside, if you start there and really get to *understand*
what''s going on, you should be relieved when most of the rest of it is
pretty smooth sailing.  There are very few common Ruby idioms that
have such tight coupling as Rails controllers, so very few tasks are
so hard to spec in isolation.  You''ll almost never have to mock
anything else as ferociously.  Model specs in particular will feel
like sunshine and puppies.

So go you!


--
Have Fun,  *(Granted, I don''t think anyone has ever kicked up silt
while writing a controller spec, lost hold of their guide line, gotten
hopelessly lost, and died many hours later in the cold and dark.  Yet.
 That only happens to J2EE programmers.)
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

Ben that worked perfectly I appreciate the help.

Stephen, I appreciate the encouragement, it feels daunting to be
learning all of this at once, but each day I bite off a little more
understanding.  It''s funny you mention scuba diving - "way back
when"
right out of high school I thought it would be fun to go to school for
underwater construction/welding - so I did. I suppose if I was able to
tackle that, I will eventually get this. I''m thankful I decided to
switch my degree path to computer science after that however. It was
an interesting part of my life to say the least. Maybe it''s a
personality quirk of mine :-)

Thanks!

Chris


On Jul 20, 9:59?pm, Stephen Eley <sfe... at gmail.com>
wrote:
> On Mon, Jul 20, 2009 at 11:05 PM, Chris
>
> Sund<ch... at silhouettesolutions.net> wrote:
>
> > I am finally to the point in the rspec book where it describes how to
> > implement controller specs, so I thought what the heck, I''ll
give it a
> > try.
>
> Heh. ?Points to you for ambition! ?You might not have realized this
> (because the RSpec book makes it sound like it should *all* be easy)
> but starting with a Rails controller spec for your very first spec is
> a bit like saying "I was thinking of getting scuba certified...
> Ooooh, CAVE DIVING! ?Let''s start with that first!"*
>
> On the upside, if you start there and really get to *understand*
> what''s going on, you should be relieved when most of the rest of
it is
> pretty smooth sailing. ?There are very few common Ruby idioms that
> have such tight coupling as Rails controllers, so very few tasks are
> so hard to spec in isolation. ?You''ll almost never have to mock
> anything else as ferociously. ?Model specs in particular will feel
> like sunshine and puppies.
>
> So go you!
>
> --
> Have Fun, ?*(Granted, I don''t think anyone has ever kicked up silt
> while writing a controller spec, lost hold of their guide line, gotten
> hopelessly lost, and died many hours later in the cold and dark. ?Yet.
> ?That only happens to J2EE programmers.)
> ? ?Steve Eley (sfe... at gmail.com)
> ? ?ESCAPE POD - The Science Fiction Podcast Magazine
> ? ?http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

I have one additional question after thinking about this for a while.
Forgive me if I''m about to read this in the book, It came to mind so I
thought I would ask. When writing specs for controllers am I always
going to mock the model? Are controllers always isolated from the
actual model? If that''s the case then using cucumber with webrat is
the only time I will test the complete stack right? Just wondering if
I understand this correctly.

Thanks

Chris

On Jul 21, 9:25?am, internetchris <ch... at silhouettesolutions.net>
wrote:
> Ben that worked perfectly I appreciate the help.
>
> Stephen, I appreciate the encouragement, it feels daunting to be
> learning all of this at once, but each day I bite off a little more
> understanding. ?It''s funny you mention scuba diving - "way
back when"
> right out of high school I thought it would be fun to go to school for
> underwater construction/welding - so I did. I suppose if I was able to
> tackle that, I will eventually get this. I''m thankful I decided to
> switch my degree path to computer science after that however. It was
> an interesting part of my life to say the least. Maybe it''s a
> personality quirk of mine :-)
>
> Thanks!
>
> Chris
>
> On Jul 20, 9:59?pm, Stephen Eley <sfe... at gmail.com> wrote:
>
>
>
> > On Mon, Jul 20, 2009 at 11:05 PM, Chris
>
> > Sund<ch... at silhouettesolutions.net> wrote:
>
> > > I am finally to the point in the rspec book where it describes
how to
> > > implement controller specs, so I thought what the heck,
I''ll give it a
> > > try.
>
> > Heh. ?Points to you for ambition! ?You might not have realized this
> > (because the RSpec book makes it sound like it should *all* be easy)
> > but starting with a Rails controller spec for your very first spec is
> > a bit like saying "I was thinking of getting scuba certified...
> > Ooooh, CAVE DIVING! ?Let''s start with that first!"*
>
> > On the upside, if you start there and really get to *understand*
> > what''s going on, you should be relieved when most of the rest
of it is
> > pretty smooth sailing. ?There are very few common Ruby idioms that
> > have such tight coupling as Rails controllers, so very few tasks are
> > so hard to spec in isolation. ?You''ll almost never have to
mock
> > anything else as ferociously. ?Model specs in particular will feel
> > like sunshine and puppies.
>
> > So go you!
>
> > --
> > Have Fun, ?*(Granted, I don''t think anyone has ever kicked up
silt
> > while writing a controller spec, lost hold of their guide line, gotten
> > hopelessly lost, and died many hours later in the cold and dark. ?Yet.
> > ?That only happens to J2EE programmers.)
> > ? ?Steve Eley (sfe... at gmail.com)
> > ? ?ESCAPE POD - The Science Fiction Podcast Magazine
> > ? ?http://www.escapepod.org
> > _______________________________________________
> > rspec-users mailing list
> > rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

internetchris wrote:
> I have one additional question after thinking about this for a while.
> Forgive me if I''m about to read this in the book, It came to mind
so I
> thought I would ask. When writing specs for controllers am I always
> going to mock the model? Are controllers always isolated from the
> actual model? If that''s the case then using cucumber with webrat
is
> the only time I will test the complete stack right? Just wondering if
> I understand this correctly.
>   
When I am using Cucumber and writing controller specs that is always how 
*I* do it.  I like having the isolation for the controllers and keeping 
them fast.  Any integration problems will be exposed by Cucumber so I 
think having the controller specs test more that the controller is a 
waste in most cases.  This is just my opinion however.  People on this 
list will agree with me and disagree, so don''t think that it is *the* 
way of doing things.  This is what the book recommends IIRC so you are 
understanding it.

-Ben
> Thanks
>
> Chris
>
> On Jul 21, 9:25 am, internetchris <ch... at silhouettesolutions.net>
> wrote:
>   
>> Ben that worked perfectly I appreciate the help.
>>
>> Stephen, I appreciate the encouragement, it feels daunting to be
>> learning all of this at once, but each day I bite off a little more
>> understanding.  It''s funny you mention scuba diving -
"way back when"
>> right out of high school I thought it would be fun to go to school for
>> underwater construction/welding - so I did. I suppose if I was able to
>> tackle that, I will eventually get this. I''m thankful I
decided to
>> switch my degree path to computer science after that however. It was
>> an interesting part of my life to say the least. Maybe it''s a
>> personality quirk of mine :-)
>>
>> Thanks!
>>
>> Chris
>>
>> On Jul 20, 9:59 pm, Stephen Eley <sfe... at gmail.com> wrote:
>>
>>
>>
>>     
>>> On Mon, Jul 20, 2009 at 11:05 PM, Chris
>>>       
>>> Sund<ch... at silhouettesolutions.net> wrote:
>>>       
>>>> I am finally to the point in the rspec book where it describes
how to
>>>> implement controller specs, so I thought what the heck,
I''ll give it a
>>>> try.
>>>>         
>>> Heh.  Points to you for ambition!  You might not have realized this
>>> (because the RSpec book makes it sound like it should *all* be
easy)
>>> but starting with a Rails controller spec for your very first spec
is
>>> a bit like saying "I was thinking of getting scuba
certified...
>>> Ooooh, CAVE DIVING!  Let''s start with that first!"*
>>>       
>>> On the upside, if you start there and really get to *understand*
>>> what''s going on, you should be relieved when most of the
rest of it is
>>> pretty smooth sailing.  There are very few common Ruby idioms that
>>> have such tight coupling as Rails controllers, so very few tasks
are
>>> so hard to spec in isolation.  You''ll almost never have to
mock
>>> anything else as ferociously.  Model specs in particular will feel
>>> like sunshine and puppies.
>>>       
>>> So go you!
>>>       
>>> --
>>> Have Fun,  *(Granted, I don''t think anyone has ever kicked
up silt
>>> while writing a controller spec, lost hold of their guide line,
gotten
>>> hopelessly lost, and died many hours later in the cold and dark. 
Yet.
>>>  That only happens to J2EE programmers.)
>>>    Steve Eley (sfe... at gmail.com)
>>>    ESCAPE POD - The Science Fiction Podcast Magazine
>>>    http://www.escapepod.org
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>>>       
>> _______________________________________________
>> rspec-users mailing list
>> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users
>>     
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

2009/7/21 internetchris <chris at
silhouettesolutions.net>:
> When writing specs for controllers am I always
> going to mock the model? Are controllers always isolated from the
> actual model?
Hi Chris,

Pretty insightful of you.  This is one of those philosophical
questions that tends to keep coming up.  The only valid answer to it
is "YMMV" -- everyone seems to have a different comfort level with how
this is done.

David Chelimsky advocates strong isolation and full model mocking for
controller specs.  That''s why you see it in the RSpec book and the
official RSpec site.  Yehuda Katz pushes a more integrated approach of
spec''ing the *request* from soup to nuts rather than the
controller''s
code base; you can see that in Merb''s testing helpers, or in this
video from last year''s RubyConf:
http://rubyconf2008.confreaks.com/writing-code-that-doesnt-suck.html

Both schools of thought have pros and cons, and both camps have their
followers.  And then some people take an approach somewhere in the
middle, or use Cucumber exclusively, or use macro frameworks like
Shoulda or mock_resourceful, or do their own thing, or just throw up
their hands and don''t test controller flow at all.

Having said that -- I''ll tell you what *I* do.  I used to spec
everything.  When I was learning RSpec I was quite zealous about it,
and I think that was a good experence. These days, though, I skip
specs for most of my controllers and declare the integration in
Cucumber features instead. I won''t say that I *never* write controller
specs, but if I do it''s usually because that controller does something
unusual.  Maybe it pulls in a couple of different models, or it needs
to reply to "/login" instead of the default
"person_sessions/new" or
it has a filter to load tabs.  I''ll spec that sort of interesting
behavior.  If it''s just a straight, looks-like-scaffold-code REST
controller, I usually don''t spec it.  And I certainly don''t
write
stubs for it.

My typical feeling is that all that stubbing to set up controller
isolation is a lot of work for small risk.  90% of all Rails
controllers are pretty nearly identical to each other, and the "cookie
cutter" RESTful controller model is simple, well-understood and
thoroughly tested in the Rails core code.  If it does break on me it''s
probably because I made some sort of dependency error, like forgetting
to declare the route or using the wrong path in my views.  That sort
of thing turns up in my integration testing (i.e. my Cucumber
features) and is always pretty easy to spot and fix.  I don''t really
gain anything by writing specs for generic execution paths that are
already tested in Rails itself.

That''s my approach.  I''m not going to claim it''s the
_best_ -- just
that it''s where my comfort level is right now.  The way I do things
has changed before, and it will probably change again.  You''ll find
your own way of doing things too; and that''s a Good Thing.

In the meantime, you can''t really lose by following the steps from the
RSpec Book as you''re starting out.  Even if you do decide that
it''s
too much overhead later on, having had the practice and developed the
discipline will help you to make smart decisions and develop your own
effective style.



-- 
Have Fun,
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org

Hey guys,

I appreciate the insight, and this brings me to my next question, and
actually the next chapter in the book (specing models). I read that
"most" developers shy away from view specs (for the most part - not
always), and then if I understand both of you correctly....each of you
tend to "do as little" with controller specs as absolutely necessary.
So if that''s the case is the main use of rspec within a rails app for
the model and validation testing? I''m sure I will gain a little more
insight on this as I progress into the next chapter, but it begged to
be asked. In fact it''s probably too much of a sweeping statement. As I
think about this a little more I can see how each of these "little"
things that rspec is used for add up to some major tools to help
ensure good solid code. Just the re-factoring element which is more a
philosophy than it is an actual syntactical element makes for nice DRY
systems.

I guess this is more of a rhetorical post, but if someone wants to add
their two cents go ahead. I have been taking my time through the Rspec
book making sure I understand each element. I''m forcing myself to
"really" understand it so I can develop better apps.

Thanks again!

Chris



On Jul 21, 9:43?pm, Stephen Eley <sfe... at gmail.com>
wrote:
> 2009/7/21 internetchris <ch... at silhouettesolutions.net>:
>
> > When writing specs for controllers am I always
> > going to mock the model? Are controllers always isolated from the
> > actual model?
>
> Hi Chris,
>
> Pretty insightful of you. ?This is one of those philosophical
> questions that tends to keep coming up. ?The only valid answer to it
> is "YMMV" -- everyone seems to have a different comfort level
with how
> this is done.
>
> David Chelimsky advocates strong isolation and full model mocking for
> controller specs. ?That''s why you see it in the RSpec book and the
> official RSpec site. ?Yehuda Katz pushes a more integrated approach of
> spec''ing the *request* from soup to nuts rather than the
controller''s
> code base; you can see that in Merb''s testing helpers, or in this
> video from last year''s
RubyConf:http://rubyconf2008.confreaks.com/writing-code-that-doesnt-suck.html
>
> Both schools of thought have pros and cons, and both camps have their
> followers. ?And then some people take an approach somewhere in the
> middle, or use Cucumber exclusively, or use macro frameworks like
> Shoulda or mock_resourceful, or do their own thing, or just throw up
> their hands and don''t test controller flow at all.
>
> Having said that -- I''ll tell you what *I* do. ?I used to spec
> everything. ?When I was learning RSpec I was quite zealous about it,
> and I think that was a good experence. These days, though, I skip
> specs for most of my controllers and declare the integration in
> Cucumber features instead. I won''t say that I *never* write
controller
> specs, but if I do it''s usually because that controller does
something
> unusual. ?Maybe it pulls in a couple of different models, or it needs
> to reply to "/login" instead of the default
"person_sessions/new" or
> it has a filter to load tabs. ?I''ll spec that sort of interesting
> behavior. ?If it''s just a straight, looks-like-scaffold-code REST
> controller, I usually don''t spec it. ?And I certainly
don''t write
> stubs for it.
>
> My typical feeling is that all that stubbing to set up controller
> isolation is a lot of work for small risk. ?90% of all Rails
> controllers are pretty nearly identical to each other, and the "cookie
> cutter" RESTful controller model is simple, well-understood and
> thoroughly tested in the Rails core code. ?If it does break on me
it''s
> probably because I made some sort of dependency error, like forgetting
> to declare the route or using the wrong path in my views. ?That sort
> of thing turns up in my integration testing (i.e. my Cucumber
> features) and is always pretty easy to spot and fix. ?I don''t
really
> gain anything by writing specs for generic execution paths that are
> already tested in Rails itself.
>
> That''s my approach. ?I''m not going to claim it''s
the _best_ -- just
> that it''s where my comfort level is right now. ?The way I do
things
> has changed before, and it will probably change again. ?You''ll
find
> your own way of doing things too; and that''s a Good Thing.
>
> In the meantime, you can''t really lose by following the steps from
the
> RSpec Book as you''re starting out. ?Even if you do decide that
it''s
> too much overhead later on, having had the practice and developed the
> discipline will help you to make smart decisions and develop your own
> effective style.
>
> --
> Have Fun,
> ? ?Steve Eley (sfe... at gmail.com)
> ? ?ESCAPE POD - The Science Fiction Podcast Magazine
> ? ?http://www.escapepod.org
> _______________________________________________
> rspec-users mailing list
> rspec-us... at
rubyforge.orghttp://rubyforge.org/mailman/listinfo/rspec-users

2009/7/22 internetchris <chris at
silhouettesolutions.net>:
>
> So if that''s the case is the main use of rspec within a rails app
for
> the model and validation testing?
For a lot of people, yes.  It''s certainly a fair generalization that
model specs are the easiest and most straightforward specs in Rails.
If you''re applying MVC well, most of the "interesting" stuff
should be
in the models anyway -- that''s where your business logic ought to
live.  The fundamental work that gives your app a reason to exist.  It
so happens that business rules are also easier to specify than HTML
interfaces (views) or interface setup and dispatching code
(controllers).  So it tends to attract more testing focus.

There are a lot of ways to strike a good balance, though.  And adding
Cucumber and Webrat (and maybe Selenium, Celerity, Javascript test
frameworks, etc.) to the mix makes for even more variations.  "There
are nine-and sixty ways of constructing tribal lays..."

Best of luck to you.


Have Fun, ("And--every--single--one--of--them--is--RIGHT!")
   Steve Eley (sfeley at gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org