[rspec-users] Attempting to Make Sense of RSpec use

Tiffani Ashley Bell tiffani2k3 at gmail.com
Sat Jul 5 17:56:05 EDT 2008


Thanks on the reminder that "new" is a class method.  Plus, I figured using
mocks and fixtures together was probably a crappy idea.  I'll be mocking
from now on...

--Tiffani AB

On Sat, Jul 5, 2008 at 5:00 PM, Steve Eley <steve at deepsalt.com> wrote:

> On Sat, Jul 5, 2008 at 3:50 PM, Tiffani Ashley Bell
> <tiffani2k3 at gmail.com> wrote:
> >
> > When I run the tests the third test fails and RSpec complains that "Mock
> > 'Account_1003' expected :new with (any args) once, but received it 0
> times"
> >
> > I'm confused about that since I am calling Account.new in the create
> method
> > on the controller.  What's really wrong here?
>
> The problem there is that Account.new is a _class_ method on the
> Account class.  The @mock_account you made is an _instance_ of Account
> (actually, not even that, it's a mock object that will pretend it's an
> Account if you ask it).  You're not sending @mock_account any
> messages, you're sending them to the Account class.  To do what you
> want, you need to stub that class, for instance:
>
> Account.stub!(:new).and_return(@mock_account)
>
> And in the spec you can do Account.should_receive(:new).
>
> There's some other stuff in that spec that looks a bit messy...
> Generally speaking, you can do some pretty clean tests with fixtures
> *or* you can do tests by mocking everything, but it's not a great idea
> to do both at the same time.  In controller specs, best practice is
> usually to mock your models and not touch the real models or the
> database (i.e. fixtures) at all, because A.) it's faster and B.)
> you're isolating your tests to *just* the controller code, and won't
> have to worry about tests failing because the models are broken.
> (That's what the model specs are for.)  >8->
>
> I'm also unclear on the relationship between User and Account in this
> code, and why you're creating a new account for every new user in the
> UsersController...  But that's really about your application, not
> about RSpec.  If that's how your application needs to behave, then
> your spec here seems to be on the right track.
>
> I hope this was helpful.  I'm just figuring a lot of this out myself,
> and my main reason for answering you was to reinforce this stuff in my
> _own_ mind.  >8->
>
>
>
>
> >
> > Thanks in advance for answering my RSpec questions! :D
> >
> > --Tiffani AB
> >
> >
> > On Thu, Jul 3, 2008 at 9:09 PM, Mikel Lindsaar <raasdnil at gmail.com>
> wrote:
> >>
> >> On Fri, Jul 4, 2008 at 8:32 AM, Tiffani Ashley Bell
> >> <tiffani2k3 at gmail.com> wrote:
> >> > Hi everybody,
> >>
> >> Hi Tiffany, welcome to Rspec
> >>
> >> > I was reading the Typo source code, however, and came across some code
> >> > that
> >> > I didn't know exactly how it worked.  I've noticed that in testing one
> >> > of
> >> > their controllers, they use a variable (@comments) that they don't
> >> > declare
> >> > anywhere else, yet they use it as a stand in for collections on some
> of
> >> > the
> >> > mocks.  How is that possible?  I know in the mocking documentation it
> >> > says
> >> > that you can define collaborations with other objects before those
> >> > objects
> >> > exist, but how is that working in this code?  I only ask that because
> >> > later,
> >> > you see code like this:  @comments.stub!(:build).and_return(@comment).
> >>
> >> If you have a look at the descriptions, they use :shared => true.
> >> This is a way of being DRY in RSpec (which I personally don't think is
> >> such a good idea).
> >>
> >> What the shared => true declaration allows you to do is to include
> >> that block of code elsewhere with 'it should behave like my shared
> >> code'
> >>
> >> So we have (describe "All Requests", :shared => true do)
> >>
> >> and then the next description block is:
> >>
> >> describe "General Comment Creation", :shared => true do
> >>  it_should_behave_like "All Requests"
> >>
> >> Which then includes the All Requests block (which is just a before
> >> method).
> >>
> >> The @comments variable gets declared in:
> >>
> >> @comments.stub!(:build).and_return(@comment)
> >>
> >> and then this is tied in to the Article model in the _previous_ code
> >> block like so:
> >>
> >>    @article  = mock_model(Article,
> >>                  :comments                   => @comments,
> >>                  :published_comments         => @comments,
> >>                  :add_comment                => @comment)
> >>
> >>
> >> So when you call @article.comments you get @comments as a stub back
> >> which stubs :build and returns a @comment.
> >>
> >> Ugh.
> >>
> >> This is where, in RSpec, you can dig a very fast grave.  Because
> >> you'll come back to this code in 6-12 months and be totally stuck
> >> trying to figure out what is where.
> >>
> >> I recently wrote a viewpoint on this that might help you:
> >>
> >>
> http://www.lindsaar.net/2008/6/24/tip-24-being-clever-in-specs-is-for-dummies
> >>
> >> Hope you do well with Rspec, feel free to ask more questions!
> >>
> >> --
> >> http://lindsaar.net/
> >> Rails, RSpec, Puppet and Life blog....
> >> _______________________________________________
> >> rspec-users mailing list
> >> rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
>
> --
> Have Fun,
> Steve Eley
> Deep Salt Team
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080705/00db956f/attachment-0001.html>


More information about the rspec-users mailing list