From zach.dennis at gmail.com  Tue Mar  4 20:09:31 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Tue, 4 Mar 2008 20:09:31 -0500
Subject: [rspec-devel] [Patch] Nicer RDoc template
In-Reply-To: <57c63afe0802281235w6d315f35we7f780b327f00650@mail.gmail.com>
References: <47C71745.2020407@plan99.net>
	<57c63afe0802281235w6d315f35we7f780b327f00650@mail.gmail.com>
Message-ID: <85d99afe0803041709o105034a9r1f8d151002fee10b@mail.gmail.com>

What about using Evan Weaver's Allison template?

Example:  http://blog.evanweaver.com/files/doc/fauna/allison/files/README.html

Zach


On Thu, Feb 28, 2008 at 3:35 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On Thu, Feb 28, 2008 at 2:19 PM, Hongli Lai <hongli at plan99.net> wrote:
>  > Many people agree that the default RDoc template looks pretty horrible.
>  >  With the attached, RSpec will use the 'Horo' RDoc template. I've
>  >  uploaded a demo to: http://izumi.plan99.net/rspec-horo/
>  >
>  >  The RDoc documentation generated by RubyGems will also use this template.
>
>  Please submit patches to the tracker, not the list:
>
>  http://rspec.lighthouseapp.com
>
>  I'll be glad to implement this if you do.
>
>  Thanks,
>  David
>
>  >
>  > _______________________________________________
>  >  rspec-devel mailing list
>  >  rspec-devel at rubyforge.org
>  >  http://rubyforge.org/mailman/listinfo/rspec-devel
>  >
>  _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Zach Dennis
http://www.continuousthinking.com

From hongli at plan99.net  Tue Mar  4 20:56:24 2008
From: hongli at plan99.net (Hongli Lai)
Date: Wed, 05 Mar 2008 02:56:24 +0100
Subject: [rspec-devel] [Patch] Nicer RDoc template
In-Reply-To: <85d99afe0803041709o105034a9r1f8d151002fee10b@mail.gmail.com>
References: <47C71745.2020407@plan99.net>	<57c63afe0802281235w6d315f35we7f780b327f00650@mail.gmail.com>
	<85d99afe0803041709o105034a9r1f8d151002fee10b@mail.gmail.com>
Message-ID: <47CDFDC8.1050006@plan99.net>

Zach Dennis wrote:
> What about using Evan Weaver's Allison template?
> 
> Example:  http://blog.evanweaver.com/files/doc/fauna/allison/files/README.html
> 
> Zach

I don't like his template's looks, but that's just my opinion.

From zach.dennis at gmail.com  Tue Mar  4 22:36:02 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Tue, 4 Mar 2008 22:36:02 -0500
Subject: [rspec-devel] Consolidating :steps and :steps_for for Story's
Message-ID: <85d99afe0803041936u1e73f474x25f743c6179e1129@mail.gmail.com>

Please see...

http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/324-consolidate-steps_for-and-steps-usage

I'm assuming David is auto-notified of these. When lighthouse to
supply a patch should we also ping here of the patch? If not I won't
spam everyone next time. =)

-- 
Zach Dennis
http://www.continuousthinking.com

From dchelimsky at gmail.com  Tue Mar  4 23:14:21 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 4 Mar 2008 22:14:21 -0600
Subject: [rspec-devel] Consolidating :steps and :steps_for for Story's
In-Reply-To: <85d99afe0803041936u1e73f474x25f743c6179e1129@mail.gmail.com>
References: <85d99afe0803041936u1e73f474x25f743c6179e1129@mail.gmail.com>
Message-ID: <57c63afe0803042014u41b28e3akd7db5d4d5b8bcb1f@mail.gmail.com>

On Tue, Mar 4, 2008 at 9:36 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
> Please see...
>
>  http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/324-consolidate-steps_for-and-steps-usage
>
>  I'm assuming David is auto-notified of these. When lighthouse to
>  supply a patch should we also ping here of the patch? If not I won't
>  spam everyone next time. =)

I don't get email, but I do get a feed. But it's fine if you ping this
list (rspec-devel).

Thanks for asking :)

Cheers,
David


>
>  --
>  Zach Dennis
>  http://www.continuousthinking.com
>  _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>

From michael.s.klishin.lists at gmail.com  Fri Mar  7 15:19:40 2008
From: michael.s.klishin.lists at gmail.com (Michael Klishin)
Date: Fri, 7 Mar 2008 23:19:40 +0300
Subject: [rspec-devel] Stories generator for Rails applications?
Message-ID: <c77505380803071219u182a661fm8d1907691c12f71@mail.gmail.com>

I am not sure whether RSpec stories generator exists, I could not find
one in the source so I have created my own little plugin for it.

Git:
http://github.com/michaelklishin/storygen/tree

Check it out, it is actually drop-in ready to use as one of
Spec::Rails generators.

-- 
MK

http://novemberain.com

From zach.dennis at gmail.com  Fri Mar  7 17:24:07 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Fri, 7 Mar 2008 17:24:07 -0500
Subject: [rspec-devel] Stories generator for Rails applications?
In-Reply-To: <c77505380803071219u182a661fm8d1907691c12f71@mail.gmail.com>
References: <c77505380803071219u182a661fm8d1907691c12f71@mail.gmail.com>
Message-ID: <85d99afe0803071424p582df7d1ha37b2715037e8027@mail.gmail.com>

Very cool Michael. Do you know if you can read from STDIN in your generator?

ie:
   ./script/generate rspec_story <story name> "
      As a blah
      I want to blah
      So that blah blah
   "

Zach


On Fri, Mar 7, 2008 at 3:19 PM, Michael Klishin
<michael.s.klishin.lists at gmail.com> wrote:
> I am not sure whether RSpec stories generator exists, I could not find
>  one in the source so I have created my own little plugin for it.
>
>  Git:
>  http://github.com/michaelklishin/storygen/tree
>
>  Check it out, it is actually drop-in ready to use as one of
>  Spec::Rails generators.
>
>  --
>  MK
>
>  http://novemberain.com
>  _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Zach Dennis
http://www.continuousthinking.com

From michael.s.klishin.lists at gmail.com  Fri Mar  7 18:22:23 2008
From: michael.s.klishin.lists at gmail.com (Michael Klishin)
Date: Sat, 8 Mar 2008 02:22:23 +0300
Subject: [rspec-devel] Stories generator for Rails applications?
In-Reply-To: <85d99afe0803071424p582df7d1ha37b2715037e8027@mail.gmail.com>
References: <c77505380803071219u182a661fm8d1907691c12f71@mail.gmail.com>
	<85d99afe0803071424p582df7d1ha37b2715037e8027@mail.gmail.com>
Message-ID: <c77505380803071522j4a22f5a3r328ee511fee68963@mail.gmail.com>

On 08/03/2008, Zach Dennis <zach.dennis at gmail.com> wrote:
> Very cool Michael. Do you know if you can read from STDIN in your generator?
>
>  ie:
>    ./script/generate rspec_story <story name> "
>       As a blah
>       I want to blah
>       So that blah blah
>    "
>
>  Zach

I did not know it, thanks! What you want is an interactive mode to
enter the story text file content? :)

-- 
MK

http://novemberain.com

From bryan.wheelock at gmail.com  Mon Mar 10 18:33:16 2008
From: bryan.wheelock at gmail.com (Bryan Wheelock)
Date: Mon, 10 Mar 2008 18:33:16 -0400
Subject: [rspec-devel] How to deal with has_many associations?
Message-ID: <93d1d3a50803101533l41399b23j760c635492efa2ab@mail.gmail.com>

I'm new to rSpec and I've been having a hard time working with has_many
associations and mocks.

Review has_many :descriptions

I have a Reviews_controller::show method:

def show
  @review = Review.find(params[:id])
  @review.descriptions << Description.kaizen(@review.id)
# Description.kaizen returns a Description object

  respond_to do |format|
    format.html # show.html.erb
    format.xml  { render :xml => @review }
  end
end

I've been trying to create a spec to test this association:

describe "handling GET /reviews/1" do


  before(:each) do
    @review = mock_model(Review, :id => 1 )
    @description = mock(Description,  :id => 1,
                                      :review_id => 1 )
   # this is all added in an attempt to make the has_many association work

    description_proxy = mock('association proxy')
    @review.stubs(:descriptions).and_returns(description_proxy)
    description_proxy.expects(:<<).with(@description)
  end

  def do_get
    get :show, :id => "1"
  end

  it "should be successful" do
    do_get
    response.should be_success
  end
end

When I run the spec, I get the following error:
Mock 'Review_1007' received unexpected message :stubs with (:descriptions)

I can't seem to find any examples via Google.

Why is my has_many association not being recognized?
What is the proper rSpec way to handle this?

thanks,
Bryan



-- 
The best marketing related articles are at
http://www.InstantDirectMarketing.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080310/0c6571a4/attachment.html 

From bryansray at gmail.com  Mon Mar 10 19:38:02 2008
From: bryansray at gmail.com (Bryan Ray)
Date: Mon, 10 Mar 2008 18:38:02 -0500
Subject: [rspec-devel] How to deal with has_many associations?
In-Reply-To: <93d1d3a50803101533l41399b23j760c635492efa2ab@mail.gmail.com>
References: <93d1d3a50803101533l41399b23j760c635492efa2ab@mail.gmail.com>
Message-ID: <D8957000-96B8-4313-9604-7ABEA72920DB@gmail.com>


Try this:

> before(:each) do
>     @review = mock_model(Review, :id => 1 )
>     @description = mock(Description,  :id => 1,
>                                       :review_id => 1 )
>
> 	# .descriptions should return an "Array of descriptions" ... so  
> let's make that here
> 	@descriptions = [@description]
>
> 	# This will stub out the 'descriptions' call .. after setting it  
> here, I typically find it wise to right a it "should happen"  
> statement below
> 	# This means whenever "descriptions" is called in your "show"  
> method return @descriptions
>     	@review.stubs!(:descriptions).and_returns(@descriptions)
> end

This would be another test that 'should' happen ... (read up on stubs  
vs. mocks - there is tons of information on google)

> it "should have a list of descriptions" do
> 	@review.should_receive(:descriptions).and_return(@descriptions)
> 	do_get
> end

I'm not entirely sure why you're doing creating a new  
Desription.kaizen() ... it seems to me like you would have an  
association in the Review model that would allow that to be called,  
but that's neither here nor there.

The code above should get your spec working ...

Hope this helps a little. Good luck, buddy.

On Mar 10, 2008, at 5:33 PM, Bryan Wheelock wrote:

> I'm new to rSpec and I've been having a hard time working with  
> has_many associations and mocks.
>
> Review has_many :descriptions
>
> I have a Reviews_controller::show method:
>
> def show
>   @review = Review.find(params[:id])
>   @review.descriptions << Description.kaizen(@review.id)
> 	# Description.kaizen returns a Description object
>
>   respond_to do |format|
>     format.html # show.html.erb
>     format.xml  { render :xml => @review }
>   end
> end
>
> I've been trying to create a spec to test this association:
>
> describe "handling GET /reviews/1" do
>
>
>   before(:each) do
>     @review = mock_model(Review, :id => 1 )
>     @description = mock(Description,  :id => 1,
>                                       :review_id => 1 )
>    # this is all added in an attempt to make the has_many  
> association work
>     description_proxy = mock('association proxy')
>     @review.stubs(:descriptions).and_returns(description_proxy)
>     description_proxy.expects(:<<).with(@description)
>   end
>
>   def do_get
>     get :show, :id => "1"
>   end
>
>   it "should be successful" do
>     do_get
>     response.should be_success
>   end
> end
>
> When I run the spec, I get the following error:
> Mock 'Review_1007' received unexpected message :stubs with  
> (:descriptions)
>
> I can't seem to find any examples via Google.
>
> Why is my has_many association not being recognized?
> What is the proper rSpec way to handle this?
>
> thanks,
> Bryan
>
>
>
> -- 
> The best marketing related articles are at http://www.InstantDirectMarketing.com 
>  _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080310/b15ca455/attachment-0001.html 

From michael.s.klishin.lists at gmail.com  Tue Mar 11 09:03:05 2008
From: michael.s.klishin.lists at gmail.com (Michael Klishin)
Date: Tue, 11 Mar 2008 15:03:05 +0200
Subject: [rspec-devel] Stories generator for Rails applications?
In-Reply-To: <85d99afe0803071424p582df7d1ha37b2715037e8027@mail.gmail.com>
References: <c77505380803071219u182a661fm8d1907691c12f71@mail.gmail.com>
	<85d99afe0803071424p582df7d1ha37b2715037e8027@mail.gmail.com>
Message-ID: <c77505380803110603i7fb0858fvad46999e2ce3e465@mail.gmail.com>

On 08/03/2008, Zach Dennis <zach.dennis at gmail.com> wrote:
> Very cool Michael. Do you know if you can read from STDIN in your generator?

By the way there has been a suggestion from David to think about
command line tool instead of just generator.

Created a ticket for it, WDYT?

http://rspec.lighthouseapp.com/projects/5645/tickets/334-patch-story-framework-generator-for-rails

-- 
MK

http://novemberain.com

From zach.dennis at gmail.com  Tue Mar 11 09:35:26 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Tue, 11 Mar 2008 09:35:26 -0400
Subject: [rspec-devel] Stories generator for Rails applications?
In-Reply-To: <c77505380803110603i7fb0858fvad46999e2ce3e465@mail.gmail.com>
References: <c77505380803071219u182a661fm8d1907691c12f71@mail.gmail.com>
	<85d99afe0803071424p582df7d1ha37b2715037e8027@mail.gmail.com>
	<c77505380803110603i7fb0858fvad46999e2ce3e465@mail.gmail.com>
Message-ID: <85d99afe0803110635t73c1801av51671a16f0756773@mail.gmail.com>

I'll post comments to the ticket. My MBP had some issues this past
weekend and had to be sent back to Apple. I'm on my wife's laptop
right now... otherwise I'd be much more timely with comments,

Zach

On Tue, Mar 11, 2008 at 9:03 AM, Michael Klishin
<michael.s.klishin.lists at gmail.com> wrote:
> On 08/03/2008, Zach Dennis <zach.dennis at gmail.com> wrote:
>
> > Very cool Michael. Do you know if you can read from STDIN in your generator?
>
>  By the way there has been a suggestion from David to think about
>  command line tool instead of just generator.
>
>  Created a ticket for it, WDYT?
>
>  http://rspec.lighthouseapp.com/projects/5645/tickets/334-patch-story-framework-generator-for-rails
>
>  --
>
>
> MK
>
>  http://novemberain.com
>  _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Zach Dennis
http://www.continuousthinking.com

From michael.s.klishin.lists at gmail.com  Tue Mar 11 10:23:16 2008
From: michael.s.klishin.lists at gmail.com (Michael Klishin)
Date: Tue, 11 Mar 2008 16:23:16 +0200
Subject: [rspec-devel] Stories generator for Rails applications?
In-Reply-To: <85d99afe0803110635t73c1801av51671a16f0756773@mail.gmail.com>
References: <c77505380803071219u182a661fm8d1907691c12f71@mail.gmail.com>
	<85d99afe0803071424p582df7d1ha37b2715037e8027@mail.gmail.com>
	<c77505380803110603i7fb0858fvad46999e2ce3e465@mail.gmail.com>
	<85d99afe0803110635t73c1801av51671a16f0756773@mail.gmail.com>
Message-ID: <c77505380803110723j3b184892ucd2d616290d9a39@mail.gmail.com>

On 11/03/2008, Zach Dennis <zach.dennis at gmail.com> wrote:
> I'll post comments to the ticket. My MBP had some issues this past
>  weekend and had to be sent back to Apple. I'm on my wife's laptop
>  right now... otherwise I'd be much more timely with comments,
>
>  Zach

Thank you.

I am going to work on tool that generates files under stories
directory in pwd or explicitly given path not being tied to Rails
application. Comments and feature requests are welcome :)

-- 
MK

http://novemberain.com

From james.deville at gmail.com  Wed Mar 12 00:28:09 2008
From: james.deville at gmail.com (James Deville)
Date: Tue, 11 Mar 2008 21:28:09 -0700
Subject: [rspec-devel] [Patch] Nicer RDoc template
In-Reply-To: <47CDFDC8.1050006@plan99.net>
References: <47C71745.2020407@plan99.net>	<57c63afe0802281235w6d315f35we7f780b327f00650@mail.gmail.com>
	<85d99afe0803041709o105034a9r1f8d151002fee10b@mail.gmail.com>
	<47CDFDC8.1050006@plan99.net>
Message-ID: <DED2799E-38C8-4DAD-9B35-DC123582809A@gmail.com>


On Mar 4, 2008, at 5:56 PM, Hongli Lai wrote:

> Zach Dennis wrote:
>> What about using Evan Weaver's Allison template?
>>
>> Example:  http://blog.evanweaver.com/files/doc/fauna/allison/files/README.html
>>
>> Zach
>
> I don't like his template's looks, but that's just my opinion.

His looks may not be nice (although, have you seen it since he changed  
to blue from purple), but the functionality is superior IMHO. Second  
on the Allison Template


>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

James Deville
http://devillecompanies.org
james.deville at gmail.com
rspec r3172
rspec_on_rails r3172
rails r8331





From roman.chernyatchik at jetbrains.com  Wed Mar 12 13:12:57 2008
From: roman.chernyatchik at jetbrains.com (Roman Chernyatchik)
Date: Wed, 12 Mar 2008 20:12:57 +0300
Subject: [rspec-devel] BaseFormatter.example_started(example) suspicious
	behavior
In-Reply-To: <mailman.0.1204734545.26113.rspec-devel@rubyforge.org>
References: <mailman.0.1204734545.26113.rspec-devel@rubyforge.org>
Message-ID: <001a01c88464$51755860$6bf01aac@Labs.IntelliJ.Net>

Hi guys!

I'm developing a custom formatter for RSpec(Rake Runner Plugin for TeamCity
buildserver, see draft description at
http://www.jetbrains.net/confluence/display/RUBYDEV/TeamCity+Rake+Runner).

I've noticed some problems during running tests. 

1. On RSpec project, rev.3331.
'Spec::Runner::Formatter::BaseFormatter.start'  and
'Spec::Runner::Formatter::BaseFormatter.dump_summary' methods returns
different example counts.
I.e.
'Spec::Runner::Formatter::BaseFormatter.start'  - 1255
'Spec::Runner::Formatter::BaseFormatter.dump' - 1314

2. In some cases RSpec starts example in one group and ends in other example
group.

How to reproduce:
Let's consider RSpec spec tests. You can see such behavior in html output or
by simple debug print:

E.g. in rspec/spec/spec/example/configuration_spec.rb example group

###########################
      describe "#prepend_before" do
        it "prepends the before block on all instances of the passed in
type" do
          order = []

          ...

          @example_group.it "calls prepend_before" do
          end
        
          @example_group.run
          order.should == [
            ...
          ]
        end
      end
###########################

leads to HTML output:

---------------------------
Spec::Example::Configuration#prepend_before

Special Example Group
    calls prepend_before
    prepends the before block on all instances of the passed in type
---------------------------
In fact the order of events is:

1. BaseFormatter.add_example_group : example group description =
"Spec::Example::Configuration#prepend_before"
2. BaseFormatter.example_started   : example description = "prepends the
before block on all instances of the passed in type"

3. BaseFormatter.add_example_group : example group description = "Special
Example Group"
4. BaseFormatter.example_started   : example description = "prepend_before"
5. BaseFormatter.example_passed    : example description = "calls
prepend_before"
6. BaseFormatter.example_passed    : example description = "prepends the
before block on all instances of the passed in type"

7. BaseFormatter.add_example_group : example group description =
"Spec::Example::Configuration#append_before"
....
-----------------------------
This problem can be reproduced on 1.1.3 and trunk versions.



----
Chernyatchik Roman
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"


From matt at aimonetti.net  Wed Mar 12 15:48:32 2008
From: matt at aimonetti.net (Matt Aimonetti)
Date: Wed, 12 Mar 2008 12:48:32 -0700
Subject: [rspec-devel] Fwd: Your message to rspec-users awaits moderator
	approval
In-Reply-To: <mailman.281.1205351165.25786.rspec-users@rubyforge.org>
References: <mailman.281.1205351165.25786.rspec-users@rubyforge.org>
Message-ID: <f58d8dcb0803121248i25218344w6468da17cc5a11ff@mail.gmail.com>

I recently forked the swx on rails plugin to fix few issues
http://github.com/matta/swx-ruby/tree/master

One of my problem is that RSpec totally freaks out because of the following
code:

ActionController::Base.class_eval do
    def render_with_swx(options = nil, &block)
      if options.is_a?(Hash) && options.keys.include?(:swx)
        swf_bytecode = SwxAssembler.write_swf(
                         options[:swx],
                         params[:debug],
                         SwxGateway.swx_config['compression_level'],
                         params[:url],
                         SwxGateway.swx_config['allow_domain']
                       )
        send_data(swf_bytecode, :type => 'application/swf', :filename => '
data.swf')
      else
        render_without_swx(options, &block)
      end
    end
    alias_method_chain :render, :swx
end

The problem is that rspec_on_rails subclasses render and passes 3 arguments(
rspec_on_rails/lib/spec/rails/example/controller_example_group.rb:189:in
`render' ) when the usual render method only has 2 arguments.

That's obviously a major problem for me and I was wondering if there was a
workaround that issue.


Thanks,

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080312/9e2f57d0/attachment.html 

From dchelimsky at gmail.com  Wed Mar 12 17:49:03 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 12 Mar 2008 21:49:03 +0000
Subject: [rspec-devel] Fwd: Your message to rspec-users awaits moderator
	approval
In-Reply-To: <f58d8dcb0803121248i25218344w6468da17cc5a11ff@mail.gmail.com>
References: <mailman.281.1205351165.25786.rspec-users@rubyforge.org>
	<f58d8dcb0803121248i25218344w6468da17cc5a11ff@mail.gmail.com>
Message-ID: <57c63afe0803121449v7ffe0beha5118a2af53658d9@mail.gmail.com>

On Wed, Mar 12, 2008 at 7:48 PM, Matt Aimonetti <matt at aimonetti.net> wrote:
> I recently forked the swx on rails plugin to fix few issues
> http://github.com/matta/swx-ruby/tree/master
>
> One of my problem is that RSpec totally freaks out because of the following
> code:
>
> ActionController::Base.class_eval do
>     def render_with_swx(options = nil, &block)
>       if options.is_a?(Hash) && options.keys.include?(:swx)
>         swf_bytecode = SwxAssembler.write_swf(
>                          options[:swx],
>                           params[:debug],
>                          SwxGateway.swx_config['compression_level'],
>                          params[:url],
>                          SwxGateway.swx_config['allow_domain']
>                         )
>         send_data(swf_bytecode, :type => 'application/swf', :filename =>
> 'data.swf')
>       else
>         render_without_swx(options, &block)
>       end
>     end
>      alias_method_chain :render, :swx
> end
>
> The problem is that rspec_on_rails subclasses render and passes 3 arguments(
> rspec_on_rails/lib/spec/rails/example/controller_example_group.rb:189:in
> `render' ) when the usual render method only has 2 arguments.

That's true as of 2.0, but before that it had 3 arguments.
rspec_on_rails is still supporting rails back to 1.2.3.

>
> That's obviously a major problem for me and I was wondering if there was a
> workaround that issue.

What version are you using? What you're talking about is not on line
189 in controller_example_group in HEAD.

>
>
> Thanks,
>
> -Matt
>
>
> _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>

From matt at aimonetti.net  Wed Mar 12 18:53:11 2008
From: matt at aimonetti.net (Matt Aimonetti)
Date: Wed, 12 Mar 2008 15:53:11 -0700
Subject: [rspec-devel] Fwd: Your message to rspec-users awaits moderator
	approval
In-Reply-To: <57c63afe0803121449v7ffe0beha5118a2af53658d9@mail.gmail.com>
References: <mailman.281.1205351165.25786.rspec-users@rubyforge.org>
	<f58d8dcb0803121248i25218344w6468da17cc5a11ff@mail.gmail.com>
	<57c63afe0803121449v7ffe0beha5118a2af53658d9@mail.gmail.com>
Message-ID: <f58d8dcb0803121553w76dac2b8nc4554db131cf5c5f@mail.gmail.com>

I'm talking about rspec_on_rails 1.1.3 and rails 2.0.2 however meekish
(author of the original plugin) suggested to use:

render_with_swx(*args, &block)

and that solved my problem.

Thanks for your help,

-Matt


On 3/12/08, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Wed, Mar 12, 2008 at 7:48 PM, Matt Aimonetti <matt at aimonetti.net>
wrote:
>  > I recently forked the swx on rails plugin to fix few issues
>  > http://github.com/matta/swx-ruby/tree/master
>  >
>  > One of my problem is that RSpec totally freaks out because of the
following
>  > code:
>  >
>  > ActionController::Base.class_eval do
>  >     def render_with_swx(options = nil, &block)
>  >       if options.is_a?(Hash) && options.keys.include?(:swx)
>  >         swf_bytecode = SwxAssembler.write_swf(
>  >                          options[:swx],
>  >                           params[:debug],
>  >                          SwxGateway.swx_config['compression_level'],
>  >                          params[:url],
>  >                          SwxGateway.swx_config['allow_domain']
>  >                         )
>  >         send_data(swf_bytecode, :type => 'application/swf', :filename
=>
>  > 'data.swf')
>  >       else
>  >         render_without_swx(options, &block)
>  >       end
>  >     end
>  >      alias_method_chain :render, :swx
>  > end
>  >
>  > The problem is that rspec_on_rails subclasses render and passes 3
arguments(
>  >
rspec_on_rails/lib/spec/rails/example/controller_example_group.rb:189:in
>  > `render' ) when the usual render method only has 2 arguments.
>
>
> That's true as of 2.0, but before that it had 3 arguments.
>  rspec_on_rails is still supporting rails back to 1.2.3.
>
>
>  >
>  > That's obviously a major problem for me and I was wondering if there
was a
>  > workaround that issue.
>
>
> What version are you using? What you're talking about is not on line
>  189 in controller_example_group in HEAD.
>
>  >
>  >
>  > Thanks,
>  >
>  > -Matt
>  >
>  >
>  > _______________________________________________
>  >  rspec-devel mailing list
>  >  rspec-devel at rubyforge.org
>  >  http://rubyforge.org/mailman/listinfo/rspec-devel
>  >
>  _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080312/7598d10a/attachment-0001.html 

From coreyhaines at gmail.com  Fri Mar 14 07:28:09 2008
From: coreyhaines at gmail.com (Corey Haines)
Date: Fri, 14 Mar 2008 07:28:09 -0400
Subject: [rspec-devel] have_text not doing a contains?
Message-ID: <6bdacb70803140428i33f19e22gfd4a81bf4541450d@mail.gmail.com>

We were struggling with a story yesterday, trying to be able to write
something like

Then user should see message 'Blah blah blah blah'

Then("user should see message '$msg') do |expected_text|
response.should have_text(expected_text)
end

Our main problem was that the response was just a <p>Blah blah blah
blah</p>. It just would not pass. I decided to look at the matcher for
have_text, and this is what it is:

        def matches?(response_or_text)
          @actual = response_or_text.respond_to?(:body) ?
response_or_text.body : response_or_text
          return actual =~ expected if Regexp === expected
          return actual == expected unless Regexp === expected
        end

Per the documentation,
Use this instead of response.should
have_tag<http://rspec.info/rdoc-rails/classes/Spec/Rails/Matchers.html#M000044>
() when you either don't know or don't care where on the page this text
appears.

So, my expectation was that this would do a String#include? or something
similar, rather than ==. Or, even, creating a regexp with the expected and
run it against actual.

Does this make sense? If so, I'd like to put in a ticket and take this
opportunity to learn how to submit a patch to rspec.

Also, I'd probably switch the code into something like

return (Regexp === expected) ? actual =~ expected : actual.include
?(expected)

But, of course, that's just personal style, as I think the if/unless in the
last two lines is duplicate intention.


Thoughts?
-Corey

-- 
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080314/62306ede/attachment.html 

From dchelimsky at gmail.com  Fri Mar 14 10:22:59 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 14 Mar 2008 14:22:59 +0000
Subject: [rspec-devel] have_text not doing a contains?
In-Reply-To: <6bdacb70803140428i33f19e22gfd4a81bf4541450d@mail.gmail.com>
References: <6bdacb70803140428i33f19e22gfd4a81bf4541450d@mail.gmail.com>
Message-ID: <57c63afe0803140722y2950d709ye94c07f148e70dd0@mail.gmail.com>

On Fri, Mar 14, 2008 at 11:28 AM, Corey Haines <coreyhaines at gmail.com> wrote:
> We were struggling with a story yesterday, trying to be able to write
> something like
>
> Then user should see message 'Blah blah blah blah'
>
> Then("user should see message '$msg') do |expected_text|
>  response.should have_text(expected_text)
> end
>
> Our main problem was that the response was just a <p>Blah blah blah
> blah</p>. It just would not pass. I decided to look at the matcher for
> have_text, and this is what it is:
>
>         def matches?(response_or_text)
>           @actual = response_or_text.respond_to?(:body) ?
> response_or_text.body : response_or_text
>           return actual =~ expected if Regexp === expected
>           return actual == expected unless Regexp === expected
>          end
>
> Per the documentation,
> Use this instead of response.should have_tag() when you either don't know or
> don't care where on the page this text appears.
>
> So, my expectation was that this would do a String#include? or something
> similar, rather than ==. Or, even, creating a regexp with the expected and
> run it against actual.
>
> Does this make sense? If so, I'd like to put in a ticket and take this
> opportunity to learn how to submit a patch to rspec.
>
> Also, I'd probably switch the code into something like
>
> return (Regexp === expected) ? actual =~ expected :
> actual.include?(expected)
>
> But, of course, that's just personal style, as I think the if/unless in the
> last two lines is duplicate intention.

What you request makes great sense. But ....

The only problem with adding this is that existing examples that use a
String and expect an exact match (intentionally) would then give false
positives if the string changed to something that included that
String.

My instinct is say "no go" here and improve the docs. Thoughts?

>
>
> Thoughts?
> -Corey
>
> --
> http://www.coreyhaines.com
> The Internet's Premiere source of information about Corey Haines
> _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>

From coreyhaines at gmail.com  Fri Mar 14 11:25:35 2008
From: coreyhaines at gmail.com (Corey Haines)
Date: Fri, 14 Mar 2008 11:25:35 -0400
Subject: [rspec-devel] have_text not doing a contains?
In-Reply-To: <57c63afe0803140722y2950d709ye94c07f148e70dd0@mail.gmail.com>
References: <6bdacb70803140428i33f19e22gfd4a81bf4541450d@mail.gmail.com>
	<57c63afe0803140722y2950d709ye94c07f148e70dd0@mail.gmail.com>
Message-ID: <6bdacb70803140825p506861abyd8e854754c34437e@mail.gmail.com>

We wrote a contain_text that does what I would like. I'd like to submit this
as a patch, then fix the documentation for have_text.


-Corey

On Fri, Mar 14, 2008 at 10:22 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:

> On Fri, Mar 14, 2008 at 11:28 AM, Corey Haines <coreyhaines at gmail.com>
> wrote:
> > We were struggling with a story yesterday, trying to be able to write
> > something like
> >
> > Then user should see message 'Blah blah blah blah'
> >
> > Then("user should see message '$msg') do |expected_text|
> >  response.should have_text(expected_text)
> > end
> >
> > Our main problem was that the response was just a <p>Blah blah blah
> > blah</p>. It just would not pass. I decided to look at the matcher for
> > have_text, and this is what it is:
> >
> >         def matches?(response_or_text)
> >           @actual = response_or_text.respond_to?(:body) ?
> > response_or_text.body : response_or_text
> >           return actual =~ expected if Regexp === expected
> >           return actual == expected unless Regexp === expected
> >          end
> >
> > Per the documentation,
> > Use this instead of response.should have_tag() when you either don't
> know or
> > don't care where on the page this text appears.
> >
> > So, my expectation was that this would do a String#include? or something
> > similar, rather than ==. Or, even, creating a regexp with the expected
> and
> > run it against actual.
> >
> > Does this make sense? If so, I'd like to put in a ticket and take this
> > opportunity to learn how to submit a patch to rspec.
> >
> > Also, I'd probably switch the code into something like
> >
> > return (Regexp === expected) ? actual =~ expected :
> > actual.include?(expected)
> >
> > But, of course, that's just personal style, as I think the if/unless in
> the
> > last two lines is duplicate intention.
>
> What you request makes great sense. But ....
>
> The only problem with adding this is that existing examples that use a
> String and expect an exact match (intentionally) would then give false
> positives if the string changed to something that included that
> String.
>
> My instinct is say "no go" here and improve the docs. Thoughts?
>
> >
> >
> > Thoughts?
> > -Corey
> >
> > --
> > http://www.coreyhaines.com
> > The Internet's Premiere source of information about Corey Haines
> > _______________________________________________
> >  rspec-devel mailing list
> >  rspec-devel at rubyforge.org
> >  http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080314/9a38b44c/attachment.html 

From dchelimsky at gmail.com  Fri Mar 14 11:27:38 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 14 Mar 2008 15:27:38 +0000
Subject: [rspec-devel] have_text not doing a contains?
In-Reply-To: <6bdacb70803140825p506861abyd8e854754c34437e@mail.gmail.com>
References: <6bdacb70803140428i33f19e22gfd4a81bf4541450d@mail.gmail.com>
	<57c63afe0803140722y2950d709ye94c07f148e70dd0@mail.gmail.com>
	<6bdacb70803140825p506861abyd8e854754c34437e@mail.gmail.com>
Message-ID: <57c63afe0803140827o151a76c2u98ac9bc3dec5f5fd@mail.gmail.com>

On Fri, Mar 14, 2008 at 3:25 PM, Corey Haines <coreyhaines at gmail.com> wrote:
> We wrote a contain_text that does what I would like. I'd like to submit this
> as a patch, then fix the documentation for have_text.

Looking forward to it.

Seeing as it's using #include under the hood, why don't you call it
include text? That also aligns better w/ other bits in rspec.

Cheers,
David

>
>
> -Corey
>
>
>
> On Fri, Mar 14, 2008 at 10:22 AM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
>
> >
> >
> >
> > On Fri, Mar 14, 2008 at 11:28 AM, Corey Haines <coreyhaines at gmail.com>
> wrote:
> > > We were struggling with a story yesterday, trying to be able to write
> > > something like
> > >
> > > Then user should see message 'Blah blah blah blah'
> > >
> > > Then("user should see message '$msg') do |expected_text|
> > >  response.should have_text(expected_text)
> > > end
> > >
> > > Our main problem was that the response was just a <p>Blah blah blah
> > > blah</p>. It just would not pass. I decided to look at the matcher for
> > > have_text, and this is what it is:
> > >
> > >         def matches?(response_or_text)
> > >           @actual = response_or_text.respond_to?(:body) ?
> > > response_or_text.body : response_or_text
> > >           return actual =~ expected if Regexp === expected
> > >           return actual == expected unless Regexp === expected
> > >          end
> > >
> > > Per the documentation,
> > > Use this instead of response.should have_tag() when you either don't
> know or
> > > don't care where on the page this text appears.
> > >
> > > So, my expectation was that this would do a String#include? or something
> > > similar, rather than ==. Or, even, creating a regexp with the expected
> and
> > > run it against actual.
> > >
> > > Does this make sense? If so, I'd like to put in a ticket and take this
> > > opportunity to learn how to submit a patch to rspec.
> > >
> > > Also, I'd probably switch the code into something like
> > >
> > > return (Regexp === expected) ? actual =~ expected :
> > > actual.include?(expected)
> > >
> > > But, of course, that's just personal style, as I think the if/unless in
> the
> > > last two lines is duplicate intention.
> >
> > What you request makes great sense. But ....
> >
> > The only problem with adding this is that existing examples that use a
> > String and expect an exact match (intentionally) would then give false
> > positives if the string changed to something that included that
> > String.
> >
> > My instinct is say "no go" here and improve the docs. Thoughts?
> >
> >
> > >
> > >
> > > Thoughts?
> > > -Corey
> > >
> > > --
> > > http://www.coreyhaines.com
> > > The Internet's Premiere source of information about Corey Haines
> > > _______________________________________________
> > >  rspec-devel mailing list
> > >  rspec-devel at rubyforge.org
> > >  http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
>
> --
>
> http://www.coreyhaines.com
> The Internet's Premiere source of information about Corey Haines
> _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>

From coreyhaines at gmail.com  Fri Mar 14 11:30:15 2008
From: coreyhaines at gmail.com (Corey Haines)
Date: Fri, 14 Mar 2008 11:30:15 -0400
Subject: [rspec-devel] StoryParser strips contiguous whitespace
Message-ID: <6bdacb70803140830x52ca13cci9bb423a4dcf6b910@mail.gmail.com>

http://rspec.lighthouseapp.com/projects/5645-rspec/tickets/338

I'll be working on a patch this weekend.

-Corey

-- 
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080314/b6d3eefd/attachment.html 

From coreyhaines at gmail.com  Fri Mar 14 11:30:38 2008
From: coreyhaines at gmail.com (Corey Haines)
Date: Fri, 14 Mar 2008 11:30:38 -0400
Subject: [rspec-devel] have_text not doing a contains?
In-Reply-To: <57c63afe0803140827o151a76c2u98ac9bc3dec5f5fd@mail.gmail.com>
References: <6bdacb70803140428i33f19e22gfd4a81bf4541450d@mail.gmail.com>
	<57c63afe0803140722y2950d709ye94c07f148e70dd0@mail.gmail.com>
	<6bdacb70803140825p506861abyd8e854754c34437e@mail.gmail.com>
	<57c63afe0803140827o151a76c2u98ac9bc3dec5f5fd@mail.gmail.com>
Message-ID: <6bdacb70803140830k69a30a3bja00a93fc9170016d@mail.gmail.com>

Sounds good.

On Fri, Mar 14, 2008 at 11:27 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:

> On Fri, Mar 14, 2008 at 3:25 PM, Corey Haines <coreyhaines at gmail.com>
> wrote:
> > We wrote a contain_text that does what I would like. I'd like to submit
> this
> > as a patch, then fix the documentation for have_text.
>
> Looking forward to it.
>
> Seeing as it's using #include under the hood, why don't you call it
> include text? That also aligns better w/ other bits in rspec.
>
> Cheers,
> David
>
> >
> >
> > -Corey
> >
> >
> >
> > On Fri, Mar 14, 2008 at 10:22 AM, David Chelimsky <dchelimsky at gmail.com>
> > wrote:
> >
> > >
> > >
> > >
> > > On Fri, Mar 14, 2008 at 11:28 AM, Corey Haines <coreyhaines at gmail.com>
> > wrote:
> > > > We were struggling with a story yesterday, trying to be able to
> write
> > > > something like
> > > >
> > > > Then user should see message 'Blah blah blah blah'
> > > >
> > > > Then("user should see message '$msg') do |expected_text|
> > > >  response.should have_text(expected_text)
> > > > end
> > > >
> > > > Our main problem was that the response was just a <p>Blah blah blah
> > > > blah</p>. It just would not pass. I decided to look at the matcher
> for
> > > > have_text, and this is what it is:
> > > >
> > > >         def matches?(response_or_text)
> > > >           @actual = response_or_text.respond_to?(:body) ?
> > > > response_or_text.body : response_or_text
> > > >           return actual =~ expected if Regexp === expected
> > > >           return actual == expected unless Regexp === expected
> > > >          end
> > > >
> > > > Per the documentation,
> > > > Use this instead of response.should have_tag() when you either don't
> > know or
> > > > don't care where on the page this text appears.
> > > >
> > > > So, my expectation was that this would do a String#include? or
> something
> > > > similar, rather than ==. Or, even, creating a regexp with the
> expected
> > and
> > > > run it against actual.
> > > >
> > > > Does this make sense? If so, I'd like to put in a ticket and take
> this
> > > > opportunity to learn how to submit a patch to rspec.
> > > >
> > > > Also, I'd probably switch the code into something like
> > > >
> > > > return (Regexp === expected) ? actual =~ expected :
> > > > actual.include?(expected)
> > > >
> > > > But, of course, that's just personal style, as I think the if/unless
> in
> > the
> > > > last two lines is duplicate intention.
> > >
> > > What you request makes great sense. But ....
> > >
> > > The only problem with adding this is that existing examples that use a
> > > String and expect an exact match (intentionally) would then give false
> > > positives if the string changed to something that included that
> > > String.
> > >
> > > My instinct is say "no go" here and improve the docs. Thoughts?
> > >
> > >
> > > >
> > > >
> > > > Thoughts?
> > > > -Corey
> > > >
> > > > --
> > > > http://www.coreyhaines.com
> > > > The Internet's Premiere source of information about Corey Haines
> > > > _______________________________________________
> > > >  rspec-devel mailing list
> > > >  rspec-devel at rubyforge.org
> > > >  http://rubyforge.org/mailman/listinfo/rspec-devel
> > > >
> > > _______________________________________________
> > > rspec-devel mailing list
> > > rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> >
> >
> >
> > --
> >
> > http://www.coreyhaines.com
> > The Internet's Premiere source of information about Corey Haines
> > _______________________________________________
> >  rspec-devel mailing list
> >  rspec-devel at rubyforge.org
> >  http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080314/a4c17bfe/attachment-0001.html 

From coreyhaines at gmail.com  Sat Mar 15 17:31:44 2008
From: coreyhaines at gmail.com (Corey Haines)
Date: Sat, 15 Mar 2008 17:31:44 -0400
Subject: [rspec-devel] Lots of failing tests in trunk
Message-ID: <6bdacb70803151431w1b2a17aei72c49042721073c@mail.gmail.com>

I'm starting on submitting my patch for include_text, but I'm getting 37
failures when running the rspec trunk tests.

There seems to be 'Invalid value for Integer' failures

I'm also getting ones like
expected: "C:/ruby/patches/rspec/rspec/bin/spec",
     got: "C:\\ruby\\patches\\rspec\\rspec\\bin\\spec" (using ==)

and

expected: "/foo/spec",
     got: "\\foo\\spec" (using ==)

Is it because I'm on windows? UGH!


-Corey

-- 
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080315/1fede35b/attachment.html 

From coreyhaines at gmail.com  Sat Mar 15 17:34:15 2008
From: coreyhaines at gmail.com (Corey Haines)
Date: Sat, 15 Mar 2008 17:34:15 -0400
Subject: [rspec-devel] Lots of failing tests in trunk
In-Reply-To: <6bdacb70803151431w1b2a17aei72c49042721073c@mail.gmail.com>
References: <6bdacb70803151431w1b2a17aei72c49042721073c@mail.gmail.com>
Message-ID: <6bdacb70803151434t51ef15d2s2e6dc35252b72ffd@mail.gmail.com>

Here's a pastie of my rake spec output

http://pastie.caboo.se/166160

On Sat, Mar 15, 2008 at 5:31 PM, Corey Haines <coreyhaines at gmail.com> wrote:

> I'm starting on submitting my patch for include_text, but I'm getting 37
> failures when running the rspec trunk tests.
>
> There seems to be 'Invalid value for Integer' failures
>
> I'm also getting ones like
> expected: "C:/ruby/patches/rspec/rspec/bin/spec",
>      got: "C:\\ruby\\patches\\rspec\\rspec\\bin\\spec" (using ==)
>
> and
>
> expected: "/foo/spec",
>      got: "\\foo\\spec" (using ==)
>
> Is it because I'm on windows? UGH!
>
>
> -Corey
>
> --
> http://www.coreyhaines.com
> The Internet's Premiere source of information about Corey Haines




-- 
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080315/72c5d7f0/attachment.html 

From coreyhaines at gmail.com  Sat Mar 15 18:04:51 2008
From: coreyhaines at gmail.com (Corey Haines)
Date: Sat, 15 Mar 2008 18:04:51 -0400
Subject: [rspec-devel] Lots of failing tests in trunk
In-Reply-To: <6bdacb70803151434t51ef15d2s2e6dc35252b72ffd@mail.gmail.com>
References: <6bdacb70803151431w1b2a17aei72c49042721073c@mail.gmail.com>
	<6bdacb70803151434t51ef15d2s2e6dc35252b72ffd@mail.gmail.com>
Message-ID: <6bdacb70803151504u218f441dh45edd7ba86e4075c@mail.gmail.com>

I found the other thread about this, and am following some of the
suggestions there.

-Corey

On Sat, Mar 15, 2008 at 5:34 PM, Corey Haines <coreyhaines at gmail.com> wrote:

> Here's a pastie of my rake spec output
>
> http://pastie.caboo.se/166160
>
>
> On Sat, Mar 15, 2008 at 5:31 PM, Corey Haines <coreyhaines at gmail.com>
> wrote:
>
> > I'm starting on submitting my patch for include_text, but I'm getting 37
> > failures when running the rspec trunk tests.
> >
> > There seems to be 'Invalid value for Integer' failures
> >
> > I'm also getting ones like
> > expected: "C:/ruby/patches/rspec/rspec/bin/spec",
> >      got: "C:\\ruby\\patches\\rspec\\rspec\\bin\\spec" (using ==)
> >
> > and
> >
> > expected: "/foo/spec",
> >      got: "\\foo\\spec" (using ==)
> >
> > Is it because I'm on windows? UGH!
> >
> >
> > -Corey
> >
> > --
> > http://www.coreyhaines.com
> > The Internet's Premiere source of information about Corey Haines
>
>
>
>
> --
> http://www.coreyhaines.com
> The Internet's Premiere source of information about Corey Haines
>



-- 
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080315/247f73e8/attachment.html 

From coreyhaines at gmail.com  Sat Mar 15 19:11:55 2008
From: coreyhaines at gmail.com (Corey Haines)
Date: Sat, 15 Mar 2008 19:11:55 -0400
Subject: [rspec-devel] have_text not doing a contains?
In-Reply-To: <6bdacb70803140825p506861abyd8e854754c34437e@mail.gmail.com>
References: <6bdacb70803140428i33f19e22gfd4a81bf4541450d@mail.gmail.com>
	<57c63afe0803140722y2950d709ye94c07f148e70dd0@mail.gmail.com>
	<6bdacb70803140825p506861abyd8e854754c34437e@mail.gmail.com>
Message-ID: <6bdacb70803151611p6f82ca45ted9755e3e9bffb41@mail.gmail.com>

I've created a ticket with my patch for include_text
http://rspec.lighthouseapp.com/projects/5645/tickets/343-include_text-matcher-and-updated-rdoc-for-have_text

I wasn't able to get the pre_commit tests passing, due to what I think is
the fact that I'm running on windows. I wrote specs for the matcher
(actually, changed the have_text specs), so I'm not 100% sure whether
everything is good.

Thanks.
-Corey

On Fri, Mar 14, 2008 at 11:25 AM, Corey Haines <coreyhaines at gmail.com>
wrote:

> We wrote a contain_text that does what I would like. I'd like to submit
> this as a patch, then fix the documentation for have_text.
>
>
> -Corey
>
>
> On Fri, Mar 14, 2008 at 10:22 AM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
>
> > On Fri, Mar 14, 2008 at 11:28 AM, Corey Haines <coreyhaines at gmail.com>
> > wrote:
> > > We were struggling with a story yesterday, trying to be able to write
> > > something like
> > >
> > > Then user should see message 'Blah blah blah blah'
> > >
> > > Then("user should see message '$msg') do |expected_text|
> > >  response.should have_text(expected_text)
> > > end
> > >
> > > Our main problem was that the response was just a <p>Blah blah blah
> > > blah</p>. It just would not pass. I decided to look at the matcher for
> > > have_text, and this is what it is:
> > >
> > >         def matches?(response_or_text)
> > >           @actual = response_or_text.respond_to?(:body) ?
> > > response_or_text.body : response_or_text
> > >           return actual =~ expected if Regexp === expected
> > >           return actual == expected unless Regexp === expected
> > >          end
> > >
> > > Per the documentation,
> > > Use this instead of response.should have_tag() when you either don't
> > know or
> > > don't care where on the page this text appears.
> > >
> > > So, my expectation was that this would do a String#include? or
> > something
> > > similar, rather than ==. Or, even, creating a regexp with the expected
> > and
> > > run it against actual.
> > >
> > > Does this make sense? If so, I'd like to put in a ticket and take this
> > > opportunity to learn how to submit a patch to rspec.
> > >
> > > Also, I'd probably switch the code into something like
> > >
> > > return (Regexp === expected) ? actual =~ expected :
> > > actual.include?(expected)
> > >
> > > But, of course, that's just personal style, as I think the if/unless
> > in the
> > > last two lines is duplicate intention.
> >
> > What you request makes great sense. But ....
> >
> > The only problem with adding this is that existing examples that use a
> > String and expect an exact match (intentionally) would then give false
> > positives if the string changed to something that included that
> > String.
> >
> > My instinct is say "no go" here and improve the docs. Thoughts?
> >
> > >
> > >
> > > Thoughts?
> > > -Corey
> > >
> > > --
> > > http://www.coreyhaines.com
> > > The Internet's Premiere source of information about Corey Haines
> > > _______________________________________________
> > >  rspec-devel mailing list
> > >  rspec-devel at rubyforge.org
> > >  http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
>
> --
> http://www.coreyhaines.com
> The Internet's Premiere source of information about Corey Haines
>



-- 
http://www.coreyhaines.com
The Internet's Premiere source of information about Corey Haines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080315/c845bcc0/attachment.html 

From dchelimsky at gmail.com  Tue Mar 18 09:10:40 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 18 Mar 2008 08:10:40 -0500
Subject: [rspec-devel] stub_model
Message-ID: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>

Hi all,

Over the last couple of years I've read a ton of mail from users
concerned with false positives coming from stubbing/mocking methods
that don't exist. I recently added a stub_model method for
rspec_on_rails (not yet released, available in git) which I think
mitigates this a bit. It is still in development and subject to
change, but here's how it works now.

It looks a lot like mock_model.

  stub_model(Person, :name => 'David')

But it works in a fundamentally different way: FIrst, it creates a
real instance (which means you have to create the model to use it). It
assigns it an id by default, but you can set :id => nil if you want it
to behave like a new record. It overrides new_record? so that it
behaves as you would expect (false if there is an id, true if not). It
also overrides #connection, raising an error if there is any attempt
to access the database. This gives you the db isolation you get from
mock_model, but with a real object. Kind of like unit_record, but on
an instance by instance basis.

I've been using this for a few weeks now (just introduced it to the
rspec code base a week or so ago) and I'm finding it very useful. I'm
thinking of changing the generated rails specs to use stub_model
instead of mock_model, and I'd be curious to hear your thoughts about
this.

Also - right now it checks the hash against the model's attributes. If
the model has a matching attribute it gets assigned, otherwise a stub
is created. It occurs to me that, with some modification, this *could*
be used as a bit of an auditing/red-flagging tool. So let's say you do
this:

  stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
{:full_name => 'Full Name'})

In this case it would fail if the Person model changed :last_name to
:given_name, for example. I have very mixed feelings about that, and
might never use it myself, but it would serve to alleviate the fear of
false positives.

Thoughts?

Cheers,
David

From adam at thewilliams.ws  Tue Mar 18 10:29:59 2008
From: adam at thewilliams.ws (Adam Williams)
Date: Tue, 18 Mar 2008 10:29:59 -0400
Subject: [rspec-devel] stub_model
In-Reply-To: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
Message-ID: <F534E909-605A-4F58-A46B-B79260EDF003@thewilliams.ws>

I, for one, would find this kind of thing useful. I typically create  
an instance and set id, stubbing or mocking specific methods. I  
believe stubbing and mocking aren't about never using a model's  
behavior as much as it's about controlling /some/ of it. This would  
reduce the number of lines I have to type, and provide the extra  
assurance that I'm not accidentally going to the database.

+1, barring any unforeseen pains in the rear

   adam

On Mar 18, 2008, at 9:10 AM, David Chelimsky wrote:

> Hi all,
>
> Over the last couple of years I've read a ton of mail from users
> concerned with false positives coming from stubbing/mocking methods
> that don't exist. I recently added a stub_model method for
> rspec_on_rails (not yet released, available in git) which I think
> mitigates this a bit. It is still in development and subject to
> change, but here's how it works now.
>
> It looks a lot like mock_model.
>
>  stub_model(Person, :name => 'David')
>
> But it works in a fundamentally different way: FIrst, it creates a
> real instance (which means you have to create the model to use it). It
> assigns it an id by default, but you can set :id => nil if you want it
> to behave like a new record. It overrides new_record? so that it
> behaves as you would expect (false if there is an id, true if not). It
> also overrides #connection, raising an error if there is any attempt
> to access the database. This gives you the db isolation you get from
> mock_model, but with a real object. Kind of like unit_record, but on
> an instance by instance basis.
>
> I've been using this for a few weeks now (just introduced it to the
> rspec code base a week or so ago) and I'm finding it very useful. I'm
> thinking of changing the generated rails specs to use stub_model
> instead of mock_model, and I'd be curious to hear your thoughts about
> this.
>
> Also - right now it checks the hash against the model's attributes. If
> the model has a matching attribute it gets assigned, otherwise a stub
> is created. It occurs to me that, with some modification, this *could*
> be used as a bit of an auditing/red-flagging tool. So let's say you do
> this:
>
>  stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
> {:full_name => 'Full Name'})
>
> In this case it would fail if the Person model changed :last_name to
> :given_name, for example. I have very mixed feelings about that, and
> might never use it myself, but it would serve to alleviate the fear of
> false positives.
>
> Thoughts?
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From adam at thewilliams.ws  Tue Mar 18 11:12:21 2008
From: adam at thewilliams.ws (Adam Williams)
Date: Tue, 18 Mar 2008 11:12:21 -0400
Subject: [rspec-devel] Loading RSpec on Rails
Message-ID: <8F70BCDD-41EE-4E65-AB1F-B4DBFCB4423A@thewilliams.ws>

Folks,

I have built a plugin called 'Scenarios', which allows me to create  
data for tests. I have specs for it, but historically have had to  
modify rspec_on_rails very slightly to get them to run. Here's the deal:

1. Require everything necessary for testing a rails plugin and using  
rspec_on_rails

require 'active_support'
require 'active_record'
require 'action_controller'
require 'action_view'
require 'spec/rails'

2. I get an error when requiring 'spec/rails', which ultimately fails  
when requiring rspec_on_rails/edge/lib/spec/rails/extensions/spec/ 
example/configuration.rb

  activesupport/edge/lib/active_support/dependencies.rb:263:in  
`load_missing_constant': uninitialized constant  
Spec::Rails::Example::RailsExampleGroup (NameError)
  activesupport/edge/lib/active_support/dependencies.rb:453:in  
`const_missing'
  rspec_on_rails/edge/lib/spec/rails/extensions/spec/example/ 
configuration.rb:14
  /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ 
1.8/rubygems/custom_require.rb:27:in `gem_original_require'
  /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/ 
1.8/rubygems/custom_require.rb:27:in `require'
  activesupport/edge/lib/active_support/dependencies.rb:496:in `require'
  activesupport/edge/lib/active_support/dependencies.rb:342:in  
`new_constants_in'
  activesupport/edge/lib/active_support/dependencies.rb:496:in `require'
  rspec_on_rails/edge/lib/spec/rails/extensions.rb:5 ... 22 levels...

3. I have 'fixed' this in the past by applying a patch like this one http://faithfulcode.rubyforge.org/svn/plugins/trunk/scenarios/testing/rspec_on_rails_3119.patch


I'm not interested in doing that any more. Does anyone know a good way  
to resolve this problem?

Thank you,

    adam williams



From bryansray at gmail.com  Tue Mar 18 11:47:59 2008
From: bryansray at gmail.com (Bryan Ray)
Date: Tue, 18 Mar 2008 10:47:59 -0500
Subject: [rspec-devel] stub_model
In-Reply-To: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
Message-ID: <29a0119e0803180847j4650b3fbu42ce305931014e03@mail.gmail.com>

Awesome. I've had a lot of trouble convincing my co-workers that straight
mocking is a very useful thing (integration testing always seems to take
precedence in my environment) ... and the "false positives" argument is
always brought up. I will definitely be taking a look at this.

+1 ... would love to hear any arguments against it though. I can't think of
any at the moment.

On Tue, Mar 18, 2008 at 8:10 AM, David Chelimsky <dchelimsky at gmail.com>
wrote:

> Hi all,
>
> Over the last couple of years I've read a ton of mail from users
> concerned with false positives coming from stubbing/mocking methods
> that don't exist. I recently added a stub_model method for
> rspec_on_rails (not yet released, available in git) which I think
> mitigates this a bit. It is still in development and subject to
> change, but here's how it works now.
>
> It looks a lot like mock_model.
>
>  stub_model(Person, :name => 'David')
>
> But it works in a fundamentally different way: FIrst, it creates a
> real instance (which means you have to create the model to use it). It
> assigns it an id by default, but you can set :id => nil if you want it
> to behave like a new record. It overrides new_record? so that it
> behaves as you would expect (false if there is an id, true if not). It
> also overrides #connection, raising an error if there is any attempt
> to access the database. This gives you the db isolation you get from
> mock_model, but with a real object. Kind of like unit_record, but on
> an instance by instance basis.
>
> I've been using this for a few weeks now (just introduced it to the
> rspec code base a week or so ago) and I'm finding it very useful. I'm
> thinking of changing the generated rails specs to use stub_model
> instead of mock_model, and I'd be curious to hear your thoughts about
> this.
>
> Also - right now it checks the hash against the model's attributes. If
> the model has a matching attribute it gets assigned, otherwise a stub
> is created. It occurs to me that, with some modification, this *could*
> be used as a bit of an auditing/red-flagging tool. So let's say you do
> this:
>
>  stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
> {:full_name => 'Full Name'})
>
> In this case it would fail if the Person model changed :last_name to
> :given_name, for example. I have very mixed feelings about that, and
> might never use it myself, but it would serve to alleviate the fear of
> false positives.
>
> Thoughts?
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Bryan Ray
http://www.bryanray.net

"Programming today is a race between software engineers striving to build
bigger and better idiot-proof programs, and the Universe trying to produce
bigger and better idiots. So far, the Universe is winning."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080318/556112fa/attachment.html 

From james.deville at gmail.com  Tue Mar 18 18:43:45 2008
From: james.deville at gmail.com (James Deville)
Date: Tue, 18 Mar 2008 15:43:45 -0700
Subject: [rspec-devel] stub_model
In-Reply-To: <29a0119e0803180847j4650b3fbu42ce305931014e03@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
	<29a0119e0803180847j4650b3fbu42ce305931014e03@mail.gmail.com>
Message-ID: <8FF75B10-01FA-4435-8700-87BAE0404363@gmail.com>

+1 I think it sounds awesome. Especially since you get the speed of  
mocking by faking #connections, but you still get real behaviour!

JD
On Mar 18, 2008, at 8:47 AM, Bryan Ray wrote:

> Awesome. I've had a lot of trouble convincing my co-workers that  
> straight mocking is a very useful thing (integration testing always  
> seems to take precedence in my environment) ... and the "false  
> positives" argument is always brought up. I will definitely be  
> taking a look at this.
>
> +1 ... would love to hear any arguments against it though. I can't  
> think of any at the moment.
>
> On Tue, Mar 18, 2008 at 8:10 AM, David Chelimsky  
> <dchelimsky at gmail.com> wrote:
> Hi all,
>
> Over the last couple of years I've read a ton of mail from users
> concerned with false positives coming from stubbing/mocking methods
> that don't exist. I recently added a stub_model method for
> rspec_on_rails (not yet released, available in git) which I think
> mitigates this a bit. It is still in development and subject to
> change, but here's how it works now.
>
> It looks a lot like mock_model.
>
>  stub_model(Person, :name => 'David')
>
> But it works in a fundamentally different way: FIrst, it creates a
> real instance (which means you have to create the model to use it). It
> assigns it an id by default, but you can set :id => nil if you want it
> to behave like a new record. It overrides new_record? so that it
> behaves as you would expect (false if there is an id, true if not). It
> also overrides #connection, raising an error if there is any attempt
> to access the database. This gives you the db isolation you get from
> mock_model, but with a real object. Kind of like unit_record, but on
> an instance by instance basis.
>
> I've been using this for a few weeks now (just introduced it to the
> rspec code base a week or so ago) and I'm finding it very useful. I'm
> thinking of changing the generated rails specs to use stub_model
> instead of mock_model, and I'd be curious to hear your thoughts about
> this.
>
> Also - right now it checks the hash against the model's attributes. If
> the model has a matching attribute it gets assigned, otherwise a stub
> is created. It occurs to me that, with some modification, this *could*
> be used as a bit of an auditing/red-flagging tool. So let's say you do
> this:
>
>  stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
> {:full_name => 'Full Name'})
>
> In this case it would fail if the Person model changed :last_name to
> :given_name, for example. I have very mixed feelings about that, and
> might never use it myself, but it would serve to alleviate the fear of
> false positives.
>
> Thoughts?
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
>
> -- 
> Bryan Ray
> http://www.bryanray.net
>
> "Programming today is a race between software engineers striving to  
> build bigger and better idiot-proof programs, and the Universe  
> trying to produce bigger and better idiots. So far, the Universe is  
> winning." _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080318/b52f795d/attachment.html 

From linojon at gmail.com  Tue Mar 18 20:51:00 2008
From: linojon at gmail.com (linojon)
Date: Tue, 18 Mar 2008 20:51:00 -0400
Subject: [rspec-devel] stub_model
In-Reply-To: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
Message-ID: <8DCD4486-06B2-4A23-A410-10821EA04F36@gmail.com>

does it handle associations?


On Mar 18, 2008, at 9:10 AM, David Chelimsky wrote:

> Hi all,
>
> Over the last couple of years I've read a ton of mail from users
> concerned with false positives coming from stubbing/mocking methods
> that don't exist. I recently added a stub_model method for
> rspec_on_rails (not yet released, available in git) which I think
> mitigates this a bit. It is still in development and subject to
> change, but here's how it works now.
>
> It looks a lot like mock_model.
>
>   stub_model(Person, :name => 'David')
>
> But it works in a fundamentally different way: FIrst, it creates a
> real instance (which means you have to create the model to use it). It
> assigns it an id by default, but you can set :id => nil if you want it
> to behave like a new record. It overrides new_record? so that it
> behaves as you would expect (false if there is an id, true if not). It
> also overrides #connection, raising an error if there is any attempt
> to access the database. This gives you the db isolation you get from
> mock_model, but with a real object. Kind of like unit_record, but on
> an instance by instance basis.
>
> I've been using this for a few weeks now (just introduced it to the
> rspec code base a week or so ago) and I'm finding it very useful. I'm
> thinking of changing the generated rails specs to use stub_model
> instead of mock_model, and I'd be curious to hear your thoughts about
> this.
>
> Also - right now it checks the hash against the model's attributes. If
> the model has a matching attribute it gets assigned, otherwise a stub
> is created. It occurs to me that, with some modification, this *could*
> be used as a bit of an auditing/red-flagging tool. So let's say you do
> this:
>
>   stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
> {:full_name => 'Full Name'})
>
> In this case it would fail if the Person model changed :last_name to
> :given_name, for example. I have very mixed feelings about that, and
> might never use it myself, but it would serve to alleviate the fear of
> false positives.
>
> Thoughts?
>
> Cheers,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From matt at aimonetti.net  Tue Mar 18 21:35:39 2008
From: matt at aimonetti.net (Matt Aimonetti)
Date: Tue, 18 Mar 2008 18:35:39 -0700
Subject: [rspec-devel] stub_model
In-Reply-To: <8FF75B10-01FA-4435-8700-87BAE0404363@gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
	<29a0119e0803180847j4650b3fbu42ce305931014e03@mail.gmail.com>
	<8FF75B10-01FA-4435-8700-87BAE0404363@gmail.com>
Message-ID: <f58d8dcb0803181835m4b7b4cbdl9980637cd6889c3b@mail.gmail.com>

+1

 stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
{:full_name => 'Full Name'})

In this case it would fail if the Person model changed :last_name to
:given_name, for example. I have very mixed feelings about that, and
might never use it myself, but it would serve to alleviate the fear of
false positives.



I guess that could be useful, I might not use it either but I can see how
some people might really want to be able to do that.

-Matt

On 3/18/08, James Deville <james.deville at gmail.com> wrote:
>
> +1 I think it sounds awesome. Especially since you get the speed of
> mocking by faking #connections, but you still get real behaviour!
> JD
> On Mar 18, 2008, at 8:47 AM, Bryan Ray wrote:
>
> Awesome. I've had a lot of trouble convincing my co-workers that straight
> mocking is a very useful thing (integration testing always seems to take
> precedence in my environment) ... and the "false positives" argument is
> always brought up. I will definitely be taking a look at this.
>
> +1 ... would love to hear any arguments against it though. I can't think
> of any at the moment.
>
> On Tue, Mar 18, 2008 at 8:10 AM, David Chelimsky <dchelimsky at gmail.com>
> wrote:
>
> > Hi all,
> >
> > Over the last couple of years I've read a ton of mail from users
> > concerned with false positives coming from stubbing/mocking methods
> > that don't exist. I recently added a stub_model method for
> > rspec_on_rails (not yet released, available in git) which I think
> > mitigates this a bit. It is still in development and subject to
> > change, but here's how it works now.
> >
> > It looks a lot like mock_model.
> >
> >  stub_model(Person, :name => 'David')
> >
> > But it works in a fundamentally different way: FIrst, it creates a
> > real instance (which means you have to create the model to use it). It
> > assigns it an id by default, but you can set :id => nil if you want it
> > to behave like a new record. It overrides new_record? so that it
> > behaves as you would expect (false if there is an id, true if not). It
> > also overrides #connection, raising an error if there is any attempt
> > to access the database. This gives you the db isolation you get from
> > mock_model, but with a real object. Kind of like unit_record, but on
> > an instance by instance basis.
> >
> > I've been using this for a few weeks now (just introduced it to the
> > rspec code base a week or so ago) and I'm finding it very useful. I'm
> > thinking of changing the generated rails specs to use stub_model
> > instead of mock_model, and I'd be curious to hear your thoughts about
> > this.
> >
> > Also - right now it checks the hash against the model's attributes. If
> > the model has a matching attribute it gets assigned, otherwise a stub
> > is created. It occurs to me that, with some modification, this *could*
> > be used as a bit of an auditing/red-flagging tool. So let's say you do
> > this:
> >
> >  stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
> > {:full_name => 'Full Name'})
> >
> > In this case it would fail if the Person model changed :last_name to
> > :given_name, for example. I have very mixed feelings about that, and
> > might never use it myself, but it would serve to alleviate the fear of
> > false positives.
> >
> > Thoughts?
> >
> > Cheers,
> > David
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
>
> --
> Bryan Ray
> http://www.bryanray.net
>
> "Programming today is a race between software engineers striving to build
> bigger and better idiot-proof programs, and the Universe trying to produce
> bigger and better idiots. So far, the Universe is winning."
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080318/85debe7e/attachment-0001.html 

From dchelimsky at gmail.com  Tue Mar 18 22:23:06 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 18 Mar 2008 21:23:06 -0500
Subject: [rspec-devel] stub_model
In-Reply-To: <8DCD4486-06B2-4A23-A410-10821EA04F36@gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
	<8DCD4486-06B2-4A23-A410-10821EA04F36@gmail.com>
Message-ID: <57c63afe0803181923v760680fax839648e3cdcfbec5@mail.gmail.com>

On Tue, Mar 18, 2008 at 7:51 PM, linojon <linojon at gmail.com> wrote:
> does it handle associations?

Can you be more specific?

>
>
>
>  On Mar 18, 2008, at 9:10 AM, David Chelimsky wrote:
>
>
>
> > Hi all,
>  >
>  > Over the last couple of years I've read a ton of mail from users
>  > concerned with false positives coming from stubbing/mocking methods
>  > that don't exist. I recently added a stub_model method for
>  > rspec_on_rails (not yet released, available in git) which I think
>  > mitigates this a bit. It is still in development and subject to
>  > change, but here's how it works now.
>  >
>  > It looks a lot like mock_model.
>  >
>  >   stub_model(Person, :name => 'David')
>  >
>  > But it works in a fundamentally different way: FIrst, it creates a
>  > real instance (which means you have to create the model to use it). It
>  > assigns it an id by default, but you can set :id => nil if you want it
>  > to behave like a new record. It overrides new_record? so that it
>  > behaves as you would expect (false if there is an id, true if not). It
>  > also overrides #connection, raising an error if there is any attempt
>  > to access the database. This gives you the db isolation you get from
>  > mock_model, but with a real object. Kind of like unit_record, but on
>  > an instance by instance basis.
>  >
>  > I've been using this for a few weeks now (just introduced it to the
>  > rspec code base a week or so ago) and I'm finding it very useful. I'm
>  > thinking of changing the generated rails specs to use stub_model
>  > instead of mock_model, and I'd be curious to hear your thoughts about
>  > this.
>  >
>  > Also - right now it checks the hash against the model's attributes. If
>  > the model has a matching attribute it gets assigned, otherwise a stub
>  > is created. It occurs to me that, with some modification, this *could*
>  > be used as a bit of an auditing/red-flagging tool. So let's say you do
>  > this:
>  >
>  >   stub_model(Person, :attrs => {:last_name => 'Name'}, :stubs =>
>  > {:full_name => 'Full Name'})
>  >
>  > In this case it would fail if the Person model changed :last_name to
>  > :given_name, for example. I have very mixed feelings about that, and
>  > might never use it myself, but it would serve to alleviate the fear of
>  > false positives.
>  >
>  > Thoughts?
>  >
>  > Cheers,
>  > David
>
>
> > _______________________________________________
>  > rspec-devel mailing list
>  > rspec-devel at rubyforge.org
>  > http://rubyforge.org/mailman/listinfo/rspec-devel
>
>  _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>

From zach.dennis at gmail.com  Tue Mar 18 23:45:39 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Tue, 18 Mar 2008 23:45:39 -0400
Subject: [rspec-devel] stub_model
In-Reply-To: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
Message-ID: <85d99afe0803182045m64d63cc6ud8e1701d139fab2a@mail.gmail.com>

On Tue, Mar 18, 2008 at 9:10 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> Hi all,
>
>  Over the last couple of years I've read a ton of mail from users
>  concerned with false positives coming from stubbing/mocking methods
>  that don't exist. I recently added a stub_model method for
>  rspec_on_rails (not yet released, available in git) which I think
>  mitigates this a bit. It is still in development and subject to
>  change, but here's how it works now.
>
>  It looks a lot like mock_model.
>
>   stub_model(Person, :name => 'David')
>
>  But it works in a fundamentally different way: FIrst, it creates a
>  real instance (which means you have to create the model to use it). It
>  assigns it an id by default, but you can set :id => nil if you want it
>  to behave like a new record. It overrides new_record? so that it
>  behaves as you would expect (false if there is an id, true if not). It
>  also overrides #connection, raising an error if there is any attempt
>  to access the database. This gives you the db isolation you get from
>  mock_model, but with a real object.

Does this mean you have access to real model methods? If I define
FooModel#bar and I use stub_model(Foo) in a controller and someone
updates the controller to call foo#bar will it complain that an
unexpected method was called or will it call the real foo#bar method?

I hope it blows up, otherwise it acts like partial mocking classes and
that has negative drawbacks. Side rant: IMO partial mocking is evil
and should be avoided when they can be. They clutter up tests with
cases that shouldn't be there, but have to be there in order to ensure
certain calls aren't made (where a real mock would yell at you for
calling a method you didn't stub or expect). End side rant. =)

>  Kind of like unit_record, but on
>  an instance by instance basis.
>
>  I've been using this for a few weeks now (just introduced it to the
>  rspec code base a week or so ago) and I'm finding it very useful. I'm
>  thinking of changing the generated rails specs to use stub_model
>  instead of mock_model, and I'd be curious to hear your thoughts about
>  this.

I'm very eager to try this out. I'm interesting to find out more as
well. I shall sync with your git repository! Thanks for your hard work
David!


-- 
Zach Dennis
http://www.continuousthinking.com

From zach.dennis at gmail.com  Tue Mar 18 23:55:52 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Tue, 18 Mar 2008 23:55:52 -0400
Subject: [rspec-devel] Loading RSpec on Rails
In-Reply-To: <8F70BCDD-41EE-4E65-AB1F-B4DBFCB4423A@thewilliams.ws>
References: <8F70BCDD-41EE-4E65-AB1F-B4DBFCB4423A@thewilliams.ws>
Message-ID: <85d99afe0803182055i1ef145d3v6097eae203b677d0@mail.gmail.com>

Your patch seems very straightforward. Create a ticket in lighthouse
and supply your patch.

http://rspec.lighthouseapp.com/

Zach

On Tue, Mar 18, 2008 at 11:12 AM, Adam Williams <adam at thewilliams.ws> wrote:
> Folks,
>
>  I have built a plugin called 'Scenarios', which allows me to create
>  data for tests. I have specs for it, but historically have had to
>  modify rspec_on_rails very slightly to get them to run. Here's the deal:
>
>  1. Require everything necessary for testing a rails plugin and using
>  rspec_on_rails
>
>  require 'active_support'
>  require 'active_record'
>  require 'action_controller'
>  require 'action_view'
>  require 'spec/rails'
>
>  2. I get an error when requiring 'spec/rails', which ultimately fails
>  when requiring rspec_on_rails/edge/lib/spec/rails/extensions/spec/
>  example/configuration.rb
>
>   activesupport/edge/lib/active_support/dependencies.rb:263:in
>  `load_missing_constant': uninitialized constant
>  Spec::Rails::Example::RailsExampleGroup (NameError)
>   activesupport/edge/lib/active_support/dependencies.rb:453:in
>  `const_missing'
>   rspec_on_rails/edge/lib/spec/rails/extensions/spec/example/
>  configuration.rb:14
>   /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
>  1.8/rubygems/custom_require.rb:27:in `gem_original_require'
>   /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/
>  1.8/rubygems/custom_require.rb:27:in `require'
>   activesupport/edge/lib/active_support/dependencies.rb:496:in `require'
>   activesupport/edge/lib/active_support/dependencies.rb:342:in
>  `new_constants_in'
>   activesupport/edge/lib/active_support/dependencies.rb:496:in `require'
>   rspec_on_rails/edge/lib/spec/rails/extensions.rb:5 ... 22 levels...
>
>  3. I have 'fixed' this in the past by applying a patch like this one http://faithfulcode.rubyforge.org/svn/plugins/trunk/scenarios/testing/rspec_on_rails_3119.patch
>
>
>  I'm not interested in doing that any more. Does anyone know a good way
>  to resolve this problem?
>
>  Thank you,
>
>     adam williams
>
>
>  _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>



-- 
Zach Dennis
http://www.continuousthinking.com

From dchelimsky at gmail.com  Wed Mar 19 09:16:46 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 19 Mar 2008 08:16:46 -0500
Subject: [rspec-devel] stub_model
In-Reply-To: <85d99afe0803182045m64d63cc6ud8e1701d139fab2a@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
	<85d99afe0803182045m64d63cc6ud8e1701d139fab2a@mail.gmail.com>
Message-ID: <57c63afe0803190616p54e69bbdpaddc489f8deff8a1@mail.gmail.com>

On Tue, Mar 18, 2008 at 10:45 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
> On Tue, Mar 18, 2008 at 9:10 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>  > Hi all,
>  >
>  >  Over the last couple of years I've read a ton of mail from users
>  >  concerned with false positives coming from stubbing/mocking methods
>  >  that don't exist. I recently added a stub_model method for
>  >  rspec_on_rails (not yet released, available in git) which I think
>  >  mitigates this a bit. It is still in development and subject to
>  >  change, but here's how it works now.
>  >
>  >  It looks a lot like mock_model.
>  >
>  >   stub_model(Person, :name => 'David')
>  >
>  >  But it works in a fundamentally different way: FIrst, it creates a
>  >  real instance (which means you have to create the model to use it). It
>  >  assigns it an id by default, but you can set :id => nil if you want it
>  >  to behave like a new record. It overrides new_record? so that it
>  >  behaves as you would expect (false if there is an id, true if not). It
>  >  also overrides #connection, raising an error if there is any attempt
>  >  to access the database. This gives you the db isolation you get from
>  >  mock_model, but with a real object.
>
>  Does this mean you have access to real model methods? If I define
>  FooModel#bar and I use stub_model(Foo) in a controller and someone
>  updates the controller to call foo#bar will it complain that an
>  unexpected method was called or will it call the real foo#bar method?

The object IS a real model, so yes, it provides access to all of the
model methods.

>  I hope it blows up, otherwise it acts like partial mocking classes and
>  that has negative drawbacks.

It would fail if accessing that method caused some sort of error.

> Side rant: IMO partial mocking is evil
>  and should be avoided when they can be.

In general I agree, which is why it has taken me this long to arrive
at this solution. The motivation for me, personally, is that with a
mock object my view specs end up having to explicitly provide a lot of
stub values that the examples are not interested. They are just noise
that is present to keep the view moving.

It also strikes me that view specs are inherently state-based.

Take this for example:

describe "/people/show.html.erb" do
  ...
  it "should show the person's full name" do
    assigns[:person] = stub_model(Person, :full_name => "David Chelimsky")
    do_render
    response.should have_tag(".name", "David Chelimsky")
  end
end

To me, this is a very clear and simple example. We could debate that
it should be an interaction test, using
should_receive(:full_name).and_return(".."), but regardless of style
and intent, anyone with experience with view specs can read this and
it is very clear what is being expressed.

So let's say we add the person's email to the view:

  it "should show the person's email" do
    assigns[:person] = stub_model(Person, :email => "a at b.com")
    do_render
    response.should have_tag(".email", "a at b.com")
  end

With a mock object, both of these examples would now fail and I'd be
forced to supply both attributes for both examples. Sure, I could do
that by using a factory method (or object), but now I have to do this:

  it "should show the person's email" do
    assigns[:person] = create_person
    do_render
    response.should have_tag(".email", "a at b.com")
  end

But then if I change the value of the email address in the factory,
this example fails and I can't just look right at it to understand the
failure, I have to go look at the factory. So maybe I change the
expectation to use the created person's email.

  it "should show the person's email" do
    person = create_person
    assigns[:person] = person
    do_render
    response.should have_tag(".email", person.email)
  end

Except now, if the person's email is nil, and the tag happens to have
nil, the example will pass when it should fail. So maybe my factory
method takes arguments:

  it "should show the person's email" do
    assigns[:person] = create_person(:email => "a at b.com")
    do_render
    response.should have_tag(".email", "a at b.com")
  end

Now things are explicit and I'm still using a mock. Perhaps this is a
good solution using a mock object, but as the views grow, and we all
know they do, this becomes more and more work to maintain.

Using a real model instance and mocking/stubbing only what I expect in
a given example has allowed me to keep things much simpler in the view
specs and so far they have caused me no pain. Perhaps the lack of pain
has to do with the fact that views are generally not "interacting"
with the model, per se. They are simply grabbing and displaying
values. They are asking, not telling. Based on that, a mock object
almost seems like a waste.

> They clutter up tests with
>  cases that shouldn't be there, but have to be there in order to ensure
>  certain calls aren't made (where a real mock would yell at you for
>  calling a method you didn't stub or expect). End side rant. =)

I agree with you here in most cases. I'm coming to believe that views,
specifically views that rely on getters as Rails views do, are an edge
case when it comes to mock objects.

Consider an example from a CMS I'm working on. There is a content item
named promo, which has a bunch of attributes and near-zero behaviour.
Take a look at the code using mock_model (which wraps a mock object)
vs the code using stub_model (which wraps a real model object):
http://pastie.caboo.se/167751.

I think you'll agree that, given that the example is only interested
in form fields and not values, the latter is far superior for a number
of reasons. It is more clear. There is less noise. It is less brittle.
I'm sure there are others.

>  >  Kind of like unit_record, but on
>  >  an instance by instance basis.
>  >
>  >  I've been using this for a few weeks now (just introduced it to the
>  >  rspec code base a week or so ago) and I'm finding it very useful. I'm
>  >  thinking of changing the generated rails specs to use stub_model
>  >  instead of mock_model, and I'd be curious to hear your thoughts about
>  >  this.
>
>  I'm very eager to try this out. I'm interesting to find out more as
>  well. I shall sync with your git repository! Thanks for your hard work
>  David!

Thanks for your support.

Cheers,
David

>
>
>  --
>  Zach Dennis
>  http://www.continuousthinking.com
>
>
> _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>

From cgrindel at yahoo.com  Wed Mar 19 10:17:26 2008
From: cgrindel at yahoo.com (Charles Grindel)
Date: Wed, 19 Mar 2008 07:17:26 -0700 (PDT)
Subject: [rspec-devel] stub_model
Message-ID: <468269.14257.qm@web54111.mail.re2.yahoo.com>

To deal with model attribute access in my mocks, I took a slightly different approach.  First, I should mention that I use the Fixture Replacement plugin which allows you to easily create real model instances with reasonable attribute values.  (BTW, this plugin has been a real time saver.)  I realized that all I needed to do was marry the attribute definitions in Fixture Replacement's example_data.rb with RSpec's mock_model method.  So, I modified mock_model to recognize two parameters, :default_attribs and :create_attribs.  If you call mock_model without these parameters, things work as they would normally.  If you specify the :default_attribs parameter, it will retrieve the attributes from Fixture Replacement and stub them on the mock object.  If you specify the :create_attribs parameter, it will add values for :created_at, :updated_at, :created_on, :updated_on and :lock_version, if the model supports it.  Below is a typical use of this mechanism.

describe "/users/show.html.erb" do

  before(:each) do
    @user = mock_model(User, :default_attribs => true, :create_attribs => true)
    @user.person.stub!(:full_name).and_return('John Smith')
    assigns[:user] = @user
  end

  ...

end


If you are interested in perusing the code, it can be viewed at the following location.

http://pastie.caboo.se/167767


Chuck

----- Original Message ----
From: David Chelimsky <dchelimsky at gmail.com>
To: zach.dennis at gmail.com; rspec-devel <rspec-devel at rubyforge.org>
Sent: Wednesday, March 19, 2008 9:16:46 AM
Subject: Re: [rspec-devel] stub_model

On Tue, Mar 18, 2008 at 10:45 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
> On Tue, Mar 18, 2008 at 9:10 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>  > Hi all,
>  >
>  >  Over the last couple of years I've read a ton of mail from users
>  >  concerned with false positives coming from stubbing/mocking methods
>  >  that don't exist. I recently added a stub_model method for
>  >  rspec_on_rails (not yet released, available in git) which I think
>  >  mitigates this a bit. It is still in development and subject to
>  >  change, but here's how it works now.
>  >
>  >  It looks a lot like mock_model.
>  >
>  >   stub_model(Person, :name => 'David')
>  >
>  >  But it works in a fundamentally different way: FIrst, it creates a
>  >  real instance (which means you have to create the model to use it). It
>  >  assigns it an id by default, but you can set :id => nil if you want it
>  >  to behave like a new record. It overrides new_record? so that it
>  >  behaves as you would expect (false if there is an id, true if not). It
>  >  also overrides #connection, raising an error if there is any attempt
>  >  to access the database. This gives you the db isolation you get from
>  >  mock_model, but with a real object.
>
>  Does this mean you have access to real model methods? If I define
>  FooModel#bar and I use stub_model(Foo) in a controller and someone
>  updates the controller to call foo#bar will it complain that an
>  unexpected method was called or will it call the real foo#bar method?

The object IS a real model, so yes, it provides access to all of the
model methods.

>  I hope it blows up, otherwise it acts like partial mocking classes and
>  that has negative drawbacks.

It would fail if accessing that method caused some sort of error.

> Side rant: IMO partial mocking is evil
>  and should be avoided when they can be.

In general I agree, which is why it has taken me this long to arrive
at this solution. The motivation for me, personally, is that with a
mock object my view specs end up having to explicitly provide a lot of
stub values that the examples are not interested. They are just noise
that is present to keep the view moving.

It also strikes me that view specs are inherently state-based.

Take this for example:

describe "/people/show.html.erb" do
  ...
  it "should show the person's full name" do
    assigns[:person] = stub_model(Person, :full_name => "David Chelimsky")
    do_render
    response.should have_tag(".name", "David Chelimsky")
  end
end

To me, this is a very clear and simple example. We could debate that
it should be an interaction test, using
should_receive(:full_name).and_return(".."), but regardless of style
and intent, anyone with experience with view specs can read this and
it is very clear what is being expressed.

So let's say we add the person's email to the view:

  it "should show the person's email" do
    assigns[:person] = stub_model(Person, :email => "a at b.com")
    do_render
    response.should have_tag(".email", "a at b.com")
  end

With a mock object, both of these examples would now fail and I'd be
forced to supply both attributes for both examples. Sure, I could do
that by using a factory method (or object), but now I have to do this:

  it "should show the person's email" do
    assigns[:person] = create_person
    do_render
    response.should have_tag(".email", "a at b.com")
  end

But then if I change the value of the email address in the factory,
this example fails and I can't just look right at it to understand the
failure, I have to go look at the factory. So maybe I change the
expectation to use the created person's email.

  it "should show the person's email" do
    person = create_person
    assigns[:person] = person
    do_render
    response.should have_tag(".email", person.email)
  end

Except now, if the person's email is nil, and the tag happens to have
nil, the example will pass when it should fail. So maybe my factory
method takes arguments:

  it "should show the person's email" do
    assigns[:person] = create_person(:email => "a at b.com")
    do_render
    response.should have_tag(".email", "a at b.com")
  end

Now things are explicit and I'm still using a mock. Perhaps this is a
good solution using a mock object, but as the views grow, and we all
know they do, this becomes more and more work to maintain.

Using a real model instance and mocking/stubbing only what I expect in
a given example has allowed me to keep things much simpler in the view
specs and so far they have caused me no pain. Perhaps the lack of pain
has to do with the fact that views are generally not "interacting"
with the model, per se. They are simply grabbing and displaying
values. They are asking, not telling. Based on that, a mock object
almost seems like a waste.

> They clutter up tests with
>  cases that shouldn't be there, but have to be there in order to ensure
>  certain calls aren't made (where a real mock would yell at you for
>  calling a method you didn't stub or expect). End side rant. =)

I agree with you here in most cases. I'm coming to believe that views,
specifically views that rely on getters as Rails views do, are an edge
case when it comes to mock objects.

Consider an example from a CMS I'm working on. There is a content item
named promo, which has a bunch of attributes and near-zero behaviour.
Take a look at the code using mock_model (which wraps a mock object)
vs the code using stub_model (which wraps a real model object):
http://pastie.caboo.se/167751.

I think you'll agree that, given that the example is only interested
in form fields and not values, the latter is far superior for a number
of reasons. It is more clear. There is less noise. It is less brittle.
I'm sure there are others.

>  >  Kind of like unit_record, but on
>  >  an instance by instance basis.
>  >
>  >  I've been using this for a few weeks now (just introduced it to the
>  >  rspec code base a week or so ago) and I'm finding it very useful. I'm
>  >  thinking of changing the generated rails specs to use stub_model
>  >  instead of mock_model, and I'd be curious to hear your thoughts about
>  >  this.
>
>  I'm very eager to try this out. I'm interesting to find out more as
>  well. I shall sync with your git repository! Thanks for your hard work
>  David!

Thanks for your support.

Cheers,
David

>
>
>  --
>  Zach Dennis
>  http://www.continuousthinking.com
>
>
> _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>
_______________________________________________
rspec-devel mailing list
rspec-devel at rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-devel



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080319/456ac671/attachment-0001.html 

From cgrindel at yahoo.com  Wed Mar 19 10:27:37 2008
From: cgrindel at yahoo.com (Charles Grindel)
Date: Wed, 19 Mar 2008 07:27:37 -0700 (PDT)
Subject: [rspec-devel] stub_model
Message-ID: <972197.46584.qm@web54104.mail.re2.yahoo.com>

I forgot to mention one other important thing.  As my example implies, it actually creates an object graph using mock objects based upon the attribute definitions in example_data.rb.  In other words, the code that I posted will create a mocks for the models described in the example_data.rb.  Here is what my example_data.rb has for :user and :person.

  attributes_for :person do |o|
    o.last_name = Random.lastname
    o.first_name = Random.firstname
    o.middle_name = Random.initial
    o.prefix_name = nil
    o.suffix_name = nil
    o.dob = Time.now.years_ago(35).beginning_of_day
    o.gender = Gender.default_value
    o.created_by_id = 0
    o.updated_by_id = 0
  end

  attributes_for :user do |o|
    o.login = (Random.initial + Random.lastname).downcase
    o.email = Random.email
    o.user_status = UserStatus.active_value
    o.crypted_password = 'super secret password'
    o.salt = 'password salt'
    o.person = default_person
  end

Note that :user says to use a default_person.  This tells the modified mock_model code to create a Person mock with the appropriate default attributes.  Hence, I can access the person attribute on the User instance and get a mock with the Person default attributes.

Chuck

----- Original Message ----
From: Charles Grindel <cgrindel at yahoo.com>
To: rspec-devel <rspec-devel at rubyforge.org>
Sent: Wednesday, March 19, 2008 10:17:26 AM
Subject: Re: [rspec-devel] stub_model

To deal with model attribute access in my mocks, I took a slightly different approach.  First, I should mention that I use the Fixture Replacement plugin which allows you to easily create real model instances with reasonable attribute values.  (BTW, this plugin has been a real time saver.)  I realized that all I needed to do was marry the attribute definitions in Fixture Replacement's example_data.rb with RSpec's mock_model method.  So, I modified mock_model to recognize two parameters, :default_attribs and :create_attribs.  If you call mock_model without these parameters, things work as they would normally.  If you specify the :default_attribs parameter, it will retrieve the attributes from Fixture Replacement and stub them on the mock object.  If you specify the :create_attribs parameter, it will add values for :created_at, :updated_at, :created_on, :updated_on and :lock_version, if the model supports it.  Below is a typical use of this mechanism.

describe "/users/show.html.erb" do

  before(:each) do
    @user = mock_model(User, :default_attribs => true, :create_attribs => true)
    @user.person.stub!(:full_name).and_return('John Smith')
    assigns[:user] = @user
  end

  ...

end


If you are interested in perusing the code, it can be viewed at the following location.

http://pastie.caboo.se/167767


Chuck

----- Original Message ----
From: David Chelimsky <dchelimsky at gmail.com>
To: zach.dennis at gmail.com; rspec-devel <rspec-devel at rubyforge.org>
Sent: Wednesday, March 19, 2008 9:16:46 AM
Subject: Re: [rspec-devel] stub_model

On Tue, Mar 18, 2008 at 10:45 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
> On Tue, Mar 18, 2008 at 9:10 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>  > Hi all,
>  >
>  >  Over the last couple of years I've read a ton of mail from users
>  >  concerned with false positives coming from stubbing/mocking methods
>  >  that don't exist. I recently added a stub_model method for
>  >  rspec_on_rails (not yet released, available in git) which I think
>  >  mitigates this a bit. It is still in development and subject to
>  >  change, but here's how it works now.
>  >
>  >  It looks a lot like mock_model.
>  >
>  >   stub_model(Person, :name => 'David')
>  >
>  >  But it works in a fundamentally different way: FIrst, it creates a
>  >  real instance (which means you have to create the model to use it). It
>  >  assigns it an id by default, but you can set :id => nil if you want it
>  >  to behave like a new record. It overrides new_record? so that it
>  >  behaves as you would expect (false if there is an id, true if not). It
>  >  also overrides #connection, raising an error if there is any attempt
>  >  to access the database. This gives you the db isolation you get from
>  >  mock_model, but with a real object.
>
>  Does this mean you have access to real model methods? If I define
>  FooModel#bar and I use stub_model(Foo) in a controller and someone
>  updates the controller to call foo#bar will it complain that an
>  unexpected method was called or will it call the real foo#bar method?

The object IS a real model, so yes, it provides access to all of the
model methods.

>  I hope it blows up, otherwise it acts like partial mocking classes and
>  that has negative drawbacks.

It would fail if accessing that method caused some sort of error.

> Side rant: IMO partial mocking is evil
>  and should be avoided when they can be.

In general I agree, which is why it has taken me this long to arrive
at this solution. The motivation for me, personally, is that with a
mock object my view specs end up having to explicitly provide a lot of
stub values that the examples are not interested. They are just noise
that is present to keep the view moving.

It also strikes me that view specs are inherently state-based.

Take this for example:

describe "/people/show.html.erb" do
  ...
  it "should show the person's full name" do
    assigns[:person] = stub_model(Person, :full_name => "David Chelimsky")
    do_render
    response.should have_tag(".name", "David Chelimsky")
  end
end

To me, this is a very clear and simple example. We could debate that
it should be an interaction test, using
should_receive(:full_name).and_return(".."), but regardless of style
and intent, anyone with experience with view specs can read this and
it is very clear what is being expressed.

So let's say we add the person's email to the view:

  it "should show the person's email" do
    assigns[:person] = stub_model(Person, :email => "a at b.com")
    do_render
    response.should have_tag(".email", "a at b.com")
  end

With a mock object, both of these examples would now fail and I'd be
forced to supply both attributes for both examples. Sure, I could do
that by using a factory method (or object), but now I have to do this:

  it "should show the person's email" do
    assigns[:person] = create_person
    do_render
    response.should have_tag(".email", "a at b.com")
  end

But then if I change the value of the email address in the factory,
this example fails and I can't just look right at it to understand the
failure, I have to go look at the factory. So maybe I change the
expectation to use the created person's email.

  it "should show the person's email" do
    person = create_person
    assigns[:person] = person
    do_render
    response.should have_tag(".email", person.email)
  end

Except now, if the person's email is nil, and the tag happens to have
nil, the example will pass when it should fail. So maybe my factory
method takes arguments:

  it "should show the person's email" do
    assigns[:person] = create_person(:email => "a at b.com")
    do_render
    response.should have_tag(".email", "a at b.com")
  end

Now things are explicit and I'm still using a mock. Perhaps this is a
good solution using a mock object, but as the views grow, and we all
know they do, this becomes more and more work to maintain.

Using a real model instance and mocking/stubbing only what I expect in
a given example has allowed me to keep things much simpler in the view
specs and so far they have caused me no pain. Perhaps the lack of pain
has to do with the fact that views are generally not "interacting"
with the model, per se. They are simply grabbing and displaying
values. They are asking, not telling. Based on that, a mock object
almost seems like a waste.

> They clutter up tests with
>  cases that shouldn't be there, but have to be there in order to ensure
>  certain calls aren't made (where a real mock would yell at you for
>  calling a method you didn't stub or expect). End side rant. =)

I agree with you here in most cases. I'm coming to believe that views,
specifically views that rely on getters as Rails views do, are an edge
case when it comes to mock objects.

Consider an example from a CMS I'm working on. There is a content item
named promo, which has a bunch of attributes and near-zero behaviour.
Take a look at the code using mock_model (which wraps a mock object)
vs the code using stub_model (which wraps a real model object):
http://pastie.caboo.se/167751.

I think you'll agree that, given that the example is only interested
in form fields and not values, the latter is far superior for a number
of reasons. It is more clear. There is less noise. It is less brittle.
I'm sure there are others.

>  >  Kind of like unit_record, but on
>  >  an instance by instance basis.
>  >
>  >  I've been using this for a few weeks now (just introduced it to the
>  >  rspec code base a week or so ago) and I'm finding it very useful. I'm
>  >  thinking of changing the generated rails specs to use stub_model
>  >  instead of mock_model, and I'd be curious to hear your thoughts about
>  >  this.
>
>  I'm very eager to try this out. I'm interesting to find out more as
>  well. I shall sync with your git repository! Thanks for your hard work
>  David!

Thanks for your support.

Cheers,
David

>
>
>  --
>  Zach Dennis
>  http://www.continuousthinking.com
>
>
> _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>
_______________________________________________
rspec-devel mailing list
rspec-devel at rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-devel







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080319/d31678eb/attachment.html 

From bryan.wheelock at gmail.com  Wed Mar 19 22:42:14 2008
From: bryan.wheelock at gmail.com (Bryan Wheelock)
Date: Wed, 19 Mar 2008 22:42:14 -0400
Subject: [rspec-devel] understanding Mocks Stubs and ActiveRecord
Message-ID: <93d1d3a50803191942q3de0665fj9962d0506f12c35@mail.gmail.com>

I'm still having a difficult time grasping the use of Stubs and Mocks.
Does every method you pass to the mock have to stubbed out?
Do you have to stub out responses to actions on Object attributes?

If so, then it would seem you could test something that worked as a mock but
would
break with the actual database because an attribute was misspelled.

I'm guessing that what is actually happening is that I can't access the
model attributes.
Which would make sense if the Mock and Stub were the only elements of the
model that existed.

I also have a question about Activerecord::Base#increment!
Since it operates on an attribute of Candidate, should the receiver of
should_receive be Candidate or should it be Candidate.votes
Regardless, here is the code that has me confused.



describe "handling GET /affiliates/1" do

   before(:each) do
     @candidate = mock_model(Candidate, :id => 1,
                                        :name => "Mr. Falsechoice"
                                        :votes => 1 )
     Candidate.stub!(:find).with(1).and_return(@candidate)
     Candidate.should_receive(:find).with("1").and_return(@candidate)
     Candidate.stub!(:increment!).with(:votes).and_return(true)
     Candidate.should_receive(:increment!).with(:votes).and_return(true)
   end

   def do_get
     get :show, :id => "1"
   end

   it "a request for an Candidate should increment votes by one" do
     do_get
     @candidate.votes.should eql(2)
     # I don't understand how I'm supposed to mock increment!
     # things I've tried:
     # Candidate.should_receive(:increment!)
     # Candidate.should_receive("increment!")
     # Candidate.clicks.should_receive(:increment!)
   end
end

# this is the Controller I'm testing
class CandidatesController < ApplicationController
    def show
     @affiliate = Candidate.find(params[:id]).increment!("votes")
     respond_to do |format|
        format.html # show.html.erb
        format.xml  { render :xml => @affiliate }
    end
  end

My specs give me this error:
Mock 'Candidate_1007' received unexpected message :increment! with ("votes")

I really appreciate any pointers.

thanks,
Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20080319/84660201/attachment-0001.html 

From dchelimsky at gmail.com  Thu Mar 20 08:07:59 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 20 Mar 2008 07:07:59 -0500
Subject: [rspec-devel] understanding Mocks Stubs and ActiveRecord
In-Reply-To: <93d1d3a50803191942q3de0665fj9962d0506f12c35@mail.gmail.com>
References: <93d1d3a50803191942q3de0665fj9962d0506f12c35@mail.gmail.com>
Message-ID: <57c63afe0803200507o30238bf1r226f64b4e9d29465@mail.gmail.com>

On Wed, Mar 19, 2008 at 9:42 PM, Bryan Wheelock
<bryan.wheelock at gmail.com> wrote:
> I'm still having a difficult time grasping the use of Stubs and Mocks.
> Does every method you pass to the mock have to stubbed out?
> Do you have to stub out responses to actions on Object attributes?
>
> If so, then it would seem you could test something that worked as a mock but
> would
> break with the actual database because an attribute was misspelled.
>
> I'm guessing that what is actually happening is that I can't access the
> model attributes.
> Which would make sense if the Mock and Stub were the only elements of the
> model that existed.
>
> I also have a question about Activerecord::Base#increment!
> Since it operates on an attribute of Candidate, should the receiver of
> should_receive be Candidate or should it be Candidate.votes
> Regardless, here is the code that has me confused.
>
>
>
> describe "handling GET /affiliates/1" do
>
>    before(:each) do
>      @candidate = mock_model(Candidate, :id => 1,
>                                         :name => "Mr. Falsechoice"
>                                         :votes => 1 )
>      Candidate.stub!(:find).with(1).and_return(@candidate)
>      Candidate.should_receive(:find).with("1").and_return(@candidate)
>      Candidate.stub!(:increment!).with(:votes).and_return(true)
>      Candidate.should_receive(:increment!).with(:votes).and_return(true)
>    end

Why are you using both stub! and should_receive for the same messages here?

>
>    def do_get
>      get :show, :id => "1"
>    end
>
>    it "a request for an Candidate should increment votes by one" do

There's a reason we chose "it" here. Clearly "it a request ..." does
not make any sense. I'd structure this something like:

describe Candidate do
  describe "responding to a request" do
    it " should increment votes" do

>      do_get
>      @candidate.votes.should eql(2)
>      # I don't understand how I'm supposed to mock increment!
>      # things I've tried:
>      # Candidate.should_receive(:increment!)
>      # Candidate.should_receive("increment!")
>      # Candidate.clicks.should_receive(:increment!)
>    end
> end
>
> # this is the Controller I'm testing
> class CandidatesController < ApplicationController
>     def show
>      @affiliate = Candidate.find(params[:id]).increment!("votes")

This line is the same as this:

@affiliate = Candidate.find(params[:id])
@affiliate.increment!('votes')

If you think of it that way, there are two things you need to mock here:

affiliate = mock_model(Candidate)
Candidate.should_receive(:find).with("1").and_return(affiliate)
affiliate.should_receive(:increment!).with('votes')

The thing is that since you've done it all in one line, you have to
make sure to return the affiliate from the call to :increment, so ....

affiliate = mock_model(Candidate)
Candidate.should_receive(:find).with("1").and_return(affiliate)
affiliate.should_receive(:increment!).with('votes').and_return(affiliate)

Personally, when I see a need to mock two levels deep like that, I
take that as encouragement to change the design a bit. What I'd like
to see is something like:

affiliate = mock_model(Candidate)
Candidate.should_receive(:find_and_vote).with("1").and_return(affiliate)

Now the example is cleaner, the resulting controller code is cleaner,
and the work is pushed down to the model, where it belongs IMO.

HTH,
David


>      respond_to do |format|
>         format.html # show.html.erb
>         format.xml  { render :xml => @affiliate }
>     end
>   end




>
> My specs give me this error:
> Mock 'Candidate_1007' received unexpected message :increment! with ("votes")
>
> I really appreciate any pointers.
>
> thanks,
> Bryan
>
>
> _______________________________________________
>  rspec-devel mailing list
>  rspec-devel at rubyforge.org
>  http://rubyforge.org/mailman/listinfo/rspec-devel
>

From zach.dennis at gmail.com  Fri Mar 21 11:30:47 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Fri, 21 Mar 2008 11:30:47 -0400
Subject: [rspec-devel] stub_model
In-Reply-To: <57c63afe0803190616p54e69bbdpaddc489f8deff8a1@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
	<85d99afe0803182045m64d63cc6ud8e1701d139fab2a@mail.gmail.com>
	<57c63afe0803190616p54e69bbdpaddc489f8deff8a1@mail.gmail.com>
Message-ID: <85d99afe0803210830t1bc3f61fofaf3bddc79a49b4e@mail.gmail.com>

On Wed, Mar 19, 2008 at 9:16 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Tue, Mar 18, 2008 at 10:45 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>  > On Tue, Mar 18, 2008 at 9:10 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>  >  > Hi all,
>  >  >
>  >  >  Over the last couple of years I've read a ton of mail from users
>  >  >  concerned with false positives coming from stubbing/mocking methods
>  >  >  that don't exist. I recently added a stub_model method for
>  >  >  rspec_on_rails (not yet released, available in git) which I think
>  >  >  mitigates this a bit. It is still in development and subject to
>  >  >  change, but here's how it works now.
>  >  >
>  >  >  It looks a lot like mock_model.
>  >  >
>  >  >   stub_model(Person, :name => 'David')
>  >  >
>  >  >  But it works in a fundamentally different way: FIrst, it creates a
>  >  >  real instance (which means you have to create the model to use it). It
>  >  >  assigns it an id by default, but you can set :id => nil if you want it
>  >  >  to behave like a new record. It overrides new_record? so that it
>  >  >  behaves as you would expect (false if there is an id, true if not). It
>  >  >  also overrides #connection, raising an error if there is any attempt
>  >  >  to access the database. This gives you the db isolation you get from
>  >  >  mock_model, but with a real object.
>  >
>  >  Does this mean you have access to real model methods? If I define
>  >  FooModel#bar and I use stub_model(Foo) in a controller and someone
>  >  updates the controller to call foo#bar will it complain that an
>  >  unexpected method was called or will it call the real foo#bar method?
>
>  The object IS a real model, so yes, it provides access to all of the
>  model methods.
>
>
>  >  I hope it blows up, otherwise it acts like partial mocking classes and
>  >  that has negative drawbacks.
>
>  It would fail if accessing that method caused some sort of error.
>
>
>  > Side rant: IMO partial mocking is evil
>  >  and should be avoided when they can be.
>
>  In general I agree, which is why it has taken me this long to arrive
>  at this solution. The motivation for me, personally, is that with a
>  mock object my view specs end up having to explicitly provide a lot of
>  stub values that the examples are not interested. They are just noise
>  that is present to keep the view moving.
>
>  It also strikes me that view specs are inherently state-based.
>
>  Take this for example:
>
>  describe "/people/show.html.erb" do
>   ...
>   it "should show the person's full name" do
>     assigns[:person] = stub_model(Person, :full_name => "David Chelimsky")
>     do_render
>     response.should have_tag(".name", "David Chelimsky")
>   end
>  end
>
>  To me, this is a very clear and simple example. We could debate that
>  it should be an interaction test, using
>  should_receive(:full_name).and_return(".."), but regardless of style
>  and intent, anyone with experience with view specs can read this and
>  it is very clear what is being expressed.
>
>  So let's say we add the person's email to the view:
>
>   it "should show the person's email" do
>     assigns[:person] = stub_model(Person, :email => "a at b.com")
>     do_render
>     response.should have_tag(".email", "a at b.com")
>   end
>
>  With a mock object, both of these examples would now fail and I'd be
>  forced to supply both attributes for both examples. Sure, I could do
>  that by using a factory method (or object), but now I have to do this:
>
>   it "should show the person's email" do
>     assigns[:person] = create_person
>     do_render
>     response.should have_tag(".email", "a at b.com")
>   end
>
>  But then if I change the value of the email address in the factory,
>  this example fails and I can't just look right at it to understand the
>  failure, I have to go look at the factory. So maybe I change the
>  expectation to use the created person's email.
>
>   it "should show the person's email" do
>     person = create_person
>     assigns[:person] = person
>     do_render
>     response.should have_tag(".email", person.email)
>   end
>
>  Except now, if the person's email is nil, and the tag happens to have
>  nil, the example will pass when it should fail. So maybe my factory
>  method takes arguments:
>
>   it "should show the person's email" do
>     assigns[:person] = create_person(:email => "a at b.com")
>     do_render
>     response.should have_tag(".email", "a at b.com")
>   end
>
>  Now things are explicit and I'm still using a mock. Perhaps this is a
>  good solution using a mock object, but as the views grow, and we all
>  know they do, this becomes more and more work to maintain.
>
>  Using a real model instance and mocking/stubbing only what I expect in
>  a given example has allowed me to keep things much simpler in the view
>  specs and so far they have caused me no pain. Perhaps the lack of pain
>  has to do with the fact that views are generally not "interacting"
>  with the model, per se. They are simply grabbing and displaying
>  values. They are asking, not telling. Based on that, a mock object
>  almost seems like a waste.
>
>
>  > They clutter up tests with
>  >  cases that shouldn't be there, but have to be there in order to ensure
>  >  certain calls aren't made (where a real mock would yell at you for
>  >  calling a method you didn't stub or expect). End side rant. =)
>
>  I agree with you here in most cases. I'm coming to believe that views,
>  specifically views that rely on getters as Rails views do, are an edge
>  case when it comes to mock objects.
>
>  Consider an example from a CMS I'm working on. There is a content item
>  named promo, which has a bunch of attributes and near-zero behaviour.
>  Take a look at the code using mock_model (which wraps a mock object)
>  vs the code using stub_model (which wraps a real model object):
>  http://pastie.caboo.se/167751.
>
>  I think you'll agree that, given that the example is only interested
>  in form fields and not values, the latter is far superior for a number
>  of reasons. It is more clear. There is less noise. It is less brittle.
>  I'm sure there are others.

I agree with basically everything you've explained. In your example
you made the mock_model more verbose then it should have to be:

  before(:each) do
    @promo = mock_model(Promo)
    @promo.stub!(:new_record?).and_return(true)
    @promo.stub!(:title).and_return("MyString")
    @promo.stub!(:slug).and_return("MyString")
    @promo.stub!(:source).and_return("MyString")
    @promo.stub!(:author).and_return("MyString")
    @promo.stub!(:date).and_return(Date.today)
    @promo.stub!(:link).and_return("MyString")
    @promo.stub!(:text).and_return("MyText")
    @promo.stub!(:new_window).and_return(false)
    assigns[:promo] = @promo
  end

Couldn't that just be:

  @promo = mock_model(Promo,
    :new_record? => true,
    :title => "MyString",
    :slug => "MyString",
    etc... )

Not that it makes a huge improvement, but it cuts down on the noise
and increases the clarity. With the example you gave using stub_model
definitely seems to have have advantage especially since Rails forms
are so tightly integrated with their ActiveRecord counterparts.

Have you used stub_model outside of form testing, and if so how do you
find it working their?

-- 
Zach Dennis
http://www.continuousthinking.com

From zach.dennis at gmail.com  Fri Mar 21 11:32:18 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Fri, 21 Mar 2008 11:32:18 -0400
Subject: [rspec-devel] stub_model
In-Reply-To: <85d99afe0803210830t1bc3f61fofaf3bddc79a49b4e@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
	<85d99afe0803182045m64d63cc6ud8e1701d139fab2a@mail.gmail.com>
	<57c63afe0803190616p54e69bbdpaddc489f8deff8a1@mail.gmail.com>
	<85d99afe0803210830t1bc3f61fofaf3bddc79a49b4e@mail.gmail.com>
Message-ID: <85d99afe0803210832j5ec1cdb2s625c3d33d02d1787@mail.gmail.com>

On Fri, Mar 21, 2008 at 11:30 AM, Zach Dennis <zach.dennis at gmail.com> wrote:
>
> On Wed, Mar 19, 2008 at 9:16 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>  > On Tue, Mar 18, 2008 at 10:45 PM, Zach Dennis <zach.dennis at gmail.com> wrote:
>  >  > On Tue, Mar 18, 2008 at 9:10 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>  >  >  > Hi all,
>  >  >  >
>  >  >  >  Over the last couple of years I've read a ton of mail from users
>  >  >  >  concerned with false positives coming from stubbing/mocking methods
>  >  >  >  that don't exist. I recently added a stub_model method for
>  >  >  >  rspec_on_rails (not yet released, available in git) which I think
>  >  >  >  mitigates this a bit. It is still in development and subject to
>  >  >  >  change, but here's how it works now.
>  >  >  >
>  >  >  >  It looks a lot like mock_model.
>  >  >  >
>  >  >  >   stub_model(Person, :name => 'David')
>  >  >  >
>  >  >  >  But it works in a fundamentally different way: FIrst, it creates a
>  >  >  >  real instance (which means you have to create the model to use it). It
>  >  >  >  assigns it an id by default, but you can set :id => nil if you want it
>  >  >  >  to behave like a new record. It overrides new_record? so that it
>  >  >  >  behaves as you would expect (false if there is an id, true if not). It
>  >  >  >  also overrides #connection, raising an error if there is any attempt
>  >  >  >  to access the database. This gives you the db isolation you get from
>  >  >  >  mock_model, but with a real object.
>  >  >
>  >  >  Does this mean you have access to real model methods? If I define
>  >  >  FooModel#bar and I use stub_model(Foo) in a controller and someone
>  >  >  updates the controller to call foo#bar will it complain that an
>  >  >  unexpected method was called or will it call the real foo#bar method?
>  >
>  >  The object IS a real model, so yes, it provides access to all of the
>  >  model methods.
>  >
>  >
>  >  >  I hope it blows up, otherwise it acts like partial mocking classes and
>  >  >  that has negative drawbacks.
>  >
>  >  It would fail if accessing that method caused some sort of error.
>  >
>  >
>  >  > Side rant: IMO partial mocking is evil
>  >  >  and should be avoided when they can be.
>  >
>  >  In general I agree, which is why it has taken me this long to arrive
>  >  at this solution. The motivation for me, personally, is that with a
>  >  mock object my view specs end up having to explicitly provide a lot of
>  >  stub values that the examples are not interested. They are just noise
>  >  that is present to keep the view moving.
>  >
>  >  It also strikes me that view specs are inherently state-based.
>  >
>  >  Take this for example:
>  >
>  >  describe "/people/show.html.erb" do
>  >   ...
>  >   it "should show the person's full name" do
>  >     assigns[:person] = stub_model(Person, :full_name => "David Chelimsky")
>  >     do_render
>  >     response.should have_tag(".name", "David Chelimsky")
>  >   end
>  >  end
>  >
>  >  To me, this is a very clear and simple example. We could debate that
>  >  it should be an interaction test, using
>  >  should_receive(:full_name).and_return(".."), but regardless of style
>  >  and intent, anyone with experience with view specs can read this and
>  >  it is very clear what is being expressed.
>  >
>  >  So let's say we add the person's email to the view:
>  >
>  >   it "should show the person's email" do
>  >     assigns[:person] = stub_model(Person, :email => "a at b.com")
>  >     do_render
>  >     response.should have_tag(".email", "a at b.com")
>  >   end
>  >
>  >  With a mock object, both of these examples would now fail and I'd be
>  >  forced to supply both attributes for both examples. Sure, I could do
>  >  that by using a factory method (or object), but now I have to do this:
>  >
>  >   it "should show the person's email" do
>  >     assigns[:person] = create_person
>  >     do_render
>  >     response.should have_tag(".email", "a at b.com")
>  >   end
>  >
>  >  But then if I change the value of the email address in the factory,
>  >  this example fails and I can't just look right at it to understand the
>  >  failure, I have to go look at the factory. So maybe I change the
>  >  expectation to use the created person's email.
>  >
>  >   it "should show the person's email" do
>  >     person = create_person
>  >     assigns[:person] = person
>  >     do_render
>  >     response.should have_tag(".email", person.email)
>  >   end
>  >
>  >  Except now, if the person's email is nil, and the tag happens to have
>  >  nil, the example will pass when it should fail. So maybe my factory
>  >  method takes arguments:
>  >
>  >   it "should show the person's email" do
>  >     assigns[:person] = create_person(:email => "a at b.com")
>  >     do_render
>  >     response.should have_tag(".email", "a at b.com")
>  >   end
>  >
>  >  Now things are explicit and I'm still using a mock. Perhaps this is a
>  >  good solution using a mock object, but as the views grow, and we all
>  >  know they do, this becomes more and more work to maintain.
>  >
>  >  Using a real model instance and mocking/stubbing only what I expect in
>  >  a given example has allowed me to keep things much simpler in the view
>  >  specs and so far they have caused me no pain. Perhaps the lack of pain
>  >  has to do with the fact that views are generally not "interacting"
>  >  with the model, per se. They are simply grabbing and displaying
>  >  values. They are asking, not telling. Based on that, a mock object
>  >  almost seems like a waste.
>  >
>  >
>  >  > They clutter up tests with
>  >  >  cases that shouldn't be there, but have to be there in order to ensure
>  >  >  certain calls aren't made (where a real mock would yell at you for
>  >  >  calling a method you didn't stub or expect). End side rant. =)
>  >
>  >  I agree with you here in most cases. I'm coming to believe that views,
>  >  specifically views that rely on getters as Rails views do, are an edge
>  >  case when it comes to mock objects.
>  >
>  >  Consider an example from a CMS I'm working on. There is a content item
>  >  named promo, which has a bunch of attributes and near-zero behaviour.
>  >  Take a look at the code using mock_model (which wraps a mock object)
>  >  vs the code using stub_model (which wraps a real model object):
>  >  http://pastie.caboo.se/167751.
>  >
>  >  I think you'll agree that, given that the example is only interested
>  >  in form fields and not values, the latter is far superior for a number
>  >  of reasons. It is more clear. There is less noise. It is less brittle.
>  >  I'm sure there are others.
>
>  I agree with basically everything you've explained. In your example
>  you made the mock_model more verbose then it should have to be:
>
>   before(:each) do
>     @promo = mock_model(Promo)
>     @promo.stub!(:new_record?).and_return(true)
>     @promo.stub!(:title).and_return("MyString")
>     @promo.stub!(:slug).and_return("MyString")
>     @promo.stub!(:source).and_return("MyString")
>     @promo.stub!(:author).and_return("MyString")
>     @promo.stub!(:date).and_return(Date.today)
>     @promo.stub!(:link).and_return("MyString")
>     @promo.stub!(:text).and_return("MyText")
>     @promo.stub!(:new_window).and_return(false)
>     assigns[:promo] = @promo
>   end
>
>  Couldn't that just be:
>
>   @promo = mock_model(Promo,
>     :new_record? => true,
>     :title => "MyString",
>     :slug => "MyString",
>     etc... )
>
>  Not that it makes a huge improvement, but it cuts down on the noise
>  and increases the clarity. With the example you gave using stub_model
>  definitely seems to have have advantage especially since Rails forms
>  are so tightly integrated with their ActiveRecord counterparts.
>
>  Have you used stub_model outside of form testing, and if so how do you
>  find it working their?
>

"their".sub /ir/, /re/


-- 
Zach Dennis
http://www.continuousthinking.com

P.S. - didn't mean to spam you David, I hit reply instead of reply to
all the first time

From matt-lists at reprocessed.org  Fri Mar 21 15:17:32 2008
From: matt-lists at reprocessed.org (Matt Patterson)
Date: Fri, 21 Mar 2008 19:17:32 +0000
Subject: [rspec-devel] stub_model
In-Reply-To: <57c63afe0803190616p54e69bbdpaddc489f8deff8a1@mail.gmail.com>
References: <57c63afe0803180610u4517fa50r95af52ff4d721228@mail.gmail.com>
	<85d99afe0803182045m64d63cc6ud8e1701d139fab2a@mail.gmail.com>
	<57c63afe0803190616p54e69bbdpaddc489f8deff8a1@mail.gmail.com>
Message-ID: <2C984B6E-BDB7-42DA-86BD-CCEE5194DD5D@reprocessed.org>

On 19 Mar 2008, at 13:16, David Chelimsky wrote:

> On Tue, Mar 18, 2008 at 10:45 PM, Zach Dennis  
> <zach.dennis at gmail.com> wrote:
>> On Tue, Mar 18, 2008 at 9:10 AM, David Chelimsky  
>> <dchelimsky at gmail.com> wrote:
>>>  It looks a lot like mock_model.
>>>
>>>   stub_model(Person, :name => 'David')
>>>
>>>  But it works in a fundamentally different way: FIrst, it creates a
>>>  real instance (which means you have to create the model to use  
>>> it). It
>>>  assigns it an id by default, but you can set :id => nil if you  
>>> want it
>>>  to behave like a new record. It overrides new_record? so that it
>>>  behaves as you would expect (false if there is an id, true if not).

+1 from me. I've been using a very similar approach for a couple of  
months now, but I reopened ActiveRecord::Base instead and defined a  
mock_saved Class method, so you can do:

Person.mock_saved(:id => 1, :name => 'David')

for a Person instance which pretends to be saved. I know that the  
method name sucks, but I haven't been able to think of a better one...


>>> It
>>>  also overrides #connection, raising an error if there is any  
>>> attempt
>>>  to access the database. This gives you the db isolation you get  
>>> from
>>>  mock_model, but with a real object.

I'm not doing this, but I like it. (I think I shall steal it, post  
haste :-)

> In general I agree, which is why it has taken me this long to arrive
> at this solution. The motivation for me, personally, is that with a
> mock object my view specs end up having to explicitly provide a lot of
> stub values that the examples are not interested. They are just noise
> that is present to keep the view moving.

I think I may be less averse to partial mocking than many people  
(though I do worry about it), but I've found that this approach  
allows me to be less explicit in my mocks and stubs, which is to say,  
tying my tests less tightly into implementation specifics.

(However, this discussion has made me think that maybe I ought to  
look at making .mock_saved make its instances more explody)

> Using a real model instance and mocking/stubbing only what I expect in
> a given example has allowed me to keep things much simpler in the view
> specs and so far they have caused me no pain. Perhaps the lack of pain
> has to do with the fact that views are generally not "interacting"
> with the model, per se. They are simply grabbing and displaying
> values. They are asking, not telling. Based on that, a mock object
> almost seems like a waste.

Absolutely. Explicit and painless. I stub out the associations  
appropriately so I can test the various view cases, and it all seems  
much easier...

On a related mocking / stubbing noise / pain note, I've found that  
Luke Redpath's Demeter's Revenge plugin (http://www.lukeredpath.co.uk/ 
2007/10/18/demeters-revenge) has become utterly essential for helping  
untangle some of the more common cases of excess mock noise. (I tend  
to deal with the others by moving towards many-skinny-methods).

Matt


-- 
   Matt Patterson | Design & Code
   <matt at reprocessed org> | http://www.reprocessed.org/




From dchelimsky at gmail.com  Fri Mar 28 11:01:53 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 28 Mar 2008 11:01:53 -0400
Subject: [rspec-devel] help Steven Baker get to Scotland on Rails
Message-ID: <57c63afe0803280801x2fc513b0h86199cc58c43b460@mail.gmail.com>

Hi all,

Warning - this is a request for money to help do something nice for
someone. If this offends you in any way, please stop reading now and
just delete this email.

Steven Baker, the guy who actually wrote RSpec to begin with (just
think of a world in which the only BDD frameworks were in C++ and
Java), needs help getting to Scotland on Rails next week. I've set up
a fundraiser at
http://www.fundable.com/groupactions/groupaction.2008-03-28.7509751339.

If you feel so inclined, please do kick in a few bucks to help out.

Cheers,
David

ps - if you actually do feel this is completely inappropriate for this
list, please let me know.