[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...
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
> > I'm confused about that since I am calling Account.new in the create
> > 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:
> 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>
> >> 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
> >> > 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:
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rspec-users