[rspec-users] Mocking and stubbing Rails' association extensions
rick.denatale at gmail.com
Thu Jan 10 14:19:05 EST 2008
On 1/10/08, Chris Kampmeier <chris at kampers.net> wrote:
> On 1/10/08, David Chelimsky <dchelimsky at gmail.com> wrote:
> > album = mock("album")
> > songs = mock("songs")
> > album.stub!(:songs).and_return(songs)
> > songs.stub!(:streamable).and_return(true)
> > That's the general idea. Specifics will vary for each example.
> If I do this, I end up with a mock object when I call @album.songs. I need
> that object to act like a Rails association -- so it should respond to
> #each, #first, and all our other Enumerable friends, since my view iterates
> over it, as well as the stubbed call to #streamable, which returns a
> "filtered" version of the assocation (see Rails code in OP). But I certainly
> don't want to start stubbing Enumerable methods.
> # Let's say song1, song2, and song3 are instances of Song.
> # Song has a boolean attribute, streamable.
> # song1.streamable? => true
> # song2.streamable? => true
> # song3.streamable? => false
> album = mock("album")
> songs = mock("songs")
> songs.stub!(:streamable).and_return([song1, song2])
> So now album.songs.streamable returns [song1, song2] -- perfect. But I need
> album.songs to return [song1, song2, song3] as well. That's the problem.
So why not
songs = [song1, song2, song3]
My blog on Ruby
More information about the rspec-users