From barjunk at attglobal.net  Sun Jul  1 14:35:02 2007
From: barjunk at attglobal.net (barsalou)
Date: Sun, 01 Jul 2007 10:35:02 -0800
Subject: [rspec-users] testing instance variables that are set
	inside	views
In-Reply-To: <57c63afe0706301341l19d4041bvca9dd519ce3b74fc@mail.gmail.com>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
	<20070630123510.rsfz95u3okkks4s4@lcgalaska.com>
	<57c63afe0706301341l19d4041bvca9dd519ce3b74fc@mail.gmail.com>
Message-ID: <20070701103502.nzp6dpib2o80s0s0@lcgalaska.com>

Quoting David Chelimsky <dchelimsky at gmail.com>:

>>>
>> Thanks Aslak, I wondered this myself.  I looked around here :
>> http://rspec.rubyforge.org/rdoc/index.html for have_tag but didn't find
>> it.
>>
>> Where would be a good place to find some of these matchers?
>
> have_tag is not part of rspec's core, it's in the rails plugin. The
> rdoc for that is at http://rspec.rubyforge.org/rdoc-rails/index.html
>
> Cheers,
> David

Perfect, thanks!

Mike B.

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From barjunk at attglobal.net  Sun Jul  1 18:05:21 2007
From: barjunk at attglobal.net (barsalou)
Date: Sun, 01 Jul 2007 14:05:21 -0800
Subject: [rspec-users] rspec for the svn-less (ruby version)
Message-ID: <20070701140521.mkcxpwec08kokoog@lcgalaska.com>

A couple of things:

- it is defaulted to 1.0.5, but if there was a "current" I could 
probably use that instead.

- it seems like everyone might not use the rspec_on_rails piece...what 
do other think?

- there are some other checks I could put in here, suggestions are welcome.

- general code suggestions are welcome as well.

Mike B.


Here is my ruby version:

#!/usr/bin/ruby -w

require 'ftools'

def usage
  puts
  puts "Usage: makespec.rb <path> [<dotted-version>]"
  puts
  puts "Version defaults to 1.0.5"
  puts
  puts "Example: "
  puts "   makespec.rb /var/www/rails/railsapp 1.0.5"
  puts
end

if ARGV[0].nil? then
  usage
  puts
  puts "You must include a pathname"
  puts
  exit 1
end

version = ARGV[1]

if ARGV[1].nil? then
  puts
  puts "Defaulting to version: 1.0.5"
  puts
  version = "1.0.5"
end

rspec="rspec-" + version + ".tgz"
rspecrails="rspec_on_rails-" + version + ".tgz"
app = ARGV[0]

if ! File.exist?(rspec) then
  puts
  puts "Rspec tarball (" + rspec + ") does not exist in the current directory"
  puts
  exit 1
end

if ! File.exist?(rspecrails) then
  puts
  puts "Rspec-rails tarball (" + rspecrails + ") does not exist in the 
current d
irectory"
  puts
  exit 1
end

if FileTest.directory? app + "/vendor/plugins" then
   system("tar","zxvf", rspec)
   system("tar","zxvf", rspecrails)
   cwd = Dir.pwd
   Dir.chdir(app + "/vendor/plugins")
   File.move(cwd + "/" + File.basename(rspec,".tgz"),app + 
"/vendor/plugins/rspec")
   File.move(cwd + "/" + File.basename(rspecrails,".tgz"),app + 
"/vendor/plugins/rspec_on_rails")
else
   puts app + "/vendor/plugins doesn't exist"
   exit 1
end


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


From aslak.hellesoy at gmail.com  Sun Jul  1 21:06:12 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 2 Jul 2007 03:06:12 +0200
Subject: [rspec-users] rspec for the svn-less (ruby version)
In-Reply-To: <20070701140521.mkcxpwec08kokoog@lcgalaska.com>
References: <20070701140521.mkcxpwec08kokoog@lcgalaska.com>
Message-ID: <8d961d900707011806h1b6afe9ag7c9d5450b3f295cb@mail.gmail.com>

On 7/2/07, barsalou <barjunk at attglobal.net> wrote:
> A couple of things:
>
> - it is defaulted to 1.0.5, but if there was a "current" I could
> probably use that instead.
>

http://rspec.rubyforge.org/download.html says 1.0.5, I'll try to
remember to mention svn://rubyforge.org/var/svn/rspec/tags/CURRENT,
which is pointing to (and will continue to point to) the latest
release.

> - it seems like everyone might not use the rspec_on_rails piece...what
> do other think?
>

Your observation is correct. Many people use RSpec without Rails. It
was always meant to be a generic tool, and it will remain that way,
while continuing Rails support in the sister Spec::Rails project.

> - there are some other checks I could put in here, suggestions are welcome.
>

I prefer cash. I will send you my account number privately :-).

> - general code suggestions are welcome as well.
>
> Mike B.
>
>
> Here is my ruby version:
>
> #!/usr/bin/ruby -w
>
> require 'ftools'
>
> def usage
>   puts
>   puts "Usage: makespec.rb <path> [<dotted-version>]"
>   puts
>   puts "Version defaults to 1.0.5"
>   puts
>   puts "Example: "
>   puts "   makespec.rb /var/www/rails/railsapp 1.0.5"
>   puts
> end
>
> if ARGV[0].nil? then
>   usage
>   puts
>   puts "You must include a pathname"
>   puts
>   exit 1
> end
>
> version = ARGV[1]
>
> if ARGV[1].nil? then
>   puts
>   puts "Defaulting to version: 1.0.5"
>   puts
>   version = "1.0.5"
> end
>
> rspec="rspec-" + version + ".tgz"
> rspecrails="rspec_on_rails-" + version + ".tgz"
> app = ARGV[0]
>
> if ! File.exist?(rspec) then
>   puts
>   puts "Rspec tarball (" + rspec + ") does not exist in the current directory"
>   puts
>   exit 1
> end
>
> if ! File.exist?(rspecrails) then
>   puts
>   puts "Rspec-rails tarball (" + rspecrails + ") does not exist in the
> current d
> irectory"
>   puts
>   exit 1
> end
>
> if FileTest.directory? app + "/vendor/plugins" then
>    system("tar","zxvf", rspec)
>    system("tar","zxvf", rspecrails)
>    cwd = Dir.pwd
>    Dir.chdir(app + "/vendor/plugins")
>    File.move(cwd + "/" + File.basename(rspec,".tgz"),app +
> "/vendor/plugins/rspec")
>    File.move(cwd + "/" + File.basename(rspecrails,".tgz"),app +
> "/vendor/plugins/rspec_on_rails")
> else
>    puts app + "/vendor/plugins doesn't exist"
>    exit 1
> end
>

Rake also makes tarballs, and I think correctly so. It seems like the
reason why our (gzipped) tarballs are broken
(http://rubyforge.org/frs/?group_id=797) is the upload/release tool we
use - or possibly (but not likely) a RubyForge bug. I don't think your
script will make a difference, but I'll definitely look into it the
next time I adress the tarball bug.

>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From work at ashleymoran.me.uk  Mon Jul  2 05:18:21 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Mon, 2 Jul 2007 10:18:21 +0100
Subject: [rspec-users] Aspects in RSpec 1.0.5
In-Reply-To: <57c63afe0706270857k317b943cg2b87184baebcc155@mail.gmail.com>
References: <3CDEC40C-9326-4424-9667-5EC656CD1C3F@ashleymoran.me.uk>
	<57c63afe0706270857k317b943cg2b87184baebcc155@mail.gmail.com>
Message-ID: <C360A30C-F8E1-4A09-9834-9C32C10DC5FE@ashleymoran.me.uk>


On 27 Jun 2007, at 16:57, David Chelimsky wrote:

> There's an RFE for this in the tracker - wanna contribute this as a
> patch? If you do, please use "facet" instead of "aspect".


I had a quick look at this - didn't get much chance because I had  
work to do too.  I had a scan through the specs and code for the  
Behaviour class, but I came a bit unstuck because adding the "facet"  
method doesn't actually add any behaviour.  So what goes in the  
specs?  Is it enough to test that a spec inside a facet (inside a  
facet?) runs?  Or a spec inside a facet (inside a facet?) fails?  Or  
should I test that specs get added to the list of those due to run?

Ashley



From dchelimsky at gmail.com  Mon Jul  2 05:22:32 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 2 Jul 2007 04:22:32 -0500
Subject: [rspec-users] Aspects in RSpec 1.0.5
In-Reply-To: <C360A30C-F8E1-4A09-9834-9C32C10DC5FE@ashleymoran.me.uk>
References: <3CDEC40C-9326-4424-9667-5EC656CD1C3F@ashleymoran.me.uk>
	<57c63afe0706270857k317b943cg2b87184baebcc155@mail.gmail.com>
	<C360A30C-F8E1-4A09-9834-9C32C10DC5FE@ashleymoran.me.uk>
Message-ID: <57c63afe0707020222p16330702u3befb471a3ddf26c@mail.gmail.com>

On 7/2/07, Ashley Moran <work at ashleymoran.me.uk> wrote:
>
> On 27 Jun 2007, at 16:57, David Chelimsky wrote:
>
> > There's an RFE for this in the tracker - wanna contribute this as a
> > patch? If you do, please use "facet" instead of "aspect".
>
>
> I had a quick look at this - didn't get much chance because I had
> work to do too.  I had a scan through the specs and code for the
> Behaviour class, but I came a bit unstuck because adding the "facet"
> method doesn't actually add any behaviour.  So what goes in the
> specs?  Is it enough to test that a spec inside a facet (inside a
> facet?) runs?  Or a spec inside a facet (inside a facet?) fails?  Or
> should I test that specs get added to the list of those due to run?

IIRC, part of the facet idea was to prepend the facet text to the
descriptive string:

describe XP do
  facet "pair programming" do
    it "should work better when team members have breath mints" do
    end
  end
end

XP
- (pair programming) should work better when team members have breath mints

So you could write examples that describe the behaviour's description string.

David


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

From dgleal at gmail.com  Mon Jul  2 06:33:54 2007
From: dgleal at gmail.com (David Leal)
Date: Mon, 2 Jul 2007 11:33:54 +0100
Subject: [rspec-users] Testing route globbing and limitations of get()
Message-ID: <1b86cb980707020333p6303d7eu4b9a53a7d927fa23@mail.gmail.com>

Hi everyone,

I'm new to rails and also to rspec, but I tried to do my homework. To answer
my questions, I searched this list's archives, the Rails API, and Google, to
no avail. Therefor, I'd be grateful if someone could point me in the right
directions:

1) There doesn't seem to be a counterpart to assert_recognizes in rspec.
route_for() won't work with route globbing (or will it?) So, how do I test
route globbing?

2) Still using route globbing, if I do

get '/something/somewhere'

rspec will complain that it couldn't find an action for
'/something/somewhere'. I suppose this is the correct behaviour, since we're
testing the controller, and not routing. However, since the controller
action is a catchall, I must pass a path to it, or it won't know what to do.
If I try to specify the path using

request.path = '/something/somewhere'
get 'my_action_name'

the path comes out as '/'.

Can anyone instruct me on how to do this correctly?

Cheers,

-- 
David Leal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070702/88d94b31/attachment.html 

From dchelimsky at gmail.com  Mon Jul  2 08:51:58 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 2 Jul 2007 07:51:58 -0500
Subject: [rspec-users] Testing route globbing and limitations of get()
In-Reply-To: <1b86cb980707020333p6303d7eu4b9a53a7d927fa23@mail.gmail.com>
References: <1b86cb980707020333p6303d7eu4b9a53a7d927fa23@mail.gmail.com>
Message-ID: <57c63afe0707020551k2e394373o8a7109167446cf9c@mail.gmail.com>

On 7/2/07, David Leal <dgleal at gmail.com> wrote:
> Hi everyone,
>
> I'm new to rails and also to rspec, but I tried to do my homework. To answer
> my questions, I searched this list's archives, the Rails API, and Google, to
> no avail. Therefor, I'd be grateful if someone could point me in the right
> directions:
>
> 1) There doesn't seem to be a counterpart to assert_recognizes in rspec.
> route_for() won't work with route globbing (or will it?) So, how do I test
> route globbing?

For now you can use assert_recognizes.

>
> 2) Still using route globbing, if I do
>
> get '/something/somewhere'

You can use full paths like that in Rails integration testing (which
is not yet supported in RSpec), but not in controllers. For controller
examples, you just use the action name:

describe SomethingController do
  it "should get me somewhere" do
    get 'somewhere'
    ...

> rspec will complain that it couldn't find an action for
> '/something/somewhere'.

That's Rails complaining. RSpec is just the messenger.

> I suppose this is the correct behaviour, since we're
> testing the controller, and not routing. However, since the controller
> action is a catchall, I must pass a path to it, or it won't know what to do.
> If I try to specify the path using
>
> request.path = '/something/somewhere'
> get 'my_action_name'
>
> the path comes out as '/'.

This is all stuff related to Integration Testing, which I'm guessing
is what you read about.

> Can anyone instruct me on how to do this correctly?

I think this should be answered by now. Write back if you still don't
understand.

Cheers,
David

>
> Cheers,
>
> --
> David Leal
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dgleal at gmail.com  Mon Jul  2 11:31:14 2007
From: dgleal at gmail.com (David Leal)
Date: Mon, 2 Jul 2007 16:31:14 +0100
Subject: [rspec-users] Testing route globbing and limitations of get()
In-Reply-To: <57c63afe0707020551k2e394373o8a7109167446cf9c@mail.gmail.com>
References: <1b86cb980707020333p6303d7eu4b9a53a7d927fa23@mail.gmail.com>
	<57c63afe0707020551k2e394373o8a7109167446cf9c@mail.gmail.com>
Message-ID: <1b86cb980707020831w8227a51k536447ab5ae3bfef@mail.gmail.com>

Hi David, thanks for your reply.

Regarding the last topic below, there's something about which I'm not quite
clear:

The catchall method that I'm trying to test works by getting a path from the
request object passed to it (during testing it's a TestRequest object). If I
understand correctly, there is no way to test this method without writing an
integration test. But shouldn't the request object honor the path I've set
instead of resetting it?

On 7/2/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> > If I try to specify the path using
> >
> > request.path = '/something/somewhere'
> > get 'my_action_name'
> >
> > the path comes out as '/'.
>
> This is all stuff related to Integration Testing, which I'm guessing
> is what you read about.
>
> > Can anyone instruct me on how to do this correctly?
>
> I think this should be answered by now. Write back if you still don't
> understand.
>

-- 
David Leal
969 572 510
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070702/a7896cb2/attachment.html 

From dchelimsky at gmail.com  Mon Jul  2 11:34:30 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 2 Jul 2007 10:34:30 -0500
Subject: [rspec-users] Testing route globbing and limitations of get()
In-Reply-To: <1b86cb980707020831w8227a51k536447ab5ae3bfef@mail.gmail.com>
References: <1b86cb980707020333p6303d7eu4b9a53a7d927fa23@mail.gmail.com>
	<57c63afe0707020551k2e394373o8a7109167446cf9c@mail.gmail.com>
	<1b86cb980707020831w8227a51k536447ab5ae3bfef@mail.gmail.com>
Message-ID: <57c63afe0707020834v2b7e5fa7x1594388315761898@mail.gmail.com>

On 7/2/07, David Leal <dgleal at gmail.com> wrote:
> Hi David, thanks for your reply.
>
> Regarding the last topic below, there's something about which I'm not quite
> clear:
>
> The catchall method that I'm trying to test works by getting a path from the
> request object passed to it (during testing it's a TestRequest object). If I
> understand correctly, there is no way to test this method without writing an
> integration test. But shouldn't the request object honor the path I've set
> instead of resetting it?

I've never tried to do what you're doing so I can't answer from
experience. What I can tell you is that the TestRequest object is part
of Rails, not rspec, so you might have some good luck on the rails
forums and mailing lists.

>
>
> On 7/2/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > If I try to specify the path using
> > >
> > > request.path = '/something/somewhere'
> > > get 'my_action_name'
> > >
> > > the path comes out as '/'.
> >
> > This is all stuff related to Integration Testing, which I'm guessing
> > is what you read about.
> >
> > > Can anyone instruct me on how to do this correctly?
> >
> > I think this should be answered by now. Write back if you still don't
> > understand.
> >
>
> --
>  David Leal
> 969 572 510
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dgleal at gmail.com  Mon Jul  2 11:43:30 2007
From: dgleal at gmail.com (David Leal)
Date: Mon, 2 Jul 2007 16:43:30 +0100
Subject: [rspec-users] Testing route globbing and limitations of get()
In-Reply-To: <57c63afe0707020834v2b7e5fa7x1594388315761898@mail.gmail.com>
References: <1b86cb980707020333p6303d7eu4b9a53a7d927fa23@mail.gmail.com>
	<57c63afe0707020551k2e394373o8a7109167446cf9c@mail.gmail.com>
	<1b86cb980707020831w8227a51k536447ab5ae3bfef@mail.gmail.com>
	<57c63afe0707020834v2b7e5fa7x1594388315761898@mail.gmail.com>
Message-ID: <1b86cb980707020843r20a1dd0erdfe42a2f1c3468fe@mail.gmail.com>

Thanks for your answers, David. I'll investigate. It's still a bit hard for
me to understand where are the boundaries between rails tests and rspec.

Cheers,

David

On 7/2/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 7/2/07, David Leal <dgleal at gmail.com> wrote:
> > Hi David, thanks for your reply.
> >
> > Regarding the last topic below, there's something about which I'm not
> quite
> > clear:
> >
> > The catchall method that I'm trying to test works by getting a path from
> the
> > request object passed to it (during testing it's a TestRequest object).
> If I
> > understand correctly, there is no way to test this method without
> writing an
> > integration test. But shouldn't the request object honor the path I've
> set
> > instead of resetting it?
>
> I've never tried to do what you're doing so I can't answer from
> experience. What I can tell you is that the TestRequest object is part
> of Rails, not rspec, so you might have some good luck on the rails
> forums and mailing lists.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070702/4d688559/attachment.html 

From dchelimsky at gmail.com  Mon Jul  2 11:46:30 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 2 Jul 2007 10:46:30 -0500
Subject: [rspec-users] Testing route globbing and limitations of get()
In-Reply-To: <1b86cb980707020843r20a1dd0erdfe42a2f1c3468fe@mail.gmail.com>
References: <1b86cb980707020333p6303d7eu4b9a53a7d927fa23@mail.gmail.com>
	<57c63afe0707020551k2e394373o8a7109167446cf9c@mail.gmail.com>
	<1b86cb980707020831w8227a51k536447ab5ae3bfef@mail.gmail.com>
	<57c63afe0707020834v2b7e5fa7x1594388315761898@mail.gmail.com>
	<1b86cb980707020843r20a1dd0erdfe42a2f1c3468fe@mail.gmail.com>
Message-ID: <57c63afe0707020846rf41c8c6re2a9c14433eca018@mail.gmail.com>

On 7/2/07, David Leal <dgleal at gmail.com> wrote:
> Thanks for your answers, David. I'll investigate. It's still a bit hard for
> me to understand where are the boundaries between rails tests and rspec.

Spec::Rails, RSpec's rails plugin, wraps test/unit, so:

Model Examples work like Rails unit tests
View, Controller and Helper Examples work like Rails functional tests

We don't have a parallel to Rails integration tests.

That help?

>
> Cheers,
>
> David
>
>
>  On 7/2/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 7/2/07, David Leal <dgleal at gmail.com> wrote:
> > > Hi David, thanks for your reply.
> > >
> > > Regarding the last topic below, there's something about which I'm not
> quite
> > > clear:
> > >
> > > The catchall method that I'm trying to test works by getting a path from
> the
> > > request object passed to it (during testing it's a TestRequest object).
> If I
> > > understand correctly, there is no way to test this method without
> writing an
> > > integration test. But shouldn't the request object honor the path I've
> set
> > > instead of resetting it?
> >
> > I've never tried to do what you're doing so I can't answer from
> > experience. What I can tell you is that the TestRequest object is part
> > of Rails, not rspec, so you might have some good luck on the rails
> > forums and mailing lists.
> >
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dgleal at gmail.com  Mon Jul  2 12:31:36 2007
From: dgleal at gmail.com (David Leal)
Date: Mon, 2 Jul 2007 17:31:36 +0100
Subject: [rspec-users] Testing route globbing and limitations of get()
In-Reply-To: <57c63afe0707020846rf41c8c6re2a9c14433eca018@mail.gmail.com>
References: <1b86cb980707020333p6303d7eu4b9a53a7d927fa23@mail.gmail.com>
	<57c63afe0707020551k2e394373o8a7109167446cf9c@mail.gmail.com>
	<1b86cb980707020831w8227a51k536447ab5ae3bfef@mail.gmail.com>
	<57c63afe0707020834v2b7e5fa7x1594388315761898@mail.gmail.com>
	<1b86cb980707020843r20a1dd0erdfe42a2f1c3468fe@mail.gmail.com>
	<57c63afe0707020846rf41c8c6re2a9c14433eca018@mail.gmail.com>
Message-ID: <1b86cb980707020931h40ce0cc1y3db1365f155b8efb@mail.gmail.com>

I see. It's simple. Sorry that I missed that.

I looked at Mephisto's tests to see how they do it. Turns out you need to
call

get :action, :path => ["all", "path", "components"] # for
/all/path/components

Again, thanks for the help, David.

Cheers,

David

On 7/2/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 7/2/07, David Leal <dgleal at gmail.com> wrote:
> > Thanks for your answers, David. I'll investigate. It's still a bit hard
> for
> > me to understand where are the boundaries between rails tests and rspec.
>
> Spec::Rails, RSpec's rails plugin, wraps test/unit, so:
>
> Model Examples work like Rails unit tests
> View, Controller and Helper Examples work like Rails functional tests
>
> We don't have a parallel to Rails integration tests.
>
> That help?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070702/f8f714b0/attachment.html 

From pritchie at videotron.ca  Tue Jul  3 14:28:30 2007
From: pritchie at videotron.ca (Patrick Ritchie)
Date: Tue, 03 Jul 2007 14:28:30 -0400
Subject: [rspec-users] testing instance variables that are set inside
	views
In-Reply-To: <8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
Message-ID: <468A954E.2060704@videotron.ca>

Hi,

I think @header may not be an implementation detail in this case.

If your layout looks like this:

...
<head>
<title><%= @header || 'Default Title' %></title>
</head>
...

And the view we are testing looks like this:

...
<h1><%= @header = 'Specific Title'></h1>
...

Then setting @header is an essential behavior for the view spec.

Or am I missing something?

Cheers!
Patrick
> @header is an implementation detail of your view that you shouldn't
> care about in your view spec at all. I recommend you use the have_tag
> matcher instead to verify what content gets rendered as expected.
>
> Aslak
>
> On 6/29/07, Jeremy Stephens <jeremy.f.stephens at vanderbilt.edu> wrote:
>   
>> Hi all,
>>
>> In my view specs (for Rails), how can I get at instance variables that
>> are set within my view?  For example, if my view looks like this:
>>
>> <% @header = "My Header" -%>
>> <div>some content</div>
>>
>> How can I get to @header from within my view spec?  I've tried @header
>> and assigns[:header] to no avail.
>>
>> TIA,
>> Jeremy
>>
>> --
>> Jeremy Stephens   Computer Systems Analyst I    School of Medicine
>>                   Department of Biostatistics   Vanderbilt University
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>     
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070703/7dc3b9d2/attachment-0001.html 

From has.sox at gmail.com  Wed Jul  4 00:38:25 2007
From: has.sox at gmail.com (Daniel N)
Date: Wed, 4 Jul 2007 14:38:25 +1000
Subject: [rspec-users] Testing Rails Associations
Message-ID: <2fff50390707032138y9ba5542pd92087d78ae33712@mail.gmail.com>

Hi,

I'm very new to rspec, so if this is not the right forum please let me know.

I'm starting to spec my models first in an existing rails app, porting from
a mix of Test::Unit, and simply_bdd amongst others.

I'm at the point where I want to test that certain associations are
present.  What I'm not sure of is should I test the association or the
method and return object.

That is, if I wanted to test a has_many should I:

Confirm the methods exist, and that the return an array etc

OR

Check that the model has the named has_many association through it's
reflections.

On one hand the second one looks like it will be a bit more robust, since if
there is a has_many relationship, then all the associated methods may be
used througout the app.  This would put testing in the one place.

On the other hand, this would be really testing the implementation of the
model rather than it's behaviour.   The behaviour is to call @
article.comments and have an array of comments returned.

Any thoughts?
Cheers
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070704/8f209d4f/attachment.html 

From aslak.hellesoy at gmail.com  Wed Jul  4 03:54:22 2007
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 4 Jul 2007 09:54:22 +0200
Subject: [rspec-users] testing instance variables that are set inside
	views
In-Reply-To: <468A954E.2060704@videotron.ca>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
	<468A954E.2060704@videotron.ca>
Message-ID: <8d961d900707040054r18c6d604pae2f291b2aec14@mail.gmail.com>

On 7/3/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>
>  Hi,
>
>  I think @header may not be an implementation detail in this case.
>
>  If your layout looks like this:
>
>  ...
>  <head>
>  <title><%= @header || 'Default Title' %></title>
>  </head>
>  ...
>
>  And the view we are testing looks like this:
>
>  ...
>  <h1><%= @header = 'Specific Title'></h1>
>  ...
>
>  Then setting @header is an essential behavior for the view spec.
>
>  Or am I missing something?
>

Before I can answer about how to test this with RSpec, I need to
understand what's going on in the code. Isn't the head part of the
layout evaluated before the body? If that's the case, what's the point
of assigning the @header variable in the view? It wouldn't change the
title anyway.

Aslak

>  Cheers!
>  Patrick
>
>
>  @header is an implementation detail of your view that you shouldn't
> care about in your view spec at all. I recommend you use the have_tag
> matcher instead to verify what content gets rendered as expected.
>
> Aslak
>
> On 6/29/07, Jeremy Stephens
> <jeremy.f.stephens at vanderbilt.edu> wrote:
>
>
>  Hi all,
>
> In my view specs (for Rails), how can I get at instance variables that
> are set within my view? For example, if my view looks like this:
>
> <% @header = "My Header" -%>
> <div>some content</div>
>
> How can I get to @header from within my view spec? I've tried @header
> and assigns[:header] to no avail.
>
> TIA,
> Jeremy
>
> --
> Jeremy Stephens Computer Systems Analyst I School of Medicine
>  Department of Biostatistics Vanderbilt University
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>  _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From work at ashleymoran.me.uk  Wed Jul  4 04:42:01 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Wed, 4 Jul 2007 09:42:01 +0100
Subject: [rspec-users] Aspects in RSpec 1.0.5
In-Reply-To: <57c63afe0707020222p16330702u3befb471a3ddf26c@mail.gmail.com>
References: <3CDEC40C-9326-4424-9667-5EC656CD1C3F@ashleymoran.me.uk>
	<57c63afe0706270857k317b943cg2b87184baebcc155@mail.gmail.com>
	<C360A30C-F8E1-4A09-9834-9C32C10DC5FE@ashleymoran.me.uk>
	<57c63afe0707020222p16330702u3befb471a3ddf26c@mail.gmail.com>
Message-ID: <0FE18859-1EFF-4968-B566-5AB445B4CAF8@ashleymoran.me.uk>


On 2 Jul 2007, at 10:22, David Chelimsky wrote:

> IIRC, part of the facet idea was to prepend the facet text to the
> descriptive string:
>
> describe XP do
>   facet "pair programming" do
>     it "should work better when team members have breath mints" do
>     end
>   end
> end
>
> XP
> - (pair programming) should work better when team members have  
> breath mints

I never knew that :)

>
> So you could write examples that describe the behaviour's  
> description string.

I'll have another go this weekend, again if I get chance...

Just to clear something up, can you define Behaviour and Example for  
me?  When I went through the code I got the impression that a  
Behaviour is everything in the "describe" block and an Example is  
everything in an "it" block.

Ashley


From dchelimsky at gmail.com  Wed Jul  4 07:09:00 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 4 Jul 2007 06:09:00 -0500
Subject: [rspec-users] Aspects in RSpec 1.0.5
In-Reply-To: <0FE18859-1EFF-4968-B566-5AB445B4CAF8@ashleymoran.me.uk>
References: <3CDEC40C-9326-4424-9667-5EC656CD1C3F@ashleymoran.me.uk>
	<57c63afe0706270857k317b943cg2b87184baebcc155@mail.gmail.com>
	<C360A30C-F8E1-4A09-9834-9C32C10DC5FE@ashleymoran.me.uk>
	<57c63afe0707020222p16330702u3befb471a3ddf26c@mail.gmail.com>
	<0FE18859-1EFF-4968-B566-5AB445B4CAF8@ashleymoran.me.uk>
Message-ID: <57c63afe0707040409s4ccfe6daib4512fadbd9d33da@mail.gmail.com>

On 7/4/07, Ashley Moran <work at ashleymoran.me.uk> wrote:
>
> On 2 Jul 2007, at 10:22, David Chelimsky wrote:
>
> > IIRC, part of the facet idea was to prepend the facet text to the
> > descriptive string:
> >
> > describe XP do
> >   facet "pair programming" do
> >     it "should work better when team members have breath mints" do
> >     end
> >   end
> > end
> >
> > XP
> > - (pair programming) should work better when team members have
> > breath mints
>
> I never knew that :)
>
> >
> > So you could write examples that describe the behaviour's
> > description string.
>
> I'll have another go this weekend, again if I get chance...
>
> Just to clear something up, can you define Behaviour and Example for
> me?  When I went through the code I got the impression that a
> Behaviour is everything in the "describe" block and an Example is
> everything in an "it" block.

That's correct.

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

From pritchie at videotron.ca  Wed Jul  4 11:35:03 2007
From: pritchie at videotron.ca (Patrick Ritchie)
Date: Wed, 04 Jul 2007 11:35:03 -0400
Subject: [rspec-users] testing instance variables that are set inside
	views
In-Reply-To: <8d961d900707040054r18c6d604pae2f291b2aec14@mail.gmail.com>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
	<468A954E.2060704@videotron.ca>
	<8d961d900707040054r18c6d604pae2f291b2aec14@mail.gmail.com>
Message-ID: <468BBE27.4080202@videotron.ca>

aslak hellesoy wrote:
> On 7/3/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>   
>>  Hi,
>>
>>  I think @header may not be an implementation detail in this case.
>>
>>  If your layout looks like this:
>>
>>  ...
>>  <head>
>>  <title><%= @header || 'Default Title' %></title>
>>  </head>
>>  ...
>>
>>  And the view we are testing looks like this:
>>
>>  ...
>>  <h1><%= @header = 'Specific Title'></h1>
>>  ...
>>
>>  Then setting @header is an essential behavior for the view spec.
>>
>>  Or am I missing something?
>>
>>     
>
> Before I can answer about how to test this with RSpec, I need to
> understand what's going on in the code. Isn't the head part of the
> layout evaluated before the body? If that's the case, what's the point
> of assigning the @header variable in the view? It wouldn't change the
> title anyway
The layout is evaluated after the view so the above code is a useful way 
to include some piece of data in the head without having to initialize 
it in the controller. Very handy for things like head/title or view 
specific onload js etc...

Cheers!
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070704/4b0e5cf3/attachment.html 

From dchelimsky at gmail.com  Wed Jul  4 11:41:59 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 4 Jul 2007 10:41:59 -0500
Subject: [rspec-users] testing instance variables that are set inside
	views
In-Reply-To: <468BBE27.4080202@videotron.ca>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
	<468A954E.2060704@videotron.ca>
	<8d961d900707040054r18c6d604pae2f291b2aec14@mail.gmail.com>
	<468BBE27.4080202@videotron.ca>
Message-ID: <57c63afe0707040841p7b88d46cha488c336c66d53d9@mail.gmail.com>

On 7/4/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>
>  aslak hellesoy wrote:
>  On 7/3/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>
>
>  Hi,
>
>  I think @header may not be an implementation detail in this case.
>
>  If your layout looks like this:
>
>  ...
>  <head>
>  <title><%= @header || 'Default Title' %></title>
>  </head>
>  ...
>
>  And the view we are testing looks like this:
>
>  ...
>  <h1><%= @header = 'Specific Title'></h1>
>  ...
>
>  Then setting @header is an essential behavior for the view spec.
>
>  Or am I missing something?
>
>
>  Before I can answer about how to test this with RSpec, I need to
> understand what's going on in the code. Isn't the head part of the
> layout evaluated before the body? If that's the case, what's the point
> of assigning the @header variable in the view? It wouldn't change the
> title anyway
>  The layout is evaluated after the view so the above code is a useful way to
> include some piece of data in the head without having to initialize it in
> the controller. Very handy for things like head/title or view specific
> onload js etc...

Correct me if I'm wrong, but it seems to me that the behavior you're
interested in is that the right thing shows up in the title:

response.should have_tag('title', 'whatever I am expecting')

Am I missing something?


>
>  Cheers!
>  Patrick
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From pritchie at videotron.ca  Wed Jul  4 12:09:31 2007
From: pritchie at videotron.ca (Patrick Ritchie)
Date: Wed, 04 Jul 2007 12:09:31 -0400
Subject: [rspec-users] testing instance variables that are set inside
	views
In-Reply-To: <57c63afe0707040841p7b88d46cha488c336c66d53d9@mail.gmail.com>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
	<468A954E.2060704@videotron.ca>
	<8d961d900707040054r18c6d604pae2f291b2aec14@mail.gmail.com>
	<468BBE27.4080202@videotron.ca>
	<57c63afe0707040841p7b88d46cha488c336c66d53d9@mail.gmail.com>
Message-ID: <468BC63B.3000805@videotron.ca>

David Chelimsky wrote:
> On 7/4/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>   
>>  aslak hellesoy wrote:
>>  On 7/3/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>>
>>
>>  Hi,
>>
>>  I think @header may not be an implementation detail in this case.
>>
>>  If your layout looks like this:
>>
>>  ...
>>  <head>
>>  <title><%= @header || 'Default Title' %></title>
>>  </head>
>>  ...
>>
>>  And the view we are testing looks like this:
>>
>>  ...
>>  <h1><%= @header = 'Specific Title'></h1>
>>  ...
>>
>>  Then setting @header is an essential behavior for the view spec.
>>
>>  Or am I missing something?
>>
>>
>>  Before I can answer about how to test this with RSpec, I need to
>> understand what's going on in the code. Isn't the head part of the
>> layout evaluated before the body? If that's the case, what's the point
>> of assigning the @header variable in the view? It wouldn't change the
>> title anyway
>>  The layout is evaluated after the view so the above code is a useful way to
>> include some piece of data in the head without having to initialize it in
>> the controller. Very handy for things like head/title or view specific
>> onload js etc...
>>     
>
> Correct me if I'm wrong, but it seems to me that the behavior you're
> interested in is that the right thing shows up in the title:
>
> response.should have_tag('title', 'whatever I am expecting')
>
> Am I missing something?
>   
I could do that, but that's not the really behavior I'm interested in 
for the view. I'd rather look at the title tag in my layout spec and the 
instance variable in my view.

It doesn't really make a difference in this simple case, but it would if 
the title was inserted from a partial called from the layout, or the 
instance variable was used in multiple places in the layout.

Cheers!
Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070704/624f3d80/attachment.html 

From don at donpetersen.net  Wed Jul  4 07:52:25 2007
From: don at donpetersen.net (Don Petersen)
Date: Wed, 4 Jul 2007 06:52:25 -0500
Subject: [rspec-users] testing instance variables that are set inside
	views
In-Reply-To: <468BC63B.3000805@videotron.ca>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
	<468A954E.2060704@videotron.ca>
	<8d961d900707040054r18c6d604pae2f291b2aec14@mail.gmail.com>
	<468BBE27.4080202@videotron.ca>
	<57c63afe0707040841p7b88d46cha488c336c66d53d9@mail.gmail.com>
	<468BC63B.3000805@videotron.ca>
Message-ID: <BC52DDAF-6C93-4496-88AE-4255D155F62A@donpetersen.net>

I can sympathize with not wanting to just verify the final html  
output, even though it would probably be sufficient in this simple case.

I'm a big fan of helpers for any logic in views, even simple stuff  
like this.  If you had a couple of methods in your ApplicationHelper  
that handled setting and getting the page title value, that would be  
very easy to test.

Approaching it this way, you can use the helper specs to verify that  
the actual set/get logic worked.  You can even take that whole 'title  
= @header || "Default Title"' logic out of your layout if you wanted,  
and put it in the helper where you're only testing that logic and  
nothing more.

So in your view spec, where you had previously been wanting to test  
if an instance variable had been set, now you just need to verify  
that the helper method was called.  Like so:
@controller.template.should_receive(:set_page_title)

That's how I have done this very logic in the past, and it feels  
right to me.

Alternately, if you don't want to use helpers, you might use  
"content_for"(http://api.rubyonrails.org/classes/ActionView/Helpers/ 
CaptureHelper.html).  It's probably overkill for just a basic string  
like this, but maybe you can rig it to work in this case.

Don

On Jul 4, 2007, at 11:09 AM, Patrick Ritchie wrote:

> David Chelimsky wrote:
>> On 7/4/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>>> aslak hellesoy wrote: On 7/3/07, Patrick Ritchie  
>>> <pritchie at videotron.ca> wrote: Hi, I think @header may not be an  
>>> implementation detail in this case. If your layout looks like  
>>> this: ... ... And the view we are testing looks like this: ... <% 
>>> = @header = 'Specific Title'> ... Then setting @header is an  
>>> essential behavior for the view spec. Or am I missing something?  
>>> Before I can answer about how to test this with RSpec, I need to  
>>> understand what's going on in the code. Isn't the head part of  
>>> the layout evaluated before the body? If that's the case, what's  
>>> the point of assigning the @header variable in the view? It  
>>> wouldn't change the title anyway The layout is evaluated after  
>>> the view so the above code is a useful way to include some piece  
>>> of data in the head without having to initialize it in the  
>>> controller. Very handy for things like head/title or view  
>>> specific onload js etc...
>> Correct me if I'm wrong, but it seems to me that the behavior  
>> you're interested in is that the right thing shows up in the  
>> title: response.should have_tag('title', 'whatever I am  
>> expecting') Am I missing something?
> I could do that, but that's not the really behavior I'm interested  
> in for the view. I'd rather look at the title tag in my layout spec  
> and the instance variable in my view.
>
> It doesn't really make a difference in this simple case, but it  
> would if the title was inserted from a partial called from the  
> layout, or the instance variable was used in multiple places in the  
> layout.
>
> Cheers!
> Patrick
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From pritchie at videotron.ca  Wed Jul  4 13:55:20 2007
From: pritchie at videotron.ca (Patrick Ritchie)
Date: Wed, 04 Jul 2007 13:55:20 -0400
Subject: [rspec-users] testing instance variables that are set inside
	views
In-Reply-To: <BC52DDAF-6C93-4496-88AE-4255D155F62A@donpetersen.net>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
	<468A954E.2060704@videotron.ca>
	<8d961d900707040054r18c6d604pae2f291b2aec14@mail.gmail.com>
	<468BBE27.4080202@videotron.ca>
	<57c63afe0707040841p7b88d46cha488c336c66d53d9@mail.gmail.com>
	<468BC63B.3000805@videotron.ca>
	<BC52DDAF-6C93-4496-88AE-4255D155F62A@donpetersen.net>
Message-ID: <468BDF08.5040209@videotron.ca>

Hi Don,

Thanks for the tip! That looks like a great way to handle this case.

So what does everybody think, is this the definitive answer for setting 
instance variables in your views? (use a helper) or are their cases 
where we may still want to check instance variables in view specs?

Cheers!
Patrick
> I can sympathize with not wanting to just verify the final html  
> output, even though it would probably be sufficient in this simple case.
>
> I'm a big fan of helpers for any logic in views, even simple stuff  
> like this.  If you had a couple of methods in your ApplicationHelper  
> that handled setting and getting the page title value, that would be  
> very easy to test.
>
> Approaching it this way, you can use the helper specs to verify that  
> the actual set/get logic worked.  You can even take that whole 'title  
> = @header || "Default Title"' logic out of your layout if you wanted,  
> and put it in the helper where you're only testing that logic and  
> nothing more.
>
> So in your view spec, where you had previously been wanting to test  
> if an instance variable had been set, now you just need to verify  
> that the helper method was called.  Like so:
> @controller.template.should_receive(:set_page_title)
>
> That's how I have done this very logic in the past, and it feels  
> right to me.
>
> Alternately, if you don't want to use helpers, you might use  
> "content_for"(http://api.rubyonrails.org/classes/ActionView/Helpers/ 
> CaptureHelper.html).  It's probably overkill for just a basic string  
> like this, but maybe you can rig it to work in this case.
>
> Don
>
> On Jul 4, 2007, at 11:09 AM, Patrick Ritchie wrote:
>
>   
>> David Chelimsky wrote:
>>     
>>> On 7/4/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>>>       
>>>> aslak hellesoy wrote: On 7/3/07, Patrick Ritchie  
>>>> <pritchie at videotron.ca> wrote: Hi, I think @header may not be an  
>>>> implementation detail in this case. If your layout looks like  
>>>> this: ... ... And the view we are testing looks like this: ... <% 
>>>> = @header = 'Specific Title'> ... Then setting @header is an  
>>>> essential behavior for the view spec. Or am I missing something?  
>>>> Before I can answer about how to test this with RSpec, I need to  
>>>> understand what's going on in the code. Isn't the head part of  
>>>> the layout evaluated before the body? If that's the case, what's  
>>>> the point of assigning the @header variable in the view? It  
>>>> wouldn't change the title anyway The layout is evaluated after  
>>>> the view so the above code is a useful way to include some piece  
>>>> of data in the head without having to initialize it in the  
>>>> controller. Very handy for things like head/title or view  
>>>> specific onload js etc...
>>>>         
>>> Correct me if I'm wrong, but it seems to me that the behavior  
>>> you're interested in is that the right thing shows up in the  
>>> title: response.should have_tag('title', 'whatever I am  
>>> expecting') Am I missing something?
>>>       
>> I could do that, but that's not the really behavior I'm interested  
>> in for the view. I'd rather look at the title tag in my layout spec  
>> and the instance variable in my view.
>>
>> It doesn't really make a difference in this simple case, but it  
>> would if the title was inserted from a partial called from the  
>> layout, or the instance variable was used in multiple places in the  
>> layout.
>>
>> Cheers!
>> Patrick
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>     
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070704/ebf47d56/attachment.html 

From dchelimsky at gmail.com  Wed Jul  4 14:02:11 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 4 Jul 2007 13:02:11 -0500
Subject: [rspec-users] testing instance variables that are set inside
	views
In-Reply-To: <468BDF08.5040209@videotron.ca>
References: <468576DB.7060803@vanderbilt.edu>
	<8d961d900706300052n47b6798ci16a2d0b5667ccd42@mail.gmail.com>
	<468A954E.2060704@videotron.ca>
	<8d961d900707040054r18c6d604pae2f291b2aec14@mail.gmail.com>
	<468BBE27.4080202@videotron.ca>
	<57c63afe0707040841p7b88d46cha488c336c66d53d9@mail.gmail.com>
	<468BC63B.3000805@videotron.ca>
	<BC52DDAF-6C93-4496-88AE-4255D155F62A@donpetersen.net>
	<468BDF08.5040209@videotron.ca>
Message-ID: <57c63afe0707041102o4e06279cwc1f076e2e5931915@mail.gmail.com>

On 7/4/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>
>  Hi Don,
>
>  Thanks for the tip! That looks like a great way to handle this case.
>
>  So what does everybody think, is this the definitive answer for setting
> instance variables in your views? (use a helper) or are their cases where we
> may still want to check instance variables in view specs?

>From a design perspective, conventional wisdom suggests that you don't
put any decision making or control in your views. Doing this in
helpers is the Rails Way.

>From a practical perspective, there is no direct support for accessing
instance variables in views in rspec, so the helper route seems to be
the path of least resistance. Of course, you could always use
instance_eval. This IS Ruby, after all. But I wouldn't recommend it.

Cheers,
David

>
>  Cheers!
>  Patrick
>
>
>  I can sympathize with not wanting to just verify the final html
> output, even though it would probably be sufficient in this simple case.
>
> I'm a big fan of helpers for any logic in views, even simple stuff
> like this. If you had a couple of methods in your ApplicationHelper
> that handled setting and getting the page title value, that would be
> very easy to test.
>
> Approaching it this way, you can use the helper specs to verify that
> the actual set/get logic worked. You can even take that whole 'title
> = @header || "Default Title"' logic out of your layout if you wanted,
> and put it in the helper where you're only testing that logic and
> nothing more.
>
> So in your view spec, where you had previously been wanting to test
> if an instance variable had been set, now you just need to verify
> that the helper method was called. Like so:
> @controller.template.should_receive(:set_page_title)
>
> That's how I have done this very logic in the past, and it feels
> right to me.
>
> Alternately, if you don't want to use helpers, you might use
> "content_for"(http://api.rubyonrails.org/classes/ActionView/Helpers/
> CaptureHelper.html). It's probably overkill for just a basic string
> like this, but maybe you can rig it to work in this case.
>
> Don
>
> On Jul 4, 2007, at 11:09 AM, Patrick Ritchie wrote:
>
>
>
>  David Chelimsky wrote:
>
>
>  On 7/4/07, Patrick Ritchie <pritchie at videotron.ca> wrote:
>
>
>  aslak hellesoy wrote: On 7/3/07, Patrick Ritchie
> <pritchie at videotron.ca> wrote: Hi, I think @header may not be an
> implementation detail in this case. If your layout looks like
> this: ... ... And the view we are testing looks like this: ... <%
> = @header = 'Specific Title'> ... Then setting @header is an
> essential behavior for the view spec. Or am I missing something?
> Before I can answer about how to test this with RSpec, I need to
> understand what's going on in the code. Isn't the head part of
> the layout evaluated before the body? If that's the case, what's
> the point of assigning the @header variable in the view? It
> wouldn't change the title anyway The layout is evaluated after
> the view so the above code is a useful way to include some piece
> of data in the head without having to initialize it in the
> controller. Very handy for things like head/title or view
> specific onload js etc...
>
>  Correct me if I'm wrong, but it seems to me that the behavior
> you're interested in is that the right thing shows up in the
> title: response.should have_tag('title', 'whatever I am
> expecting') Am I missing something?
>
>  I could do that, but that's not the really behavior I'm interested
> in for the view. I'd rather look at the title tag in my layout spec
> and the instance variable in my view.
>
> It doesn't really make a difference in this simple case, but it
> would if the title was inserted from a partial called from the
> layout, or the instance variable was used in multiple places in the
> layout.
>
> Cheers!
> Patrick
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>  _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From win at wincent.com  Thu Jul  5 04:28:22 2007
From: win at wincent.com (Wincent Colaiuta)
Date: Thu, 5 Jul 2007 10:28:22 +0200
Subject: [rspec-users] Nicer failure message formatting
In-Reply-To: <190A2F5D-96D3-49D2-805A-4B8209B32F53@wincent.com>
References: <FCC75AB0-FC9B-4398-90F5-9F88D8F07240@hobocentral.net>
	<190A2F5D-96D3-49D2-805A-4B8209B32F53@wincent.com>
Message-ID: <389B0522-7590-4B3D-AC88-162B80BC9F1E@wincent.com>

El 22/6/2007, a las 15:34, Wincent Colaiuta escribi?:

> El 22/6/2007, a las 14:36, Tom Locke escribi?:
>
>> Easier to read:
>>
>> expected:
>> "this is a very long string blah blah"
>> got:
>> "this is a very very long string blah blah"
>> (using ==)
>>
>> Comments?
>
> For me even easier to read would be:
>
> expected: "this is a very long string blah blah"
> got     : "this is a very very long string blah blah"
> (using ==)

I've whipped up a patch for this against the current trunk (r2153). I  
was sick of seeing output like this:

<http://pastie.textmate.org/76179>

Now I see output like this:

<http://pastie.textmate.org/76180>

So for really short strings ("foo" vs "bar") readability is about the  
same, and for longer strings like the ones in the linked examples the  
readability is much improved. For *really* long strings (which wrap  
over multiple lines) readability in the console still sucks. You can  
see this for yourself by resizing your browser window to see how  
readability goes down as soon as wrapping starts to take place.

But this is still a big improvement. If you run your specs from  
inside TextMate then even long strings are much more readable,  
because SpecMate doesn't perform soft wrapping of long lines when  
showing diffs.

Pasting the diff here:

<http://pastie.textmate.org/76181>

Will also try submitting via RubyForge, but I have a lot of troubling  
logging in thanks to the transparent proxy imposed by my ISP... :-(

Cheers,
Wincent


From win at wincent.com  Thu Jul  5 04:32:53 2007
From: win at wincent.com (Wincent Colaiuta)
Date: Thu, 5 Jul 2007 10:32:53 +0200
Subject: [rspec-users] Nicer failure message formatting
In-Reply-To: <389B0522-7590-4B3D-AC88-162B80BC9F1E@wincent.com>
References: <FCC75AB0-FC9B-4398-90F5-9F88D8F07240@hobocentral.net>
	<190A2F5D-96D3-49D2-805A-4B8209B32F53@wincent.com>
	<389B0522-7590-4B3D-AC88-162B80BC9F1E@wincent.com>
Message-ID: <B44881B7-6828-41A2-8ECE-5AA3EC53F04D@wincent.com>

El 5/7/2007, a las 10:28, Wincent Colaiuta escribi?:

> Pasting the diff here:
>
> <http://pastie.textmate.org/76181>
>
> Will also try submitting via RubyForge, but I have a lot of troubling
> logging in thanks to the transparent proxy imposed by my ISP... :-(

Managed to stay logged in long enough to get it submitted:

<http://rubyforge.org/tracker/index.php? 
func=detail&aid=12010&group_id=797&atid=3151>

Cheers,
Wincent


From has.sox at gmail.com  Thu Jul  5 09:28:28 2007
From: has.sox at gmail.com (Daniel N)
Date: Thu, 5 Jul 2007 23:28:28 +1000
Subject: [rspec-users] mocking methods in the controller.
Message-ID: <2fff50390707050628i55391c60v75ea4b1b12e1311c@mail.gmail.com>

Hi,

I'm very new to rspec so please be patient with me.

I've tried to take some of my tests out of the controller specs to check for
things that are rendered.

This has not worked so well, since my views have the controller method

current_user

in quite a few places.

Is there any way that I can define this so that my views will be executed?
Will this same thing occur for all helper methods that are definied in the
controller?

Cheers
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070705/1a8e6a3a/attachment.html 

From work at ashleymoran.me.uk  Thu Jul  5 11:30:09 2007
From: work at ashleymoran.me.uk (Ashley Moran)
Date: Thu, 5 Jul 2007 16:30:09 +0100
Subject: [rspec-users] Fwd: argument constraints docs on www site
References: <418CA05B-B966-472B-BE3E-EAFDDC6AF2B3@codeweavers.net>
Message-ID: <C1D1AD28-95D3-496B-8EDB-C1F226F2BADD@ashleymoran.me.uk>

Hi

Thought I had found an actual issue here but turned out it was me  
being an idiot.  In the process though, I noticed that the rspec page  
docs say you should use ":anything" rather than "anything()",  
although it is deprecated.  Any reason for that or does it just need  
updating?

Ashley


From dchelimsky at gmail.com  Thu Jul  5 11:40:37 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 5 Jul 2007 10:40:37 -0500
Subject: [rspec-users] Fwd: argument constraints docs on www site
In-Reply-To: <C1D1AD28-95D3-496B-8EDB-C1F226F2BADD@ashleymoran.me.uk>
References: <418CA05B-B966-472B-BE3E-EAFDDC6AF2B3@codeweavers.net>
	<C1D1AD28-95D3-496B-8EDB-C1F226F2BADD@ashleymoran.me.uk>
Message-ID: <57c63afe0707050840r7ca7e70ah383e860e4bc7d7f6@mail.gmail.com>

On 7/5/07, Ashley Moran <work at ashleymoran.me.uk> wrote:
> Hi
>
> Thought I had found an actual issue here but turned out it was me
> being an idiot.  In the process though, I noticed that the rspec page
> docs say you should use ":anything" rather than "anything()",
> although it is deprecated.  Any reason for that or does it just need
> updating?

It's updated in the trunk docs, so it'll get updated when we release
1.0.6. We don't generally update the site between releases because
it's a hassle to manage.

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

From ashley.moran at codeweavers.net  Thu Jul  5 10:36:01 2007
From: ashley.moran at codeweavers.net (Ashley Moran)
Date: Thu, 5 Jul 2007 15:36:01 +0100
Subject: [rspec-users] argument constraints docs on www site
Message-ID: <418CA05B-B966-472B-BE3E-EAFDDC6AF2B3@codeweavers.net>

Hi

Thought I had found an actual issue here but turned out it was me  
being an idiot.  In the process though, I noticed that the rspec page  
docs say you should use ":anything" rather than "anything()",  
although it is deprecated.  Any reason for that or does it just need  
updating?

Ashley



--

?If only we?d been written in Ruby.?
Steve from Urbis upon hearing that the junk segment ?ALU? is repeated  
300,000 times in the human genome

Codeweavers Ltd (Registered in England and Wales No. 04092394. VAT  
registration no. 823826816)
Address: Unit 11, Imex Technology Park, ST4 8LJ.     Tel: 0870 443 0888




From cwdinfo at gmail.com  Thu Jul  5 15:09:15 2007
From: cwdinfo at gmail.com (s.ross)
Date: Thu, 5 Jul 2007 12:09:15 -0700
Subject: [rspec-users] Wording describe/it so specdocs look good
In-Reply-To: <c96c19520706280121o530e5b0bi8b3ce4d6a2f27c8e@mail.gmail.com>
References: <c96c19520706280121o530e5b0bi8b3ce4d6a2f27c8e@mail.gmail.com>
Message-ID: <103B3F02-F94B-4BED-80B0-31ECD1006BBD@gmail.com>

I'm looking through my specs and they work great, but they don't read  
as English. I'm wondering how others are phrasing these. Here are  
some examples:

describe Agent do
   it 'should be possible to create one' do
   end
end

This reads as "Agent should be possible to create one". Any  
suggestions how the describe/it might better be worded?

Thx

From edward.og at gmail.com  Thu Jul  5 15:19:59 2007
From: edward.og at gmail.com (Edward Ocampo-Gooding)
Date: Thu, 05 Jul 2007 15:19:59 -0400
Subject: [rspec-users] Wording describe/it so specdocs look good
In-Reply-To: <103B3F02-F94B-4BED-80B0-31ECD1006BBD@gmail.com>
References: <c96c19520706280121o530e5b0bi8b3ce4d6a2f27c8e@mail.gmail.com>
	<103B3F02-F94B-4BED-80B0-31ECD1006BBD@gmail.com>
Message-ID: <468D445F.9070507@gmail.com>

> I'm looking through my specs and they work great, but they don't read  
> as English. I'm wondering how others are phrasing these. Here are  
> some examples:
> 
> describe Agent do
>    it 'should be possible to create one' do
>    end
> end

Does

describe Agent do
   it 'should be createable' do
	# stuff
   end
end

work for you?

From cwdinfo at gmail.com  Thu Jul  5 15:39:27 2007
From: cwdinfo at gmail.com (s.ross)
Date: Thu, 5 Jul 2007 12:39:27 -0700
Subject: [rspec-users] Wording describe/it so specdocs look good
In-Reply-To: <468D445F.9070507@gmail.com>
References: <c96c19520706280121o530e5b0bi8b3ce4d6a2f27c8e@mail.gmail.com>
	<103B3F02-F94B-4BED-80B0-31ECD1006BBD@gmail.com>
	<468D445F.9070507@gmail.com>
Message-ID: <56ECC68B-4B02-497F-BEEA-AD795F6B2D10@gmail.com>

For that simple case, yes. But how about the case where I specify:

Agent "should not be possible for the same user to rate the same  
agent twice with same kind of transaction"

The English grammar gets a bit twisty. Perhaps:

Agent "should not allow the same user to rate the same agent twice  
with the same kind of transaction"

Thoughts?


On Jul 5, 2007, at 12:19 PM, Edward Ocampo-Gooding wrote:

>> I'm looking through my specs and they work great, but they don't read
>> as English. I'm wondering how others are phrasing these. Here are
>> some examples:
>>
>> describe Agent do
>>    it 'should be possible to create one' do
>>    end
>> end
>
> Does
>
> describe Agent do
>    it 'should be createable' do
> 	# stuff
>    end
> end
>
> work for you?
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From dchelimsky at gmail.com  Thu Jul  5 15:52:46 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 5 Jul 2007 14:52:46 -0500
Subject: [rspec-users] Wording describe/it so specdocs look good
In-Reply-To: <56ECC68B-4B02-497F-BEEA-AD795F6B2D10@gmail.com>
References: <c96c19520706280121o530e5b0bi8b3ce4d6a2f27c8e@mail.gmail.com>
	<103B3F02-F94B-4BED-80B0-31ECD1006BBD@gmail.com>
	<468D445F.9070507@gmail.com>
	<56ECC68B-4B02-497F-BEEA-AD795F6B2D10@gmail.com>
Message-ID: <57c63afe0707051252o6c248babw56aa3f76b2ecf292@mail.gmail.com>

On 7/5/07, s.ross <cwdinfo at gmail.com> wrote:
> For that simple case, yes. But how about the case where I specify:
>
> Agent "should not be possible for the same user to rate the same
> agent twice with same kind of transaction"
>
> The English grammar gets a bit twisty. Perhaps:
>
> Agent "should not allow the same user to rate the same agent twice
> with the same kind of transaction"
>
> Thoughts?

How would you phrase all this with context/specify? Or, a bit further
off target, TestCase/test_method?

>
>
> On Jul 5, 2007, at 12:19 PM, Edward Ocampo-Gooding wrote:
>
> >> I'm looking through my specs and they work great, but they don't read
> >> as English. I'm wondering how others are phrasing these. Here are
> >> some examples:
> >>
> >> describe Agent do
> >>    it 'should be possible to create one' do
> >>    end
> >> end
> >
> > Does
> >
> > describe Agent do
> >    it 'should be createable' do
> >       # stuff
> >    end
> > end
> >
> > work for you?
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From cwdinfo at gmail.com  Thu Jul  5 16:06:41 2007
From: cwdinfo at gmail.com (s.ross)
Date: Thu, 5 Jul 2007 13:06:41 -0700
Subject: [rspec-users] Wording describe/it so specdocs look good
In-Reply-To: <57c63afe0707051252o6c248babw56aa3f76b2ecf292@mail.gmail.com>
References: <c96c19520706280121o530e5b0bi8b3ce4d6a2f27c8e@mail.gmail.com>
	<103B3F02-F94B-4BED-80B0-31ECD1006BBD@gmail.com>
	<468D445F.9070507@gmail.com>
	<56ECC68B-4B02-497F-BEEA-AD795F6B2D10@gmail.com>
	<57c63afe0707051252o6c248babw56aa3f76b2ecf292@mail.gmail.com>
Message-ID: <F70F8E08-779D-4584-A985-8468A41FA96C@gmail.com>


On Jul 5, 2007, at 12:52 PM, David Chelimsky wrote:

>> Agent "should not allow the same user to rate the same agent twice
>> with the same kind of transaction"
>>
>> Thoughts?
>
> How would you phrase all this with context/specify? Or, a bit further
> off target, TestCase/test_method?
>

I wouldn't phrase it differently with context/specify and with  
TestCase/test_method, I'd probably care less because I wouldn't have  
been trained to create beautiful, self-documenting example  
descriptions :)

I'm just thinking there must be a nicer way to express what I mean.

From edward.og at gmail.com  Thu Jul  5 16:24:40 2007
From: edward.og at gmail.com (Edward Ocampo-Gooding)
Date: Thu, 05 Jul 2007 16:24:40 -0400
Subject: [rspec-users] Wording describe/it so specdocs look good
In-Reply-To: <56ECC68B-4B02-497F-BEEA-AD795F6B2D10@gmail.com>
References: <c96c19520706280121o530e5b0bi8b3ce4d6a2f27c8e@mail.gmail.com>	<103B3F02-F94B-4BED-80B0-31ECD1006BBD@gmail.com>	<468D445F.9070507@gmail.com>
	<56ECC68B-4B02-497F-BEEA-AD795F6B2D10@gmail.com>
Message-ID: <468D5388.8080603@gmail.com>

Does this work?

describe Agent, "rated by a user with the same kind of transaction" do
   it 'should not be rated twice' do
     # stuff
   end
end

s.ross wrote:
> For that simple case, yes. But how about the case where I specify:
> 
> Agent "should not be possible for the same user to rate the same  
> agent twice with same kind of transaction"
> 
> The English grammar gets a bit twisty. Perhaps:
> 
> Agent "should not allow the same user to rate the same agent twice  
> with the same kind of transaction"
> 
> Thoughts?
> 
> 
> On Jul 5, 2007, at 12:19 PM, Edward Ocampo-Gooding wrote:
> 
>>> I'm looking through my specs and they work great, but they don't read
>>> as English. I'm wondering how others are phrasing these. Here are
>>> some examples:
>>>
>>> describe Agent do
>>>    it 'should be possible to create one' do
>>>    end
>>> end
>> Does
>>
>> describe Agent do
>>    it 'should be createable' do
>> 	# stuff
>>    end
>> end
>>
>> work for you?
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
> 
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
> 

From don at donpetersen.net  Thu Jul  5 16:25:28 2007
From: don at donpetersen.net (Don Petersen)
Date: Thu, 5 Jul 2007 15:25:28 -0500
Subject: [rspec-users] Wording describe/it so specdocs look good
In-Reply-To: <F70F8E08-779D-4584-A985-8468A41FA96C@gmail.com>
References: <c96c19520706280121o530e5b0bi8b3ce4d6a2f27c8e@mail.gmail.com>
	<103B3F02-F94B-4BED-80B0-31ECD1006BBD@gmail.com>
	<468D445F.9070507@gmail.com>
	<56ECC68B-4B02-497F-BEEA-AD795F6B2D10@gmail.com>
	<57c63afe0707051252o6c248babw56aa3f76b2ecf292@mail.gmail.com>
	<F70F8E08-779D-4584-A985-8468A41FA96C@gmail.com>
Message-ID: <753DD095-4ECE-48F9-B4D1-31A59450ACEC@donpetersen.net>

I have no idea what the business logic is, but I guess I see a few  
words there which could be more concise.

"should not allow" could become "disallows".  Not much shorter, but I  
don't think it's written anywhere that everything must to start with  
"should"?

"the same user to rate the same agent twice" could become "duplicate  
ratings"

So maybe:
Agent disallows duplicate ratings of the same transaction type

Again I'm just taking a wild shot in the dark about your business  
logic from that description.  I don't mention "user" or "agent" in  
mine.  But we're already describing Agent, and can anything but a  
User rate an agent?  If only a User can, do you even need to specify  
that it's a User who is doing the rating?

I do find exercises like this where you have to try and describe your  
problem domain succinctly helps to understand it, and to be able to  
talk to another developer or your customer intelligently about it.

Don

On Jul 5, 2007, at 3:06 PM, s.ross wrote:

>
> On Jul 5, 2007, at 12:52 PM, David Chelimsky wrote:
>
>>> Agent "should not allow the same user to rate the same agent twice
>>> with the same kind of transaction"
>>>
>>> Thoughts?
>>
>> How would you phrase all this with context/specify? Or, a bit further
>> off target, TestCase/test_method?
>>
>
> I wouldn't phrase it differently with context/specify and with
> TestCase/test_method, I'd probably care less because I wouldn't have
> been trained to create beautiful, self-documenting example
> descriptions :)
>
> I'm just thinking there must be a nicer way to express what I mean.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From crafterm at gmail.com  Fri Jul  6 02:11:30 2007
From: crafterm at gmail.com (Marcus Crafter)
Date: Fri, 6 Jul 2007 16:11:30 +1000
Subject: [rspec-users] Edge, link_to and mocks
Message-ID: <B1DA821A-849F-4259-8FC4-0A716C0D2DC4@gmail.com>

Hi All,

Anyone noticed that using the newer link_to syntax in edge currently  
fails with mocked objects in view specs or helpers.

eg. if you have something like the following in your view (or  
equivalent in a helper):

	<%= link_to @dog.name, @dog %>

as opposed to the current 1.2 syntax:

	<%= link_to @dog.name, dog_path(@dog) %>

Using a mock_model as the 'dog' will raise a:

	undefined method `polymorphic_path' for [Dynamically generated class  
for RSpec example]:#<Class:0x26814f4>

error - I presume due to the introspection on the @dog object to find  
out what kind of class it is to create it's URL.

Anyone worked around this at all, other than using the older syntax?  
Any ideas appreciated.

Cheers,

Marcus

From dchelimsky at gmail.com  Fri Jul  6 03:00:28 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 6 Jul 2007 02:00:28 -0500
Subject: [rspec-users] Edge, link_to and mocks
In-Reply-To: <B1DA821A-849F-4259-8FC4-0A716C0D2DC4@gmail.com>
References: <B1DA821A-849F-4259-8FC4-0A716C0D2DC4@gmail.com>
Message-ID: <57c63afe0707060000i5b5fef29l5e017e22c4db3739@mail.gmail.com>

On 7/6/07, Marcus Crafter <crafterm at gmail.com> wrote:
> Hi All,
>
> Anyone noticed that using the newer link_to syntax in edge currently
> fails with mocked objects in view specs or helpers.
>
> eg. if you have something like the following in your view (or
> equivalent in a helper):
>
>         <%= link_to @dog.name, @dog %>
>
> as opposed to the current 1.2 syntax:
>
>         <%= link_to @dog.name, dog_path(@dog) %>
>
> Using a mock_model as the 'dog' will raise a:
>
>         undefined method `polymorphic_path' for [Dynamically generated class
> for RSpec example]:#<Class:0x26814f4>
>
> error - I presume due to the introspection on the @dog object to find
> out what kind of class it is to create it's URL.
>
> Anyone worked around this at all, other than using the older syntax?
> Any ideas appreciated.

All mock_model does is that it wraps mock, adding some method stubs.
So you can do this:

thing = mock_model(Thing)
thing.polymorphic_path = 'whatever'
...

Also - please report this sort of thing to rspec's tracker:

http://rubyforge.org/tracker/?group_id=797

>
> Cheers,
>
> Marcus
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Fri Jul  6 03:07:40 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 6 Jul 2007 02:07:40 -0500
Subject: [rspec-users] Testing Rails Associations
In-Reply-To: <2fff50390707032138y9ba5542pd92087d78ae33712@mail.gmail.com>
References: <2fff50390707032138y9ba5542pd92087d78ae33712@mail.gmail.com>
Message-ID: <57c63afe0707060007n467399d7r7987fa92a849f953@mail.gmail.com>

On 7/3/07, Daniel N <has.sox at gmail.com> wrote:
> Hi,
>
>  I'm very new to rspec, so if this is not the right forum please let me
> know.
>
>  I'm starting to spec my models first in an existing rails app, porting from
> a mix of Test::Unit, and simply_bdd amongst others.
>
>  I'm at the point where I want to test that certain associations are
> present.  What I'm not sure of is should I test the association or the
> method and return object.
>
>  That is, if I wanted to test a has_many should I:
>
>  Confirm the methods exist, and that the return an array etc
>
>  OR
>
>  Check that the model has the named has_many association through it's
> reflections.
>
>  On one hand the second one looks like it will be a bit more robust, since
> if there is a has_many relationship, then all the associated methods may be
> used througout the app.  This would put testing in the one place.
>
>  On the other hand, this would be really testing the implementation of the
> model rather than it's behaviour.   The behaviour is to call
> @article.comments and have an array of comments returned.
>
>  Any thoughts?

I think the jury is still out on this one. Both approaches present
problems, and no better approaches have been proposed. I'd say try it
both ways and report back on experiences.

David

>  Cheers
>  Daniel
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Fri Jul  6 03:11:14 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 6 Jul 2007 02:11:14 -0500
Subject: [rspec-users] mocking methods in the controller.
In-Reply-To: <2fff50390707050628i55391c60v75ea4b1b12e1311c@mail.gmail.com>
References: <2fff50390707050628i55391c60v75ea4b1b12e1311c@mail.gmail.com>
Message-ID: <57c63afe0707060011w1c5d35e9l293e075dab359bd7@mail.gmail.com>

On 7/5/07, Daniel N <has.sox at gmail.com> wrote:
> Hi,
>
> I'm very new to rspec so please be patient with me.
>
> I've tried to take some of my tests out of the controller specs to check for
> things that are rendered.
>
> This has not worked so well, since my views have the controller method
>
> current_user
>
> in quite a few places.
>
> Is there any way that I can define this so that my views will be executed?
> Will this same thing occur for all helper methods that are definied in the
> controller?

If I understand you correctly, you are trying to take tests for views
that were previously rails functional tests and turn them into rspec
view examples. If that is the case, you should be able to do this:

template.stub!(:current_user).and_return(mock_model(User))

If not, please provide an explicit example so we can better understand
what you're talking about.

Cheers,
David

>
> Cheers
> Daniel
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From has.sox at gmail.com  Fri Jul  6 03:35:13 2007
From: has.sox at gmail.com (Daniel N)
Date: Fri, 6 Jul 2007 17:35:13 +1000
Subject: [rspec-users] mocking methods in the controller.
In-Reply-To: <57c63afe0707060011w1c5d35e9l293e075dab359bd7@mail.gmail.com>
References: <2fff50390707050628i55391c60v75ea4b1b12e1311c@mail.gmail.com>
	<57c63afe0707060011w1c5d35e9l293e075dab359bd7@mail.gmail.com>
Message-ID: <2fff50390707060035nb036c50qe4440feb836f5076@mail.gmail.com>

On 7/6/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 7/5/07, Daniel N <has.sox at gmail.com> wrote:
> > Hi,
> >
> > I'm very new to rspec so please be patient with me.
> >
> > I've tried to take some of my tests out of the controller specs to check
> for
> > things that are rendered.
> >
> > This has not worked so well, since my views have the controller method
> >
> > current_user
> >
> > in quite a few places.
> >
> > Is there any way that I can define this so that my views will be
> executed?
> > Will this same thing occur for all helper methods that are definied in
> the
> > controller?
>
> If I understand you correctly, you are trying to take tests for views
> that were previously rails functional tests and turn them into rspec
> view examples. If that is the case, you should be able to do this:
>
> template.stub!(:current_user).and_return(mock_model(User))
>
> If not, please provide an explicit example so we can better understand
> what you're talking about.
>
> Cheers,
> David



Thanx David,

That looks like what I was looking for.

I will try it when I get home.

Cheers
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070706/d0825410/attachment.html 

From has.sox at gmail.com  Fri Jul  6 03:49:52 2007
From: has.sox at gmail.com (Daniel N)
Date: Fri, 6 Jul 2007 17:49:52 +1000
Subject: [rspec-users] Testing Rails Associations
In-Reply-To: <57c63afe0707060007n467399d7r7987fa92a849f953@mail.gmail.com>
References: <2fff50390707032138y9ba5542pd92087d78ae33712@mail.gmail.com>
	<57c63afe0707060007n467399d7r7987fa92a849f953@mail.gmail.com>
Message-ID: <2fff50390707060049l17ecd756h7d8874c7989f0999@mail.gmail.com>

On 7/6/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 7/3/07, Daniel N <has.sox at gmail.com> wrote:
> > Hi,
> >
> >  I'm very new to rspec, so if this is not the right forum please let me
> > know.
> >
> >  I'm starting to spec my models first in an existing rails app, porting
> from
> > a mix of Test::Unit, and simply_bdd amongst others.
> >
> >  I'm at the point where I want to test that certain associations are
> > present.  What I'm not sure of is should I test the association or the
> > method and return object.
> >
> >  That is, if I wanted to test a has_many should I:
> >
> >  Confirm the methods exist, and that the return an array etc
> >
> >  OR
> >
> >  Check that the model has the named has_many association through it's
> > reflections.
> >
> >  On one hand the second one looks like it will be a bit more robust,
> since
> > if there is a has_many relationship, then all the associated methods may
> be
> > used througout the app.  This would put testing in the one place.
> >
> >  On the other hand, this would be really testing the implementation of
> the
> > model rather than it's behaviour.   The behaviour is to call
> > @article.comments and have an array of comments returned.
> >
> >  Any thoughts?
>
> I think the jury is still out on this one. Both approaches present
> problems, and no better approaches have been proposed. I'd say try it
> both ways and report back on experiences.
>
> David
>
> >  Cheers
> >  Daniel
> >


I went with the second way, testing the association through reflections.
The reason I did this is that by testing that there is a has_* or belongs_to
you are really testing the availablity of all the assoicated methods.  Which
you are then free to use throughout your app.

If you go the other way, you are not in fact testing if a model "has_many"
since this implies that all has_many methods will be included, not just
returning and setting an Array.

If your interested I've put up the module that I am using to provide these
and a couple of other methods on pastie.  This is my first go so please
don't expect anything spectacular.

http://pastie.caboo.se/76462

Cheers
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070706/0cef0276/attachment.html 

From has.sox at gmail.com  Fri Jul  6 04:40:52 2007
From: has.sox at gmail.com (Daniel N)
Date: Fri, 6 Jul 2007 18:40:52 +1000
Subject: [rspec-users] Testing Rails Associations
In-Reply-To: <2fff50390707060049l17ecd756h7d8874c7989f0999@mail.gmail.com>
References: <2fff50390707032138y9ba5542pd92087d78ae33712@mail.gmail.com>
	<57c63afe0707060007n467399d7r7987fa92a849f953@mail.gmail.com>
	<2fff50390707060049l17ecd756h7d8874c7989f0999@mail.gmail.com>
Message-ID: <2fff50390707060140p59c91492sb8667c81704d794c@mail.gmail.com>

On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
>
>
>
> On 7/6/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 7/3/07, Daniel N <has.sox at gmail.com> wrote:
> > > Hi,
> > >
> > >  I'm very new to rspec, so if this is not the right forum please let me
> > > know.
> > >
> > >  I'm starting to spec my models first in an existing rails app, porting
> from
> > > a mix of Test::Unit, and simply_bdd amongst others.
> > >
> > >  I'm at the point where I want to test that certain associations are
> > > present.  What I'm not sure of is should I test the association or the
> > > method and return object.
> > >
> > >  That is, if I wanted to test a has_many should I:
> > >
> > >  Confirm the methods exist, and that the return an array etc
> > >
> > >  OR
> > >
> > >  Check that the model has the named has_many association through it's
> > > reflections.
> > >
> > >  On one hand the second one looks like it will be a bit more robust,
> since
> > > if there is a has_many relationship, then all the associated methods may
> be
> > > used througout the app.  This would put testing in the one place.
> > >
> > >  On the other hand, this would be really testing the implementation of
> the
> > > model rather than it's behaviour.   The behaviour is to call
> > > @article.comments and have an array of comments returned.
> > >
> > >  Any thoughts?
> >
> > I think the jury is still out on this one. Both approaches present
> > problems, and no better approaches have been proposed. I'd say try it
> > both ways and report back on experiences.
> >
> > David
> >
> > >  Cheers
> > >  Daniel
> > >
>
> I went with the second way, testing the association through reflections.
> The reason I did this is that by testing that there is a has_* or belongs_to
> you are really testing the availablity of all the assoicated methods.  Which
> you are then free to use throughout your app.
>
> If you go the other way, you are not in fact testing if a model "has_many"
> since this implies that all has_many methods will be included, not just
> returning and setting an Array.
>
> If your interested I've put up the module that I am using to provide these
> and a couple of other methods on pastie.  This is my first go so please
> don't expect anything spectacular.
>
> http://pastie.caboo.se/76462
>
> Cheers
> Daniel
>

Wow I should really have checked that more thoroughly.  I found many
mistakes in that.

Here is one I've fixed up.

http://pastie.caboo.se/76470

Daniel

From has.sox at gmail.com  Fri Jul  6 08:42:29 2007
From: has.sox at gmail.com (Daniel N)
Date: Fri, 6 Jul 2007 22:42:29 +1000
Subject: [rspec-users] mocking methods in the controller.
In-Reply-To: <2fff50390707060035nb036c50qe4440feb836f5076@mail.gmail.com>
References: <2fff50390707050628i55391c60v75ea4b1b12e1311c@mail.gmail.com>
	<57c63afe0707060011w1c5d35e9l293e075dab359bd7@mail.gmail.com>
	<2fff50390707060035nb036c50qe4440feb836f5076@mail.gmail.com>
Message-ID: <2fff50390707060542x3c8e721ag619bfc8b375e9181@mail.gmail.com>

On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
>
>
>
> On 7/6/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> >
> > On 7/5/07, Daniel N <has.sox at gmail.com> wrote:
> > > Hi,
> > >
> > > I'm very new to rspec so please be patient with me.
> > >
> > > I've tried to take some of my tests out of the controller specs to
> > check for
> > > things that are rendered.
> > >
> > > This has not worked so well, since my views have the controller method
> > >
> > > current_user
> > >
> > > in quite a few places.
> > >
> > > Is there any way that I can define this so that my views will be
> > executed?
> > > Will this same thing occur for all helper methods that are definied in
> > the
> > > controller?
> >
> > If I understand you correctly, you are trying to take tests for views
> > that were previously rails functional tests and turn them into rspec
> > view examples. If that is the case, you should be able to do this:
> >
> > template.stub!(:current_user).and_return(mock_model(User))
> >
> > If not, please provide an explicit example so we can better understand
> > what you're talking about.
> >
> > Cheers,
> > David
>
>
>
> Thanx David,
>
> That looks like what I was looking for.
>
> I will try it when I get home.
>
> Cheers
> Daniel
>

Ok I've started to have a crack at this but it's getting way out of hand.
Everytime I stub a method there's another one to do.

I've also found that when there's a partial _detail and I've passed the
:collection => @things to it it blows up complaining that the local variable
is nil in
dom_id( detail )

Am I doing someting wrong?  The start of my specs is

  before do
    @u = mock_model( User )
    @book = mock_model( Book )

    public_book = mock_model( Book )
    private_book = mock_model( Book )
    public_book.stub!(:title=).and_return( "Public Title" )
    private_book.stub!(:title=).and_return( "Private Title" )
    public_book.stub!( :title ).and_return( "Public Title" )
    private_book.stub!( :title ).and_return( "Private Title" )

    @u.stub!( :public_books ).and_return( [public_book] )
    @u.stub!( :private_books ).and_return( [private_book] )
    @clip = mock_model( Clip )
    @clip.stub!( :id ).and_return( 1 )
    @clips = [ @clip ]

    template.stub!( :current_user ).and_return( @u )
  end

and I've only started.  Is it normal to have to stub this much for a view?

Cheers
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070706/c135d879/attachment.html 

From dchelimsky at gmail.com  Fri Jul  6 08:59:28 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 6 Jul 2007 07:59:28 -0500
Subject: [rspec-users] mocking methods in the controller.
In-Reply-To: <2fff50390707060542x3c8e721ag619bfc8b375e9181@mail.gmail.com>
References: <2fff50390707050628i55391c60v75ea4b1b12e1311c@mail.gmail.com>
	<57c63afe0707060011w1c5d35e9l293e075dab359bd7@mail.gmail.com>
	<2fff50390707060035nb036c50qe4440feb836f5076@mail.gmail.com>
	<2fff50390707060542x3c8e721ag619bfc8b375e9181@mail.gmail.com>
Message-ID: <57c63afe0707060559l58fd8826k91afd8b2d696e0d3@mail.gmail.com>

On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
> On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
> > On 7/6/07, David Chelimsky < dchelimsky at gmail.com> wrote:
> > > On 7/5/07, Daniel N <has.sox at gmail.com> wrote:
> > > > Hi,
> > > >
> > > > I'm very new to rspec so please be patient with me.
> > > >
> > > > I've tried to take some of my tests out of the controller specs to
> check for
> > > > things that are rendered.
> > > >
> > > > This has not worked so well, since my views have the controller method
> > > >
> > > > current_user
> > > >
> > > > in quite a few places.
> > > >
> > > > Is there any way that I can define this so that my views will be
> executed?
> > > > Will this same thing occur for all helper methods that are definied in
> the
> > > > controller?
> > >
> > > If I understand you correctly, you are trying to take tests for views
> > > that were previously rails functional tests and turn them into rspec
> > > view examples. If that is the case, you should be able to do this:
> > >
> > >
> template.stub!(:current_user).and_return(mock_model(User))
> > >
> > > If not, please provide an explicit example so we can better understand
> > > what you're talking about.
> > >
> > > Cheers,
> > > David
> >
> >
> >
> > Thanx David,
> >
> > That looks like what I was looking for.
> >
> > I will try it when I get home.
> >
> > Cheers
> > Daniel
>
> Ok I've started to have a crack at this but it's getting way out of hand.
> Everytime I stub a method there's another one to do.
>
> I've also found that when there's a partial _detail and I've passed the
> :collection => @things to it it blows up complaining that the local variable
> is nil in
> dom_id( detail )

If you're using the trunk, you can do this:

template.expects_render(:partial => 'detail', :collection => @things)

>
> Am I doing someting wrong?  The start of my specs is
>
>   before do
>     @u = mock_model( User )
>     @book = mock_model( Book )
>
>     public_book = mock_model( Book )
>     private_book = mock_model( Book )
>     public_book.stub!(:title=).and_return( "Public Title" )
>     private_book.stub!(:title=).and_return( "Private Title"
> )
>     public_book.stub!( :title ).and_return( "Public Title" )
>     private_book.stub!( :title ).and_return( "Private Title" )

Why are you stubbing the same calls twice each?

>
>     @u.stub!( :public_books ).and_return( [public_book] )
>     @u.stub!( :private_books ).and_return( [private_book] )
>     @clip = mock_model( Clip )
>     @clip.stub!( :id ).and_return( 1 )
>     @clips = [ @clip ]
>
>     template.stub!( :current_user ).and_return( @u )
>   end
>
> and I've only started.  Is it normal to have to stub this much for a view?

Depends on how much stuff is in your view :)

You've got a couple of options. You could create instances of the
model instead. As long as you're not saving and retrieving them
there's very little db interaction - just enough for AR to discover
the attributes.

If you prefer to keep it all mocked/stubbed, you could clean up a bit like this:

before do
  @u = mock_model( User )
  @book = mock_model( Book )

  public_book = mock_model(Book, :title => 'Public Title')
  private_book = mock_model( Book, :title => 'Private Title')

  @u.stub!( :public_books ).and_return( [public_book] )
  @u.stub!( :private_books ).and_return( [private_book] )

  @clips = [ @clip = mock_model( Clip, :id => 1 ) ]

  template.stub!( :current_user ).and_return( @u )
end

That stubs the same amount of stuff, but its a little cleaner. You
could also write a shared behaviour that stubs current user:

describe "authenticated page view", :shared => true do
  before(:each) do
    template.stub!( :current_user ).and_return( @u )
  end
end

describe "/some/page"
  it_should_behave_like "authenticated page view"

  before(:each) do
    @u = mock_model( User )
    @book = mock_model( Book )

    public_book = mock_model(Book, :title => 'Public Title')
    private_book = mock_model( Book, :title => 'Private Title')

    @u.stub!( :public_books ).and_return( [public_book] )
    @u.stub!( :private_books ).and_return( [private_book] )

    @clips = [ @clip = mock_model( Clip, :id => 1 ) ]

  end
end

There's probably a bit more to clean up but I'd have to see the view
code. Would you mind letting us see it?

>
> Cheers
> Daniel
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From has.sox at gmail.com  Fri Jul  6 10:27:16 2007
From: has.sox at gmail.com (Daniel N)
Date: Sat, 7 Jul 2007 00:27:16 +1000
Subject: [rspec-users] mocking methods in the controller.
In-Reply-To: <57c63afe0707060559l58fd8826k91afd8b2d696e0d3@mail.gmail.com>
References: <2fff50390707050628i55391c60v75ea4b1b12e1311c@mail.gmail.com>
	<57c63afe0707060011w1c5d35e9l293e075dab359bd7@mail.gmail.com>
	<2fff50390707060035nb036c50qe4440feb836f5076@mail.gmail.com>
	<2fff50390707060542x3c8e721ag619bfc8b375e9181@mail.gmail.com>
	<57c63afe0707060559l58fd8826k91afd8b2d696e0d3@mail.gmail.com>
Message-ID: <2fff50390707060727m1ac54674m1ed9aea4869d96c5@mail.gmail.com>

On 7/6/07, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
> > On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
> > > On 7/6/07, David Chelimsky < dchelimsky at gmail.com> wrote:
> > > > On 7/5/07, Daniel N <has.sox at gmail.com> wrote:
> > > > > Hi,
> > > > >
> > > > > I'm very new to rspec so please be patient with me.
> > > > >
> > > > > I've tried to take some of my tests out of the controller specs to
> > check for
> > > > > things that are rendered.
> > > > >
> > > > > This has not worked so well, since my views have the controller
> method
> > > > >
> > > > > current_user
> > > > >
> > > > > in quite a few places.
> > > > >
> > > > > Is there any way that I can define this so that my views will be
> > executed?
> > > > > Will this same thing occur for all helper methods that are
> definied in
> > the
> > > > > controller?
> > > >
> > > > If I understand you correctly, you are trying to take tests for
> views
> > > > that were previously rails functional tests and turn them into rspec
> > > > view examples. If that is the case, you should be able to do this:
> > > >
> > > >
> > template.stub!(:current_user).and_return(mock_model(User))
> > > >
> > > > If not, please provide an explicit example so we can better
> understand
> > > > what you're talking about.
> > > >
> > > > Cheers,
> > > > David
> > >
> > >
> > >
> > > Thanx David,
> > >
> > > That looks like what I was looking for.
> > >
> > > I will try it when I get home.
> > >
> > > Cheers
> > > Daniel
> >
> > Ok I've started to have a crack at this but it's getting way out of
> hand.
> > Everytime I stub a method there's another one to do.
> >
> > I've also found that when there's a partial _detail and I've passed the
> > :collection => @things to it it blows up complaining that the local
> variable
> > is nil in
> > dom_id( detail )
>
> If you're using the trunk, you can do this:
>
> template.expects_render(:partial => 'detail', :collection => @things)
>
> >
> > Am I doing someting wrong?  The start of my specs is
> >
> >   before do
> >     @u = mock_model( User )
> >     @book = mock_model( Book )
> >
> >     public_book = mock_model( Book )
> >     private_book = mock_model( Book )
> >     public_book.stub!(:title=).and_return( "Public Title" )
> >     private_book.stub!(:title=).and_return( "Private Title"
> > )
> >     public_book.stub!( :title ).and_return( "Public Title" )
> >     private_book.stub!( :title ).and_return( "Private Title" )
>
> Why are you stubbing the same calls twice each?
>
> >
> >     @u.stub!( :public_books ).and_return( [public_book] )
> >     @u.stub!( :private_books ).and_return( [private_book] )
> >     @clip = mock_model( Clip )
> >     @clip.stub!( :id ).and_return( 1 )
> >     @clips = [ @clip ]
> >
> >     template.stub!( :current_user ).and_return( @u )
> >   end
> >
> > and I've only started.  Is it normal to have to stub this much for a
> view?
>
> Depends on how much stuff is in your view :)
>
> You've got a couple of options. You could create instances of the
> model instead. As long as you're not saving and retrieving them
> there's very little db interaction - just enough for AR to discover
> the attributes.
>
> If you prefer to keep it all mocked/stubbed, you could clean up a bit like
> this:
>
> before do
>   @u = mock_model( User )
>   @book = mock_model( Book )
>
>   public_book = mock_model(Book, :title => 'Public Title')
>   private_book = mock_model( Book, :title => 'Private Title')
>
>   @u.stub!( :public_books ).and_return( [public_book] )
>   @u.stub!( :private_books ).and_return( [private_book] )
>
>   @clips = [ @clip = mock_model( Clip, :id => 1 ) ]
>
>   template.stub!( :current_user ).and_return( @u )
> end
>
> That stubs the same amount of stuff, but its a little cleaner. You
> could also write a shared behaviour that stubs current user:
>
> describe "authenticated page view", :shared => true do
>   before(:each) do
>     template.stub!( :current_user ).and_return( @u )
>   end
> end
>
> describe "/some/page"
>   it_should_behave_like "authenticated page view"
>
>   before(:each) do
>     @u = mock_model( User )
>     @book = mock_model( Book )
>
>     public_book = mock_model(Book, :title => 'Public Title')
>     private_book = mock_model( Book, :title => 'Private Title')
>
>     @u.stub!( :public_books ).and_return( [public_book] )
>     @u.stub!( :private_books ).and_return( [private_book] )
>
>     @clips = [ @clip = mock_model( Clip, :id => 1 ) ]
>
>   end
> end
>
> There's probably a bit more to clean up but I'd have to see the view
> code. Would you mind letting us see it?
>
> >
> > Cheers
> > Daniel



index.html.erb

<% content_for :action_bar do %>
  <% @public_books = current_user.public_books %>
    <% @private_books = current_user.private_books %>
  <%= render :file => 'books/_book_list.html.erb' -%>
<% end %>

<% if @book %>
  <div class='book_clip_list' id='<%= dom_id( @book )-%>'>
      <h2 class='book_header'><%= @book.title -%></h2>
        <ul id="book_clip_menu">
            <li>
                <button class='collapse_all'>Collapse All</button>
                <button class='expand_all'>Expand All</button>
            </li>
        </ul>
        <%= render :partial => 'detail', :collection => @clips %>
    </div>
<% else %>
  <%= render :partial => 'detail', :collection => @clips -%>

<% end %>


detail.html.erb
<div id='<%= dom_id( detail ) -%>' class='clip_container'>
    <div class='clip_header'>
        <button class='minimize'>-</button>
        <h3 id='<%= "#{dom_id( detail )}_header" -%>'><%= detail.title-%></h3>
        <div>
            <a href='<%= detail.url -%>' target='_blank'><%= URI.parse(
detail.url).host -%></a><br/>
            <%= detail.created_at.to_s( :long ) -%>
        </div>
    </div>
    <div class='content_container' id='<%= "#{dom_id( detail
)}_content_container" -%>'>
    <div class='clip_menu'>
        <ul class='action_menu'>
            <%= render :partial => 'action_menu_links', :locals => { :clip
=> detail, :book => @book } -%>
        </ul>
        <ul class='view_menu'>
        <%= render :partial => 'alternative_content_links', :locals => {
:clip => detail } -%>
        </ul>
    </div>
    <blockquote id='<%= "#{dom_id( detail )}_blockquote"-%>'>
    <% render_as = @view_type || 'html' %>
    <% render_as = 'html' unless Clip.available_types.include?( render_as )
%>
        <% case render_as %>
        <% when 'quote' %>
            <%= render :partial => 'text',     :locals => { :clip => detail
} %>
        <% when 'images' %>
          <%= render :partial => 'images',     :locals => { :clip => detail
} %>
        <% when 'html' %>
            <%= render :partial => 'html',        :locals => { :clip =>
detail } %>
        <% end %>

    </blockquote>
    </div>
</div>


The _text, _images, _html partials are very simple so I won't show them
here.  This will be enough I think to evaluate it.

Thankyou for helping with this.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070707/7a172439/attachment.html 

From jed.hurt at gmail.com  Fri Jul  6 11:45:39 2007
From: jed.hurt at gmail.com (Jed Hurt)
Date: Fri, 6 Jul 2007 09:45:39 -0600
Subject: [rspec-users] Outside-In with RSpec on Rails
Message-ID: <dbc32d450707060845q4e93d4e4ie0d25b4f4385c414@mail.gmail.com>

I just read 'Mocks Aren't Stubs' and was intrigued by the notion of
'outside-in' TDD.

As a Rails developer, I'm curious if others are employing this method
when developing Rails applications using RSpec. Is it common practice
(or even practical) to drive the development of a Rails app by
starting with view specs, then controller specs, then models?

From dchelimsky at gmail.com  Fri Jul  6 11:55:09 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 6 Jul 2007 10:55:09 -0500
Subject: [rspec-users] Outside-In with RSpec on Rails
In-Reply-To: <dbc32d450707060845q4e93d4e4ie0d25b4f4385c414@mail.gmail.com>
References: <dbc32d450707060845q4e93d4e4ie0d25b4f4385c414@mail.gmail.com>
Message-ID: <57c63afe0707060855k501bf8a0l8a1eed29f76a95ee@mail.gmail.com>

On 7/6/07, Jed Hurt <jed.hurt at gmail.com> wrote:
> I just read 'Mocks Aren't Stubs' and was intrigued by the notion of
> 'outside-in' TDD.
>
> As a Rails developer, I'm curious if others are employing this method
> when developing Rails applications using RSpec. Is it common practice
> (or even practical) to drive the development of a Rails app by
> starting with view specs, then controller specs, then models?

Common? Not from what I've seen. I think that most ppl seem to start
w/ the controller.

That said, I've been starting with the views with some success. I find
that when I've started with the controller, I've ended up doing a lot
more refactoring once that slice was done (i.e. a given
view/controller action/model trio) than I do when I start w/ the view.
In other words, the designs that emerge when I start w/ views are
closer to the designs that I want.

This is just me. I'm not advocating that this will work for everybody.

David


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

From jcfischer.lists at gmail.com  Fri Jul  6 12:07:42 2007
From: jcfischer.lists at gmail.com (Jens-Christian Fischer)
Date: Fri, 6 Jul 2007 18:07:42 +0200
Subject: [rspec-users] stubbing helper methods for View specs
Message-ID: <64BFD93F-71D6-47E0-A4C0-22DEBDB6C6DD@gmail.com>

Hi there

I have several view specs, that include the following snippet in  
their "before" block to stub the methods by acts_as_authenticated

   before :each do
     @u = mock_model(User)
     @u.should_receive(:name).and_return("Hans Muster")
     template.should_receive(:logged_in?).and_return(true)
     template.should_receive(:current_user).and_return(@u)
   end

this works for views / helpers like this:

   it "should show bla" do
     render "/layouts/thetool"
     response.should have_tag("p", "bla")
   end

and the view (haml to make things more interesting)

   - if logged_in?
     %p bla


Now I also use Ezra acl_system2 plugin which defines a "restrict_to"  
method that queries some roles. When I stub the methods above and run  
specs, I get the following error:

ActionView::TemplateError in '/users/show should display the  
information of the user'
undefined local variable or method `current_user' for  
#<Spec::Rails::DSL::ViewExampleController:0x35d5cc0>
On line #59 of app/views/users/show.haml

     56:       - @user.roles.each do |role|
     57:         = role.title
     58:
     59: - restrict_to "admin | projektleiter" do
     60:   = link_to "Bearbeiten", edit_user_url(@user)
     app/views//users/show.haml:59
     vendor/plugins/acl_system2/lib/caboose/access_control.rb:75:in  
`restrict_to'
     (eval):2:in `restrict_to'
     (eval):164:in `_render_haml_1'
     vendor/plugins/haml/lib/haml/engine.rb:435:in `compile'
     vendor/plugins/haml/lib/haml/engine.rb:186:in `to_html'
     vendor/plugins/haml/lib/haml/template.rb:69:in `render'
     vendor/rails/actionpack/lib/action_view/base.rb:502:in  
`delegate_render'
     vendor/rails/actionpack/lib/action_view/base.rb:324:in  
`render_template_old'
     vendor/plugins/haml/lib/haml/template.rb:96:in `render_template'
     vendor/rails/actionpack/lib/action_view/base.rb:286:in  
`globalize_old_render_file'
     vendor/plugins/trunk/lib/globalize/rails/action_view.rb:20:in  
`render_file'
     vendor/rails/actionpack/lib/action_controller/base.rb:879:in  
`render_file'
     vendor/rails/actionpack/lib/action_controller/base.rb:814:in  
`render_with_no_layout'
     vendor/rails/actionpack/lib/action_controller/layout.rb:258:in  
`render_without_benchmark'
     vendor/rails/actionpack/lib/action_controller/benchmarking.rb: 
51:in `render'
     /usr/local/lib/ruby/site_ruby/1.8/benchmark.rb:300:in `measure'
     vendor/rails/actionpack/lib/action_controller/benchmarking.rb: 
51:in `render'
     vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/ 
view.rb:51:in `render'
     spec/views/users/show_haml_spec.rb:23
     ...



Interestingly, when I misspell the name of the stub in the working  
example, I get the following error:

1)
ActionView::TemplateError in '/shared/layout_test not logged in  
should have the correct head information'
undefined method `logged_in?' for #<ActionView::Base:0x22ec6f8>
On line #13 of app/views/layouts/thetool.haml

app/views//layouts/thetool.haml:13
     app/helpers/application_helper.rb:5:in `login_logout'
     (eval):28:in `_render_haml_1'
     vendor/plugins/haml/lib/haml/engine.rb:435:in `compile'
     vendor/plugins/haml/lib/haml/engine.rb:186:in `to_html'
     vendor/plugins/haml/lib/haml/template.rb:69:in `render'
     vendor/rails/actionpack/lib/action_view/base.rb:502:in  
`delegate_render'
     vendor/rails/actionpack/lib/action_view/base.rb:324:in  
`render_template_old'
     vendor/plugins/haml/lib/haml/template.rb:96:in `render_template'
     vendor/rails/actionpack/lib/action_view/base.rb:286:in  
`globalize_old_render_file'
     vendor/plugins/trunk/lib/globalize/rails/action_view.rb:20:in  
`render_file'
     vendor/rails/actionpack/lib/action_controller/base.rb:879:in  
`render_file'
     vendor/rails/actionpack/lib/action_controller/base.rb:814:in  
`render_with_no_layout'
     vendor/rails/actionpack/lib/action_controller/layout.rb:258:in  
`render_without_benchmark'
     vendor/rails/actionpack/lib/action_controller/benchmarking.rb: 
51:in `render'
     /usr/local/lib/ruby/site_ruby/1.8/benchmark.rb:300:in `measure'
     vendor/rails/actionpack/lib/action_controller/benchmarking.rb: 
51:in `render'
     vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/ 
view.rb:51:in `render'
     spec/views/layouts/thetool_haml_spec.rb:16


Note the different class (#<ActionView::Base:0x22ec6f8> vs  
#<Spec::Rails::DSL::ViewExampleController:0x35d5cc0>) in the two specs.

I don't have enough rspec_fu to deduce where the problem lies..


Any helpers?

thanks
Jens-Christian




From jed.hurt at gmail.com  Fri Jul  6 12:13:49 2007
From: jed.hurt at gmail.com (Jed Hurt)
Date: Fri, 6 Jul 2007 10:13:49 -0600
Subject: [rspec-users] Outside-In with RSpec on Rails
In-Reply-To: <57c63afe0707060855k501bf8a0l8a1eed29f76a95ee@mail.gmail.com>
References: <dbc32d450707060845q4e93d4e4ie0d25b4f4385c414@mail.gmail.com>
	<57c63afe0707060855k501bf8a0l8a1eed29f76a95ee@mail.gmail.com>
Message-ID: <dbc32d450707060913n82829cq9f07302f4001fd6c@mail.gmail.com>

Cool. I'll have to give it a try on my next project.

On 7/6/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 7/6/07, Jed Hurt <jed.hurt at gmail.com> wrote:
> > I just read 'Mocks Aren't Stubs' and was intrigued by the notion of
> > 'outside-in' TDD.
> >
> > As a Rails developer, I'm curious if others are employing this method
> > when developing Rails applications using RSpec. Is it common practice
> > (or even practical) to drive the development of a Rails app by
> > starting with view specs, then controller specs, then models?
>
> Common? Not from what I've seen. I think that most ppl seem to start
> w/ the controller.
>
> That said, I've been starting with the views with some success. I find
> that when I've started with the controller, I've ended up doing a lot
> more refactoring once that slice was done (i.e. a given
> view/controller action/model trio) than I do when I start w/ the view.
> In other words, the designs that emerge when I start w/ views are
> closer to the designs that I want.
>
> This is just me. I'm not advocating that this will work for everybody.
>
> David
>
>
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Fri Jul  6 12:17:10 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 6 Jul 2007 11:17:10 -0500
Subject: [rspec-users] mocking methods in the controller.
In-Reply-To: <2fff50390707060727m1ac54674m1ed9aea4869d96c5@mail.gmail.com>
References: <2fff50390707050628i55391c60v75ea4b1b12e1311c@mail.gmail.com>
	<57c63afe0707060011w1c5d35e9l293e075dab359bd7@mail.gmail.com>
	<2fff50390707060035nb036c50qe4440feb836f5076@mail.gmail.com>
	<2fff50390707060542x3c8e721ag619bfc8b375e9181@mail.gmail.com>
	<57c63afe0707060559l58fd8826k91afd8b2d696e0d3@mail.gmail.com>
	<2fff50390707060727m1ac54674m1ed9aea4869d96c5@mail.gmail.com>
Message-ID: <57c63afe0707060917k4cfc3096ya9314bfcb551839@mail.gmail.com>

On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
>
>
>
> On 7/6/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
> > > On 7/6/07, Daniel N <has.sox at gmail.com> wrote:
> > > > On 7/6/07, David Chelimsky < dchelimsky at gmail.com> wrote:
> > > > > On 7/5/07, Daniel N <has.sox at gmail.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I'm very new to rspec so please be patient with me.
> > > > > >
> > > > > > I've tried to take some of my tests out of the controller specs to
> > > check for
> > > > > > things that are rendered.
> > > > > >
> > > > > > This has not worked so well, since my views have the controller
> method
> > > > > >
> > > > > > current_user
> > > > > >
> > > > > > in quite a few places.
> > > > > >
> > > > > > Is there any way that I can define this so that my views will be
> > > executed?
> > > > > > Will this same thing occur for all helper methods that are
> definied in
> > > the
> > > > > > controller?
> > > > >
> > > > > If I understand you correctly, you are trying to take tests for
> views
> > > > > that were previously rails functional tests and turn them into rspec
> > > > > view examples. If that is the case, you should be able to do this:
> > > > >
> > > > >
> > >
> template.stub!(:current_user).and_return(mock_model(User))
> > > > >
> > > > > If not, please provide an explicit example so we can better
> understand
> > > > > what you're talking about.
> > > > >
> > > > > Cheers,
> > > > > David
> > > >
> > > >
> > > >
> > > > Thanx David,
> > > >
> > > > That looks like what I was looking for.
> > > >
> > > > I will try it when I get home.
> > > >
> > > > Cheers
> > > > Daniel
> > >
> > > Ok I've started to have a crack at this but it's getting way out of
> hand.
> > > Everytime I stub a method there's another one to do.
> > >
> > > I've also found that when there's a partial _detail and I've passed the
> > > :collection => @things to it it blows up complaining that the local
> variable
> > > is nil in
> > > dom_id( detail )
> >
> > If you're using the trunk, you can do this:
> >
> > template.expects_render(:partial => 'detail', :collection => @things)
> >
> > >
> > > Am I doing someting wrong?  The start of my specs is
> > >
> > >   before do
> > >     @u = mock_model( User )
> > >     @book = mock_model( Book )
> > >
> > >     public_book = mock_model( Book )
> > >     private_book = mock_model( Book )
> > >     public_book.stub!(:title=).and_return( "Public
> Title" )
> > >     private_book.stub!(:title=).and_return( "Private
> Title"
> > > )
> > >     public_book.stub!( :title ).and_return( "Public Title" )
> > >     private_book.stub!( :title ).and_return( "Private Title" )
> >
> > Why are you stubbing the same calls twice each?
> >
> > >
> > >     @u.stub!( :public_books ).and_return( [public_book] )
> > >     @u.stub!( :private_books ).and_return( [private_book] )
> > >     @clip = mock_model( Clip )
> > >     @clip.stub!( :id ).and_return( 1 )
> > >     @clips = [ @clip ]
> > >
> > >     template.stub!( :current_user ).and_return( @u )
> > >   end
> > >
> > > and I've only started.  Is it normal to have to stub this much for a
> view?
> >
> > Depends on how much stuff is in your view :)
> >
> > You've got a couple of options. You could create instances of the
> > model instead. As long as you're not saving and retrieving them
> > there's very little db interaction - just enough for AR to discover
> > the attributes.
> >
> > If you prefer to keep it all mocked/stubbed, you could clean up a bit like
> this:
> >
> > before do
> >   @u = mock_model( User )
> >   @book = mock_model( Book )
> >
> >   public_book = mock_model(Book, :title => 'Public Title')
> >   private_book = mock_model( Book, :title => 'Private Title')
> >
> >   @u.stub!( :public_books ).and_return( [public_book] )
> >   @u.stub!( :private_books ).and_return( [private_book] )
> >
> >   @clips = [ @clip = mock_model( Clip, :id => 1 ) ]
> >
> >   template.stub!( :current_user ).and_return( @u )
> > end
> >
> > That stubs the same amount of stuff, but its a little cleaner. You
> > could also write a shared behaviour that stubs current user:
> >
> > describe "authenticated page view", :shared => true do
> >   before(:each) do
> >     template.stub!( :current_user ).and_return( @u )
> >   end
> > end
> >
> > describe "/some/page"
> >   it_should_behave_like "authenticated page view"
> >
> >   before(:each) do
> >     @u = mock_model( User )
> >     @book = mock_model( Book )
> >
> >     public_book = mock_model(Book, :title => 'Public Title')
> >     private_book = mock_model( Book, :title => 'Private Title')
> >
> >     @u.stub!( :public_books ).and_return( [public_book] )
> >     @u.stub!( :private_books ).and_return( [private_book] )
> >
> >     @clips = [ @clip = mock_model( Clip, :id => 1 ) ]
> >
> >   end
> > end
> >
> > There's probably a bit more to clean up but I'd have to see the view
> > code. Would you mind letting us see it?
> >
> > >
> > > Cheers
> > > Daniel
>
>
> index.html.erb
>
> <% content_for :action_bar do %>
>   <% @public_books = current_user.public_books %>
>     <% @private_books = current_user.private_books %>
>   <%= render :file => 'books/_book_list.html.erb' -%>
> <% end %>
>
> <% if @book %>
>   <div class='book_clip_list' id='<%= dom_id( @book )-%>'>
>       <h2 class='book_header'><%= @book.title -%></h2>
>         <ul id="book_clip_menu">
>             <li>
>                 <button class='collapse_all'>Collapse All</button>
>                 <button class='expand_all'>Expand All</button>
>             </li>
>         </ul>
>         <%= render :partial => 'detail', :collection => @clips %>
>     </div>
> <% else %>
>   <%= render :partial => 'detail', :collection => @clips -%>
>
> <% end %>
>
>
> detail.html.erb
> <div id='<%= dom_id( detail ) -%>' class='clip_container'>
>     <div class='clip_header'>
>         <button class='minimize'>-</button>
>         <h3 id='<%= "#{dom_id( detail )}_header" -%>'><%= detail.title
> -%></h3>
>         <div>
>             <a href='<%= detail.url -%>' target='_blank'><%=
> URI.parse(detail.url).host -%></a><br/>
>             <%= detail.created_at.to_s ( :long ) -%>
>         </div>
>     </div>
>     <div class='content_container' id='<%= "#{dom_id( detail
> )}_content_container" -%>'>
>     <div class='clip_menu'>
>         <ul class='action_menu'>
>             <%= render :partial => 'action_menu_links', :locals => { :clip
> => detail, :book => @book } -%>
>         </ul>
>         <ul class='view_menu'>
>         <%= render :partial => 'alternative_content_links', :locals => {
> :clip => detail } -%>
>         </ul>
>     </div>
>     <blockquote id='<%= "#{dom_id( detail )}_blockquote"-%>'>
>     <% render_as = @view_type || 'html' %>
>     <% render_as = 'html' unless Clip.available_types.include?( render_as )
> %>
>         <% case render_as %>
>         <% when 'quote' %>
>             <%= render :partial => 'text',     :locals => { :clip => detail
> } %>
>         <% when 'images' %>
>           <%= render :partial => 'images',     :locals => { :clip => detail
> } %>
>         <% when 'html' %>
>             <%= render :partial => 'html',        :locals => { :clip =>
> detail } %>
>         <% end %>
>
>     </blockquote>
>      </div>
> </div>
>
>
> The _text, _images, _html partials are very simple so I won't show them
> here.  This will be enough I think to evaluate it.
>
> Thank you for helping with this.

OK - there's quite a bit going on here, and I don't really have time
to address every detail right now - but here's a couple of things to
think about:

Conventional wisdom suggests that you should favor decision making in
controllers and helpers rather than in the views themselves. One
reason for this is that view templates boil down to a single method,
so you have to provide all of the state they need every time. If your
view has nothing but instance variables that get assigned from the
controller, and never reach into them for their data, then you have
nothing to set up in a test.

Consider this:

<% content_for :action_bar do %>
  <% @public_books = current_user.public_books %>
  <% @private_books = current_user.private_books %>
  <%= render :file => 'books/_book_list.html.erb' -%>
<% end %>

That design choice requires that you set up a current_user which can
provide public_books and private_books. If, instead, you handled that
in the controller, you'd still have to provide a current_user for the
controller examples, but it becomes much easier to start pushing
things around to different methods that can each be tested in
isolation, so the setup for each can get smaller. If you did this, the
view example might look like this:

template.expects_render(:file => 'books/_book_list.html.erb')

instead of this:

template.stub!(:current_user).and_return(
  mock_model(User,
    :public_books => [],
    :private_books => [],
  )
)
template.expects_render(:file => 'books/_book_list.html.erb')

Given what you've got, I think you could do this (with trunk) in before(:each):

============================
controller.stub!(:dom_id).and_return("anything")
template.stub!(:current_user).and_return(
  mock_model(User,
    :public_books => [],
    :private_books => [],
  )
)
template.stubs_render(:file => 'books/_book_list.html.erb')
template.stubs_render(:partial => 'detail', :collection => @clips)

assigns[:clips] => []
assigns[:book] => mock_model(Book)
============================

Then you could use Message Expectations (mocks) in each example for
the specific thing you want to describe.

Hope this helps.

David


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

From dchelimsky at gmail.com  Fri Jul  6 14:27:47 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 6 Jul 2007 13:27:47 -0500
Subject: [rspec-users] stubbing helper methods for View specs
In-Reply-To: <64BFD93F-71D6-47E0-A4C0-22DEBDB6C6DD@gmail.com>
References: <64BFD93F-71D6-47E0-A4C0-22DEBDB6C6DD@gmail.com>
Message-ID: <57c63afe0707061127i598c64b0k32e2229c82241782@mail.gmail.com>

On 7/6/07, Jens-Christian Fischer <jcfischer.lists at gmail.com> wrote:
> Hi there
>
> I have several view specs, that include the following snippet in
> their "before" block to stub the methods by acts_as_authenticated
>
>    before :each do
>      @u = mock_model(User)
>      @u.should_receive(:name).and_return("Hans Muster")
>      template.should_receive(:logged_in?).and_return(true)
>      template.should_receive(:current_user).and_return(@u)
>    end
>
> this works for views / helpers like this:
>
>    it "should show bla" do
>      render "/layouts/thetool"
>      response.should have_tag("p", "bla")
>    end
>
> and the view (haml to make things more interesting)
>
>    - if logged_in?
>      %p bla
>
>
> Now I also use Ezra acl_system2 plugin which defines a "restrict_to"
> method that queries some roles. When I stub the methods above and run
> specs, I get the following error:
>
> ActionView::TemplateError in '/users/show should display the
> information of the user'
> undefined local variable or method `current_user' for
> #<Spec::Rails::DSL::ViewExampleController:0x35d5cc0>
> On line #59 of app/views/users/show.haml
>
>      56:       - @user.roles.each do |role|
>      57:         = role.title
>      58:
>      59: - restrict_to "admin | projektleiter" do
>      60:   = link_to "Bearbeiten", edit_user_url(@user)
>      app/views//users/show.haml:59
>      vendor/plugins/acl_system2/lib/caboose/access_control.rb:75:in
> `restrict_to'
>      (eval):2:in `restrict_to'
>      (eval):164:in `_render_haml_1'
>      vendor/plugins/haml/lib/haml/engine.rb:435:in `compile'
>      vendor/plugins/haml/lib/haml/engine.rb:186:in `to_html'
>      vendor/plugins/haml/lib/haml/template.rb:69:in `render'
>      vendor/rails/actionpack/lib/action_view/base.rb:502:in
> `delegate_render'
>      vendor/rails/actionpack/lib/action_view/base.rb:324:in
> `render_template_old'
>      vendor/plugins/haml/lib/haml/template.rb:96:in `render_template'
>      vendor/rails/actionpack/lib/action_view/base.rb:286:in
> `globalize_old_render_file'
>      vendor/plugins/trunk/lib/globalize/rails/action_view.rb:20:in
> `render_file'
>      vendor/rails/actionpack/lib/action_controller/base.rb:879:in
> `render_file'
>      vendor/rails/actionpack/lib/action_controller/base.rb:814:in
> `render_with_no_layout'
>      vendor/rails/actionpack/lib/action_controller/layout.rb:258:in
> `render_without_benchmark'
>      vendor/rails/actionpack/lib/action_controller/benchmarking.rb:
> 51:in `render'
>      /usr/local/lib/ruby/site_ruby/1.8/benchmark.rb:300:in `measure'
>      vendor/rails/actionpack/lib/action_controller/benchmarking.rb:
> 51:in `render'
>      vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/
> view.rb:51:in `render'
>      spec/views/users/show_haml_spec.rb:23
>      ...
>
>
>
> Interestingly, when I misspell the name of the stub in the working
> example, I get the following error:
>
> 1)
> ActionView::TemplateError in '/shared/layout_test not logged in
> should have the correct head information'
> undefined method `logged_in?' for #<ActionView::Base:0x22ec6f8>
> On line #13 of app/views/layouts/thetool.haml
>
> app/views//layouts/thetool.haml:13
>      app/helpers/application_helper.rb:5:in `login_logout'
>      (eval):28:in `_render_haml_1'
>      vendor/plugins/haml/lib/haml/engine.rb:435:in `compile'
>      vendor/plugins/haml/lib/haml/engine.rb:186:in `to_html'
>      vendor/plugins/haml/lib/haml/template.rb:69:in `render'
>      vendor/rails/actionpack/lib/action_view/base.rb:502:in
> `delegate_render'
>      vendor/rails/actionpack/lib/action_view/base.rb:324:in
> `render_template_old'
>      vendor/plugins/haml/lib/haml/template.rb:96:in `render_template'
>      vendor/rails/actionpack/lib/action_view/base.rb:286:in
> `globalize_old_render_file'
>      vendor/plugins/trunk/lib/globalize/rails/action_view.rb:20:in
> `render_file'
>      vendor/rails/actionpack/lib/action_controller/base.rb:879:in
> `render_file'
>      vendor/rails/actionpack/lib/action_controller/base.rb:814:in
> `render_with_no_layout'
>      vendor/rails/actionpack/lib/action_controller/layout.rb:258:in
> `render_without_benchmark'
>      vendor/rails/actionpack/lib/action_controller/benchmarking.rb:
> 51:in `render'
>      /usr/local/lib/ruby/site_ruby/1.8/benchmark.rb:300:in `measure'
>      vendor/rails/actionpack/lib/action_controller/benchmarking.rb:
> 51:in `render'
>      vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/
> view.rb:51:in `render'
>      spec/views/layouts/thetool_haml_spec.rb:16
>
>
> Note the different class (#<ActionView::Base:0x22ec6f8> vs
> #<Spec::Rails::DSL::ViewExampleController:0x35d5cc0>) in the two specs.
>
> I don't have enough rspec_fu to deduce where the problem lies..
>
>
> Any helpers?

In a nutshell - Rails compiles templates the first time they are
encountered in a given runtime. Combine this with the fact that mock
expectations are cleared out after every example, but the mock
framework doesn't have access to the compiled template, and you can
imagine that this is )(*&)(*ing nightmare-ish can of worms.

I thought I had a solution for this in trunk, but I've just discovered
some problems with it and am working to resolve them.

Sorry - can't be more helpful right now.

>
> thanks
> Jens-Christian
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From jcfischer.lists at gmail.com  Fri Jul  6 15:13:57 2007
From: jcfischer.lists at gmail.com (Jens-Christian Fischer)
Date: Fri, 6 Jul 2007 21:13:57 +0200
Subject: [rspec-users] stubbing helper methods for View specs
In-Reply-To: <57c63afe0707061127i598c64b0k32e2229c82241782@mail.gmail.com>
References: <64BFD93F-71D6-47E0-A4C0-22DEBDB6C6DD@gmail.com>
	<57c63afe0707061127i598c64b0k32e2229c82241782@mail.gmail.com>
Message-ID: <15B88DEF-F378-4013-B4E2-C3AB670F1339@gmail.com>

>>
>> I don't have enough rspec_fu to deduce where the problem lies..
>>
>>
>> Any helpers?
>
> In a nutshell - Rails compiles templates the first time they are
> encountered in a given runtime. Combine this with the fact that mock
> expectations are cleared out after every example, but the mock
> framework doesn't have access to the compiled template, and you can
> imagine that this is )(*&)(*ing nightmare-ish can of worms.
>
> I thought I had a solution for this in trunk, but I've just discovered
> some problems with it and am working to resolve them.
>
> Sorry - can't be more helpful right now.

so my best bet would be to use regular functional tests for the time  
being? (Having no specs/tests kind of seems to be the wrong solution  
to this problem...

:)

cheers jc

From dchelimsky at gmail.com  Fri Jul  6 15:17:43 2007
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 6 Jul 2007 14:17:43 -0500
Subject: [rspec-users] stubbing helper methods for View specs
In-Reply-To: <15B88DEF-F378-4013-B4E2-C3AB670F1339@gmail.com>
References: <64BFD93F-71D6-47E0-A4C0-22DEBDB6C6DD@gmail.com>
	<57c63afe0707061127i598c64b0k32e2229c82241782@mail.gmail.com>
	<15B88DEF-F378-4013-B4E2-C3AB670F1339@gmail.com>
Message-ID: <57c63afe0707061217i5ed65afg22764f9a6f35221@mail.gmail.com>

On 7/6/07, Jens-Christian Fischer <jcfischer.lists at gmail.com> wrote:
> >>
> >> I don't have enough rspec_fu to deduce where the problem lies..
> >>
> >>
> >> Any helpers?
> >
> > In a nutshell - Rails compiles templates the first time they are
> > encountered in a given runtime. Combine this with the fact that mock
> > expectations are cleared out after every example, but the mock
> > framework doesn't have access to the compiled template, and you can
> > imagine that this is )(*&)(*ing nightmare-ish can of worms.
> >
> > I thought I had a solution for this in trunk, but I've just discovered
> > some problems with it and am working to resolve them.
> >
> > Sorry - can't be more helpful right now.
>
> so my best bet would be to use regular functional tests for the time
> being? (Having no specs/tests kind of seems to be the wrong solution
> to this problem...

Agreed that you shouldn't be without examples for this stuff, but you
have other options within rspec:

1 - use rspec controller examples in integration mode and use real
objects (almost exactly like rails functionals, except its rspec).

2 - use rspec view examples without mocking things directly on the
template. You can still mock helper methods (on controller or
helpers).

>
> :)
>
> cheers jc
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From has.sox at gmail.com  Mon Jul  9 09:55:09 2007
From: has.sox at gmail.com (Daniel N)
Date: Mon, 9 Jul 2007 23:55:09 +1000
Subject: [rspec-users] Is it bad to use a shared example in rspec_helper.rb?
Message-ID: <2fff50390707090655u457cf3fepc930114d24da6409@mail.gmail.com>

I want to extract the method for logging in so that I don't have to include
it in each before call.

Is it bad to use a describe block within the rspec_helper in a rails project
for controller tests?

I have in my spec_helper.rb

describe "an authenticated request", :shared => true do
  before( :each ) do
    @u = mock_model( User )
    mock_login( @u )
  end

  def mock_login( user )
    session[:user] = user
    controller.send( :instance_variable_set, :@current_user, user )
    controller.stub!( :current_user ).and_return( user )
  end

end


which I then share in my relevant controller tests with

  it_should_behave_like "an authenticated request"

Is this bad?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070709/d74c003f/attachment-0001.html 

From has.sox at gmail.com  Mon Jul  9 10:31:33 2007
From: has.sox at gmail.com (Daniel N)
Date: Tue, 10 Jul 2007 00:31:33 +1000
Subject: [rspec-users] Mocking User.find( :all, :limit => 10 )
Message-ID: <2fff50390707090731ob737113qa28680f3653cbcfe@mail.gmail.com>

Hi,

I'm trying to setup a mock for my controller test but I can't get it to
recognise the mock.

I use

  it "should find all users" do
    User.should_receive(:find).with( :all, :limit => 10
).and_return([@user])
    do_get
  end

and in the controller
@users = User.find(:all, :limit => 10 )

But this does not work.  It gives me
User expected :find with (:all) once, but received it 0 times

If I remove the :limit from the controller
@users = User.find(:all)

I get
User expected :find with (:all, {:limit=>10}) once, but received it 0 times

How do I spec mocks with options passed to them?

Cheers
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070710/4d8df89c/attachment.html 

From has.sox at gmail.com  Mon Jul  9 11:00:31 2007
From: has.sox at gmail.com (Daniel N)
Date: Tue, 10 Jul 2007 01:00:31 +1000
Subject: [rspec-users] Mocking User.find( :all, :limit => 10 )
In-Reply-To: <2fff50390707090731ob737113qa28680f3653cbcfe@mail.gmail.com>
References: <2fff50390707090731ob737113qa28680f3653cbcfe@mail.gmail.com>
Message-ID: <2fff50390707090800l1b75aa34s6914514a2ffc81fb@mail.gmail.com>

My Bad... Please ignore

On 7/10/07, Daniel N <has.sox at gmail.com> wrote:
>
> Hi,
>
> I'm trying to setup a mock for my controller test but I can't get it to
> recognise the mock.
>
> I use
>
>   it "should find all users" do
>     User.should_receive(:find).with( :all, :limit => 10
> ).and_return([@user])
>     do_get
>   end
>
> and in the controller
> @users = User.find(:all, :limit => 10 )
>
> But this does not work.  It gives me
> User expected :find with (:all) once, but received it 0 times
>
> If I remove the :limit from the controller
> @users = User.find(:all)
>
> I get
> User expected :find with (:all, {:limit=>10}) once, but received it 0
> times
>
> How do I spec mocks with options passed to them?
>
> Cheers
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20070710/cb13ee46/attachment.html 

From johan at johansorensen.com  Mon Jul  9 11:33:28 2007
From: johan at johansorensen.com (=?ISO-8859-1?Q?Johan_S=F8rensen?=)
Date: Mon, 9 Jul 2007 17:33:28 +0200
Subject: [rspec-users] Mocking User.find( :all, :limit => 10 )
In-Reply-To: <2fff50390707090800l1b75aa34s6914514a2ffc81fb@mail.gmail.com>
References: <2fff50390707090731ob737113qa28680f3653cbcfe@mail.gmail.com>
	<2fff50390707090800l1b75aa34s6914514a2ffc81fb@mail.gmail.com>
Message-ID: <43731001-FC81-4843-A2AF-95145D960610@johansorensen.com>


On Jul 9, 2007, at 5:00 PM, Daniel N wrote:

> My Bad... Please ignore
>
> On 7/10/07, Daniel N <has.sox at gmail.com> wrote:
>   it "should find all users" do
>     User.should_receive(:find).with( :all, :limit => 10 ).and_return 
> ([@user])
>     do_get
>   end

Sorry for piggybacking on your post, but since you've apparantly  
figured out your isssue I have a slightly similar question; sometimes  
I have (in ActiveRecord) a verbose #find I want to moc