From pergesu at gmail.com  Tue Jul  1 02:10:46 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Mon, 30 Jun 2008 23:10:46 -0700
Subject: [rspec-users] Odd Date-based spec failing
In-Reply-To: <A265A877-BDBF-4315-A66A-3C7F56FC9403@matt-darby.com>
References: <E6E9569D-023D-4E3B-B272-6AB2F306AAA3@matt-darby.com>
	<5e2dde260806301940i7342b4ddw2a6c4c2158d51c8a@mail.gmail.com>
	<A265A877-BDBF-4315-A66A-3C7F56FC9403@matt-darby.com>
Message-ID: <810a540e0806302310l50ce8434v1923aa413d38645@mail.gmail.com>

What do you see when you puts the values of end_date, start_date, and
Date.today inside of #percentage_complete?

On Mon, Jun 30, 2008 at 7:43 PM, Matt Darby <matt at matt-darby.com> wrote:
> On Jul 1, 2008, at 10:10 PM, Camilo Torres wrote:
>
>> It seems your Phase.percentage_complete is not working as you expect.
>> It clearly returns 100 when you are specting 83. The test clearly said
>> that.
>>
>> ?What is the implementation of your percentage_complete method?
>
> It only fails when run via 'rake spec:models'; otherwise, it passes.
>
>  def percentage_complete
>    # Returns an integer representation of a percentage (i.e. '78')
>
>    return 100 if Date.today >= self.end_date
>
>    length_in_days  = (self.end_date - self.start_date).to_f
>    days_into_phase = (Date.today - self.start_date).to_f
>
>    ((days_into_phase / length_in_days) * 100.0).round
>  end
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From matt at matt-darby.com  Tue Jul  1 08:06:18 2008
From: matt at matt-darby.com (Matt Darby)
Date: Tue, 1 Jul 2008 08:06:18 -0400
Subject: [rspec-users] Odd Date-based spec failing
In-Reply-To: <810a540e0806302310l50ce8434v1923aa413d38645@mail.gmail.com>
References: <E6E9569D-023D-4E3B-B272-6AB2F306AAA3@matt-darby.com>
	<5e2dde260806301940i7342b4ddw2a6c4c2158d51c8a@mail.gmail.com>
	<A265A877-BDBF-4315-A66A-3C7F56FC9403@matt-darby.com>
	<810a540e0806302310l50ce8434v1923aa413d38645@mail.gmail.com>
Message-ID: <79205FC9-628C-4595-A65C-D5CFA9325A6C@matt-darby.com>

On Jul 1, 2008, at 2:10 AM, Pat Maddox wrote:

> What do you see when you puts the values of end_date, start_date, and
> Date.today inside of #percentage_complete?


When run via TextMate/Rspec Bundle:
Date.today = 2008-07-01
self.start_date = 2008-06-26
self.end_date = 2008-07-02

When run via 'rake spec:models'
Date.today = 2008-07-01
self.start_date = 0825-09-17
self.end_date = 2008-07-02

Pretty obvious what the bug is suddenly, but would cause this?
Come to think of it, I'd seen this before in rare random cases in  
other Date-based specs in the past, though currently everything else  
is passing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080701/c928bbcb/attachment.html>

From tom at experthuman.com  Tue Jul  1 08:23:02 2008
From: tom at experthuman.com (Tom Stuart)
Date: Tue, 1 Jul 2008 13:23:02 +0100
Subject: [rspec-users] Odd Date-based spec failing
In-Reply-To: <79205FC9-628C-4595-A65C-D5CFA9325A6C@matt-darby.com>
References: <E6E9569D-023D-4E3B-B272-6AB2F306AAA3@matt-darby.com>
	<5e2dde260806301940i7342b4ddw2a6c4c2158d51c8a@mail.gmail.com>
	<A265A877-BDBF-4315-A66A-3C7F56FC9403@matt-darby.com>
	<810a540e0806302310l50ce8434v1923aa413d38645@mail.gmail.com>
	<79205FC9-628C-4595-A65C-D5CFA9325A6C@matt-darby.com>
Message-ID: <24E4D2F0-172E-48AD-B28D-E84FC9E7882E@experthuman.com>

On 1 Jul 2008, at 13:06, Matt Darby wrote:
> When run via 'rake spec:models'
> Date.today = 2008-07-01
> self.start_date = 0825-09-17
> self.end_date = 2008-07-02
>
> Pretty obvious what the bug is suddenly, but would cause this?

Not a solution, but a clue:

$ ./script/console
 >> Date.today.minus_with_duration(5.days)
=> Thu, 26 Jun 2008
 >> Date.today.minus_without_duration(5.days.to_i)
=> Sun, 17 Sep 0825

Is this a load-order problem? Perhaps  
ActiveSupport::CoreExtensions::Date::Calculations isn't kicking in  
correctly.

Cheers,
-Tom

From matt at matt-darby.com  Tue Jul  1 11:21:52 2008
From: matt at matt-darby.com (Matt Darby)
Date: Tue, 1 Jul 2008 11:21:52 -0400
Subject: [rspec-users] Odd Date-based spec failing
In-Reply-To: <24E4D2F0-172E-48AD-B28D-E84FC9E7882E@experthuman.com>
References: <E6E9569D-023D-4E3B-B272-6AB2F306AAA3@matt-darby.com>
	<5e2dde260806301940i7342b4ddw2a6c4c2158d51c8a@mail.gmail.com>
	<A265A877-BDBF-4315-A66A-3C7F56FC9403@matt-darby.com>
	<810a540e0806302310l50ce8434v1923aa413d38645@mail.gmail.com>
	<79205FC9-628C-4595-A65C-D5CFA9325A6C@matt-darby.com>
	<24E4D2F0-172E-48AD-B28D-E84FC9E7882E@experthuman.com>
Message-ID: <3B6415BF-3E17-4B5C-A74E-9DA66161D0EC@matt-darby.com>

On Jul 1, 2008, at 8:23 AM, Tom Stuart wrote:
> $ ./script/console
> >> Date.today.minus_with_duration(5.days)
> => Thu, 26 Jun 2008
> >> Date.today.minus_without_duration(5.days.to_i)
> => Sun, 17 Sep 0825
>
> Is this a load-order problem? Perhaps  
> ActiveSupport::CoreExtensions::Date::Calculations isn't kicking in  
> correctly.

Hrm, quite interesting there. So would this be considered a Rails issue?

From marcio.rails at gmail.com  Tue Jul  1 13:59:16 2008
From: marcio.rails at gmail.com (marcio)
Date: Tue, 1 Jul 2008 10:59:16 -0700 (PDT)
Subject: [rspec-users] jumping authentication spec
Message-ID: <1595bf9a-32e8-410d-925e-4832ededfb94@56g2000hsm.googlegroups.com>

hi everyone! i ve been working in my new rspec scaffold generator.
I have made all the neccesary  specs over all controllers and models.
I am working with restful_authenticated plugin. I have already coded
the spects of it too. But now im trying to test my controllers and i
dont know the way to "jump" my authentication system when i run rake
spec. The errors described are reffered to this plugin and i would
like to ignore it.
 I think the solution  might be mocking the user and turning "true" to
the login? method... i have tryied with the login? method and nothing
happened. Am i in the right way?
have anybody had this problem before?

Thanks a lot.

Marcio.

From dchelimsky at gmail.com  Tue Jul  1 14:08:55 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 1 Jul 2008 13:08:55 -0500
Subject: [rspec-users] jumping authentication spec
In-Reply-To: <1595bf9a-32e8-410d-925e-4832ededfb94@56g2000hsm.googlegroups.com>
References: <1595bf9a-32e8-410d-925e-4832ededfb94@56g2000hsm.googlegroups.com>
Message-ID: <9ACC0CA1-00E3-49EE-87B7-0ADC9A80F111@gmail.com>

On Jul 1, 2008, at 12:59 PM, marcio <marcio.rails at gmail.com> wrote:

> hi everyone! i ve been working in my new rspec scaffold generator.
> I have made all the neccesary  specs over all controllers and models.
> I am working with restful_authenticated plugin. I have already coded
> the spects of it too. But now im trying to test my controllers and i
> dont know the way to "jump" my authentication system when i run rake
> spec. The errors described are reffered to this plugin and i would
> like to ignore it.
> I think the solution  might be mocking the user and turning "true" to
> the login? method... i have tryied with the login? method and nothing
> happened. Am i in the right way?
> have anybody had this problem before?

Mocking the user sounds like the right approach. If you post some code  
we can help you more specifically.

Cheers,
David

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

From court3nay at gmail.com  Tue Jul  1 14:18:22 2008
From: court3nay at gmail.com (Courtenay)
Date: Tue, 1 Jul 2008 11:18:22 -0700
Subject: [rspec-users] jumping authentication spec
In-Reply-To: <9ACC0CA1-00E3-49EE-87B7-0ADC9A80F111@gmail.com>
References: <1595bf9a-32e8-410d-925e-4832ededfb94@56g2000hsm.googlegroups.com>
	<9ACC0CA1-00E3-49EE-87B7-0ADC9A80F111@gmail.com>
Message-ID: <4b430c8f0807011118t4f8f4434u5354bbd63ca02693@mail.gmail.com>

On Tue, Jul 1, 2008 at 11:08 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Jul 1, 2008, at 12:59 PM, marcio <marcio.rails at gmail.com> wrote:
>
>> hi everyone! i ve been working in my new rspec scaffold generator.
>> I have made all the neccesary  specs over all controllers and models.
>> I am working with restful_authenticated plugin. I have already coded
>> the spects of it too. But now im trying to test my controllers and i
>> dont know the way to "jump" my authentication system when i run rake
>> spec. The errors described are reffered to this plugin and i would
>> like to ignore it.
>> I think the solution  might be mocking the user and turning "true" to
>> the login? method... i have tryied with the login? method and nothing
>> happened. Am i in the right way?
>> have anybody had this problem before?
>
> Mocking the user sounds like the right approach. If you post some code we
> can help you more specifically.
>
> Cheers,
> David
>

I used to do it like

  @controller.stub!(:login_required)
  @controller.stub!(:current_user).and_return mock_model(User)

is this still valid?

From ivorpaul at gmail.com  Tue Jul  1 16:48:00 2008
From: ivorpaul at gmail.com (Ivor Paul)
Date: Tue, 1 Jul 2008 22:48:00 +0200
Subject: [rspec-users] matchers not working...?
Message-ID: <dea6f0090807011348t16574cf8n3b92139b443e7516@mail.gmail.com>

Hi.

I am pretty new to rspec so forgive my ignorance.

I am getting errors that seem to be the matchers not working - example:

vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:478:in
`const_missing': uninitialized constant
Spec::Rails::Example::ModelExampleGroup::Be_nil

I have seen the same error with other matchers like be_valid etc.

Does anyone have an idea what could be causing this?

I am using the rspec and rspec_on_rails plugins. Pretty much the
latest versions. Rails 2.0.2

Regards
Ivor

From dchelimsky at gmail.com  Tue Jul  1 16:57:38 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 1 Jul 2008 15:57:38 -0500
Subject: [rspec-users] matchers not working...?
In-Reply-To: <dea6f0090807011348t16574cf8n3b92139b443e7516@mail.gmail.com>
References: <dea6f0090807011348t16574cf8n3b92139b443e7516@mail.gmail.com>
Message-ID: <D0A28609-DEC4-49C5-B794-B47D3BF3467B@gmail.com>

On Jul 1, 2008, at 3:48 PM, Ivor Paul wrote:

> I am getting errors that seem to be the matchers not working -  
> example:
>
> vendor/rails/activerecord/lib/../../activesupport/lib/active_support/ 
> dependencies.rb:478:in
> `const_missing': uninitialized constant
> Spec::Rails::Example::ModelExampleGroup::Be_nil
>
> I have seen the same error with other matchers like be_valid etc.

Does the code say Be_nil instead of be_nil?

> Does anyone have an idea what could be causing this?

How are you invoking rspec? With rake? ruby? script/spec? or autotest?

> I am using the rspec and rspec_on_rails plugins. Pretty much the
> latest versions. Rails 2.0.2

With the 1.1.4 release we changed rspec_on_rails to rspec-rails, so  
I'm guessing you have the latest code that's still in subversion at  
rubyforge, but not the latest from github.

Would you mind giving the code from github a shot? Install  
instructions can be found at http://github.com/dchelimsky/rspec-rails/wikis/home

Cheers,
David

> Regards
> Ivor

From chris at cobaltedge.com  Tue Jul  1 19:37:03 2008
From: chris at cobaltedge.com (Christopher Bailey)
Date: Tue, 1 Jul 2008 16:37:03 -0700
Subject: [rspec-users] Cookies - how to set in controller specs?
Message-ID: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>

I've been searching Google, the mailing list, etc, etc. and can't for
the life of me get a cookie to be set in a controller spec.  From
everything I've read on the web, it appears all I need to do is the
typical:

  cookies[:name] = value

or

  cookies[:name] = { :value => something, :expires => 1.year.from_now }

I have also see things like doing "@request.cookies[:name]..." or
setting the value to doing CGI::Cookie.new(...), and so on.

I do not want to mock cookies, I want to actually test them, as that
is the logic I'm trying to test.  I know that my actual code works as
I've run through this by directly testing in the browser, but of
course I want specs to test it.  Can someone show a test of setting a
cookie, getting a page/action (and then optionally testing cookie
after that)?

-- 
Christopher Bailey
Cobalt Edge LLC
http://cobaltedge.com

From dchelimsky at gmail.com  Wed Jul  2 07:06:38 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 06:06:38 -0500
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
Message-ID: <57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>

On Tue, Jul 1, 2008 at 6:37 PM, Christopher Bailey <chris at cobaltedge.com> wrote:
> I've been searching Google, the mailing list, etc, etc. and can't for
> the life of me get a cookie to be set in a controller spec.  From
> everything I've read on the web, it appears all I need to do is the
> typical:
>
>  cookies[:name] = value
>
> or
>
>  cookies[:name] = { :value => something, :expires => 1.year.from_now }
>
> I have also see things like doing "@request.cookies[:name]..." or
> setting the value to doing CGI::Cookie.new(...), and so on.
>
> I do not want to mock cookies, I want to actually test them, as that
> is the logic I'm trying to test.  I know that my actual code works as
> I've run through this by directly testing in the browser, but of
> course I want specs to test it.  Can someone show a test of setting a
> cookie, getting a page/action (and then optionally testing cookie
> after that)?

This is just one of those goofy things in Rails testing. I'm not sure
the best way to make it easier in rspec without breaking existing
examples in the process. Regardless, here's how you interact with
cookies from an example:

To set a cookie:

  request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key', 'cookie value')

To read a cookie

  response.cookies[:cookie_key].should == ["expected value"]

or

  cookies[:cookie_key].should == ["expected value"]

Rails provides a cookies object that is actually response.cookies, so
you don't *have* to reference it through the response object. I would,
however, as I've been known to try to set a cookie in an example using
cookies when I should have been using request.cookies. So I try to
keep them explicit.

HTH,
David

From dchelimsky at gmail.com  Wed Jul  2 07:15:10 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 06:15:10 -0500
Subject: [rspec-users] Stopping Example Execution?
In-Reply-To: <BLU146-W4326878715F7908584B6EBD79F0@phx.gbl>
References: <BLU146-W4326878715F7908584B6EBD79F0@phx.gbl>
Message-ID: <57c63afe0807020415m9df6bdfmfed02ba908746e00@mail.gmail.com>

On Mon, Jun 30, 2008 at 5:11 PM, Britt Mileshosky
<mileshosky at hotmail.com> wrote:
>
> n Sun, Jun 29, 2008 at 12:20 PM, David Chelimsky wrote:
> On Jun 29, 2008, at 11:18 AM, Britt Mileshosky wrote:
>
> However, do you see where something like a return statement or end example statement could be beneficial?
> If you are working from the top down with your controller action execution, then you only need to test your expectation
> and then bail out of your action. No need to further test or meet requirements on anything else in that action because your
> single test has been met.
>
> - in my example for making sure I find a user, I'd like to end execution once I DID find the user, i shouldn't have to satisfy
> requirements about finding an account and a person... I'll write those expectations later in another nested describe group, as you
> can see here, in a top down process
>
> PeopleController with a logged in user
> - should find user
>
> PeopleController with a logged in user who has an account
> - should find account
>
> PeopleController with a logged in user who doesnt have an account
> - shouldn't find account
> - should redirect ...
>
> PeopleController with a logged in user who has an account the person belongs to
> - should find person
> - should assign person for the view
>
> PeopleController with a logged in user who has an account the requested person does not belong to
> - should not find person
> - should ...
>
> My instinct about this is that it would encourage long methods because it would make it less painful to test them, so I would be adverse to anything that let's you short circuit the method.
>
> Anybody else have opinions on that?
>
>
>
> I'm just catching up on email now after being sick for the past six days, but health aside my opinion is that I agree with David's opinion. Rather than focusing on how-to write easier tests that complain less, start focusing on how-to write the right tests that complain when necessary.
>
> One of the benefits associated with feeling the pain of a test is that it may be a sign to re-assess and refactor your code. This usually happens early enough that it only takes a few minutes. Short circuiting essentially gives you the ability to not feel the pain. Its like CIPA [0], but for code. I would fear that the code would get so bad that by the time the test cried with pain your code was already beyond easy repair and instead required invasive surgery.
>
> Tests are part of the nervous system of your application. When they hurt, they're telling you something isn't right and that it should be addressed,
>
>
>
> I wouldn't really say that anything I have been presenting has been a result of 'pains',
> more so an observation on how an example group with other example groups can be much more readable
> for myself and for other developers when they need to read the specs. Stubbing everything at the top doesn't
> make complete sense. Why not stub inside the example group that has a NICE describe statement telling you
> what this stubbing is related to. We can't do this because the first examples will blow up due to having to execute
> all the code.
>
> Take the 2 examples:
>
> ------------------------------------------------------------------------------------------------------------------------
> PeopleController
> # stub everything way up here at the top where these
> # definitions are out of context (by means of position) with following examples
> #
> # stub controller requirments
> # stub logged in requirement
> # stub account requirement
> # stub no account requirement
> # stub account owns person
> # stub account doesn't own person
>
>
> PeopleController with before filters
> - should require user
>
> PeopleController with a logged in user
> - should find user
>
> PeopleController with a logged in user who has an account
> - should find account
>
> PeopleController with a logged in user who doesnt have an account
> - shouldn't find account
> - should redirect ...
>
> PeopleController with a logged in user who has an account the person belongs to
> - should find person
> - should assign person for the view
>
> PeopleController with a logged in user who has an account the requested person does not belong to
> - should not find person
> - should ...
>
> ------------------------------------------------------------------------------------------------------------------------
> PeopleController
> # stub the minimum needed to get to the first example group up and running
>
> PeopleController with before filters
> - should require user
>
> PeopleController with a logged in user
> # stub logged in requirement
> - should find user
>
> PeopleController with a logged in user who has an account
> # stub account requirement
> - should find account
>
> PeopleController with a logged in user who doesnt have an account
> # stub no account requirement
> - shouldn't find account
> - should redirect ...
>
> PeopleController with a logged in user who has an account the person belongs to
> # stub account owns person
> - should find person
> - should assign person for the view
>
> PeopleController with a logged in user who has an account the requested person does not belong to
> # stub account doesn't own person
> - should not find person
> - should ...
>
> ------------------------------------------------------------------------------------------------------------------------
>
> I prefer the second group, but unfortunately I am not able to write my specs in this organized fashion.
> Just sayin.

I appreciate the communication value you're looking for, and you can
get it by stubbing everything you need to keep execution going
before(:each) example and then set message expectations
(should_receive) inside each example that help tell the story of that
example.

PeopleController
# stub everything way up here at the top where these
# definitions are out of context (by means of position) with following examples
#
# stub controller requirments
# stub logged in requirement
# stub account requirement
# stub no account requirement
# stub account owns person
# stub account doesn't own person

PeopleController with before filters
- should require user

PeopleController with a logged in user
# expect logged in query
- should find user

PeopleController with a logged in user who has an account
# expect logged in query
# expect account query
- should find account

etc

HTH,
David

>
> Britt

From ivorpaul at gmail.com  Wed Jul  2 08:02:27 2008
From: ivorpaul at gmail.com (Ivor Paul)
Date: Wed, 2 Jul 2008 14:02:27 +0200
Subject: [rspec-users] matchers not working...?
In-Reply-To: <D0A28609-DEC4-49C5-B794-B47D3BF3467B@gmail.com>
References: <dea6f0090807011348t16574cf8n3b92139b443e7516@mail.gmail.com>
	<D0A28609-DEC4-49C5-B794-B47D3BF3467B@gmail.com>
Message-ID: <dea6f0090807020502u5cd0b2d5wc4393fb534dfd59e@mail.gmail.com>

Hi David

thanks for the response!
This is what the error looks like for be_valid
/activesupport/lib/active_support/dependencies.rb:478:in
`const_missing': uninitialized constant
Spec::Rails::Example::ModelExampleGroup::Be_valid

and for be_nil
/activesupport/lib/active_support/dependencies.rb:478:in
`const_missing': uninitialized constant
Spec::Rails::Example::ModelExampleGroup::Be_nil

I invoke the tests using rake spec. I also get this error when I use
./script/spec path/to/file.

We were using svn externals for the plugins. I will give github a try
and let you know what happens.

Thanks for the help.
Ivor

On Tue, Jul 1, 2008 at 10:57 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Jul 1, 2008, at 3:48 PM, Ivor Paul wrote:
>
>> I am getting errors that seem to be the matchers not working - example:
>>
>>
>> vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:478:in
>> `const_missing': uninitialized constant
>> Spec::Rails::Example::ModelExampleGroup::Be_nil
>>
>> I have seen the same error with other matchers like be_valid etc.
>
> Does the code say Be_nil instead of be_nil?
>
>> Does anyone have an idea what could be causing this?
>
> How are you invoking rspec? With rake? ruby? script/spec? or autotest?
>
>> I am using the rspec and rspec_on_rails plugins. Pretty much the
>> latest versions. Rails 2.0.2
>
> With the 1.1.4 release we changed rspec_on_rails to rspec-rails, so I'm
> guessing you have the latest code that's still in subversion at rubyforge,
> but not the latest from github.
>
> Would you mind giving the code from github a shot? Install instructions can
> be found at http://github.com/dchelimsky/rspec-rails/wikis/home
>
> Cheers,
> David
>
>> Regards
>> Ivor
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From chris at cobaltedge.com  Wed Jul  2 12:15:27 2008
From: chris at cobaltedge.com (Christopher Bailey)
Date: Wed, 2 Jul 2008 09:15:27 -0700
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
Message-ID: <443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>

On Wed, Jul 2, 2008 at 4:06 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
<snip>
>
> This is just one of those goofy things in Rails testing. I'm not sure
> the best way to make it easier in rspec without breaking existing
> examples in the process. Regardless, here's how you interact with
> cookies from an example:
>
> To set a cookie:
>
>  request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key', 'cookie value')

When I do this, in order to get to this cookie in my controller code,
I have to do

  cookies[:cookie_key][:cookie_key]

Basically, it appears that what it does is assign that key a hash of
its own.  That makes sense of course, as I realize a cookie is really
a hash of name, value, path, expires, and so on.  However, it doesn't
jive with the retrieval, as you shouldn't have to double reference it
(which I believe is essentially the point of the [] method on
ActionController::CookieJar and is not how things are documented).

However, what's really behaving weird, is if I do:

  cookies[:cookie_key] = "1234"

Then, in my controller code, if I look at "cookies", it shows that
cookies is a hash, and if I call .keys on it, it spits out
":cookie_key", and if I call .values on it, it says "1234", but if I
then go and do cookies[:cookie_key], it gives me nil.

Again, I have to suspect something weird going on with Rails test
environment/RSpec, since all this works fine outside of tests.  Any
suggestions on how to debug this further or what might be wrong?

I should note I'm using Rails 2.1, and RSpec and rspec-rails from
about a week ago (from GitHub).

> To read a cookie
>
>  response.cookies[:cookie_key].should == ["expected value"]
>
> or
>
>  cookies[:cookie_key].should == ["expected value"]
>
> Rails provides a cookies object that is actually response.cookies, so
> you don't *have* to reference it through the response object. I would,
> however, as I've been known to try to set a cookie in an example using
> cookies when I should have been using request.cookies. So I try to
> keep them explicit.
>
> HTH,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>



-- 
Christopher Bailey
Cobalt Edge LLC
http://cobaltedge.com

From dchelimsky at gmail.com  Wed Jul  2 12:41:40 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 11:41:40 -0500
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
Message-ID: <A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>

On Jul 2, 2008, at 11:15 AM, Christopher Bailey wrote:

> On Wed, Jul 2, 2008 at 4:06 AM, David Chelimsky  
> <dchelimsky at gmail.com> wrote:
> <snip>
>>
>> This is just one of those goofy things in Rails testing. I'm not sure
>> the best way to make it easier in rspec without breaking existing
>> examples in the process. Regardless, here's how you interact with
>> cookies from an example:
>>
>> To set a cookie:
>>
>> request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key',  
>> 'cookie value')
>
> When I do this, in order to get to this cookie in my controller code,
> I have to do
>
>  cookies[:cookie_key][:cookie_key]

Sorry Christopher - try this:

request.cookies[:cookie_key] = 'cookie value'

Cheers,
David

> Basically, it appears that what it does is assign that key a hash of
> its own.  That makes sense of course, as I realize a cookie is really
> a hash of name, value, path, expires, and so on.  However, it doesn't
> jive with the retrieval, as you shouldn't have to double reference it
> (which I believe is essentially the point of the [] method on
> ActionController::CookieJar and is not how things are documented).
>
> However, what's really behaving weird, is if I do:
>
>  cookies[:cookie_key] = "1234"
>
> Then, in my controller code, if I look at "cookies", it shows that
> cookies is a hash, and if I call .keys on it, it spits out
> ":cookie_key", and if I call .values on it, it says "1234", but if I
> then go and do cookies[:cookie_key], it gives me nil.
>
> Again, I have to suspect something weird going on with Rails test
> environment/RSpec, since all this works fine outside of tests.  Any
> suggestions on how to debug this further or what might be wrong?
>
> I should note I'm using Rails 2.1, and RSpec and rspec-rails from
> about a week ago (from GitHub).
>
>> To read a cookie
>>
>> response.cookies[:cookie_key].should == ["expected value"]
>>
>> or
>>
>> cookies[:cookie_key].should == ["expected value"]
>>
>> Rails provides a cookies object that is actually response.cookies, so
>> you don't *have* to reference it through the response object. I  
>> would,
>> however, as I've been known to try to set a cookie in an example  
>> using
>> cookies when I should have been using request.cookies. So I try to
>> keep them explicit.
>>
>> HTH,
>> David
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
>
> -- 
> Christopher Bailey
> Cobalt Edge LLC
> http://cobaltedge.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From chris at cobaltedge.com  Wed Jul  2 12:57:35 2008
From: chris at cobaltedge.com (Christopher Bailey)
Date: Wed, 2 Jul 2008 09:57:35 -0700
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
Message-ID: <443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>

On Wed, Jul 2, 2008 at 9:41 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Jul 2, 2008, at 11:15 AM, Christopher Bailey wrote:
>
>> On Wed, Jul 2, 2008 at 4:06 AM, David Chelimsky <dchelimsky at gmail.com>
>> wrote:
>> <snip>
>>>
>>> This is just one of those goofy things in Rails testing. I'm not sure
>>> the best way to make it easier in rspec without breaking existing
>>> examples in the process. Regardless, here's how you interact with
>>> cookies from an example:
>>>
>>> To set a cookie:
>>>
>>> request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key', 'cookie
>>> value')
>>
>> When I do this, in order to get to this cookie in my controller code,
>> I have to do
>>
>>  cookies[:cookie_key][:cookie_key]
>
> Sorry Christopher - try this:
>
> request.cookies[:cookie_key] = 'cookie value'

I tried that (see below in my email - I just mistakenly wrote it
without the "request." at the beginning).  When I do this, it appears
to set it, but then trying to retrieve it in my controller fails (even
though the key is there, and the value is there, when then requesting
cookies[:cookie_key] I get no value back).  Pretty weird.


> Cheers,
> David
>
>> Basically, it appears that what it does is assign that key a hash of
>> its own.  That makes sense of course, as I realize a cookie is really
>> a hash of name, value, path, expires, and so on.  However, it doesn't
>> jive with the retrieval, as you shouldn't have to double reference it
>> (which I believe is essentially the point of the [] method on
>> ActionController::CookieJar and is not how things are documented).
>>
>> However, what's really behaving weird, is if I do:
>>
>>  cookies[:cookie_key] = "1234"
>>
>> Then, in my controller code, if I look at "cookies", it shows that
>> cookies is a hash, and if I call .keys on it, it spits out
>> ":cookie_key", and if I call .values on it, it says "1234", but if I
>> then go and do cookies[:cookie_key], it gives me nil.
>>
>> Again, I have to suspect something weird going on with Rails test
>> environment/RSpec, since all this works fine outside of tests.  Any
>> suggestions on how to debug this further or what might be wrong?
>>
>> I should note I'm using Rails 2.1, and RSpec and rspec-rails from
>> about a week ago (from GitHub).
>>
>>> To read a cookie
>>>
>>> response.cookies[:cookie_key].should == ["expected value"]
>>>
>>> or
>>>
>>> cookies[:cookie_key].should == ["expected value"]
>>>
>>> Rails provides a cookies object that is actually response.cookies, so
>>> you don't *have* to reference it through the response object. I would,
>>> however, as I've been known to try to set a cookie in an example using
>>> cookies when I should have been using request.cookies. So I try to
>>> keep them explicit.
>>>
>>> HTH,
>>> David
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>
>>
>>
>> --
>> Christopher Bailey
>> Cobalt Edge LLC
>> http://cobaltedge.com
>> _______________________________________________
>> 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
>



-- 
Christopher Bailey
Cobalt Edge LLC
http://cobaltedge.com

From mileshosky at hotmail.com  Wed Jul  2 13:13:59 2008
From: mileshosky at hotmail.com (Britt Mileshosky)
Date: Wed, 2 Jul 2008 10:13:59 -0700
Subject: [rspec-users] Stopping Example Execution?
In-Reply-To: <57c63afe0807020415m9df6bdfmfed02ba908746e00@mail.gmail.com>
References: <BLU146-W4326878715F7908584B6EBD79F0@phx.gbl>
	<57c63afe0807020415m9df6bdfmfed02ba908746e00@mail.gmail.com>
Message-ID: <BLU146-W199A415EA35CCF5816862AD7990@phx.gbl>



----------------------------------------
> Date: Wed, 2 Jul 2008 06:15:10 -0500
> From: dchelimsky at gmail.com
> To: rspec-users at rubyforge.org
> Subject: Re: [rspec-users] Stopping Example Execution?
> 
> On Mon, Jun 30, 2008 at 5:11 PM, Britt Mileshosky
>  wrote:
>>
>> n Sun, Jun 29, 2008 at 12:20 PM, David Chelimsky wrote:
>> On Jun 29, 2008, at 11:18 AM, Britt Mileshosky wrote:
>>
>> However, do you see where something like a return statement or end example statement could be beneficial?
>> If you are working from the top down with your controller action execution, then you only need to test your expectation
>> and then bail out of your action. No need to further test or meet requirements on anything else in that action because your
>> single test has been met.
>>
>> - in my example for making sure I find a user, I'd like to end execution once I DID find the user, i shouldn't have to satisfy
>> requirements about finding an account and a person... I'll write those expectations later in another nested describe group, as you
>> can see here, in a top down process
>>
>> PeopleController with a logged in user
>> - should find user
>>
>> PeopleController with a logged in user who has an account
>> - should find account
>>
>> PeopleController with a logged in user who doesnt have an account
>> - shouldn't find account
>> - should redirect ...
>>
>> PeopleController with a logged in user who has an account the person belongs to
>> - should find person
>> - should assign person for the view
>>
>> PeopleController with a logged in user who has an account the requested person does not belong to
>> - should not find person
>> - should ...
>>
>> My instinct about this is that it would encourage long methods because it would make it less painful to test them, so I would be adverse to anything that let's you short circuit the method.
>>
>> Anybody else have opinions on that?
>>
>>
>>
>> I'm just catching up on email now after being sick for the past six days, but health aside my opinion is that I agree with David's opinion. Rather than focusing on how-to write easier tests that complain less, start focusing on how-to write the right tests that complain when necessary.
>>
>> One of the benefits associated with feeling the pain of a test is that it may be a sign to re-assess and refactor your code. This usually happens early enough that it only takes a few minutes. Short circuiting essentially gives you the ability to not feel the pain. Its like CIPA [0], but for code. I would fear that the code would get so bad that by the time the test cried with pain your code was already beyond easy repair and instead required invasive surgery.
>>
>> Tests are part of the nervous system of your application. When they hurt, they're telling you something isn't right and that it should be addressed,
>>
>>
>>
>> I wouldn't really say that anything I have been presenting has been a result of 'pains',
>> more so an observation on how an example group with other example groups can be much more readable
>> for myself and for other developers when they need to read the specs. Stubbing everything at the top doesn't
>> make complete sense. Why not stub inside the example group that has a NICE describe statement telling you
>> what this stubbing is related to. We can't do this because the first examples will blow up due to having to execute
>> all the code.
>>
>> Take the 2 examples:
>>
>> ------------------------------------------------------------------------------------------------------------------------
>> PeopleController
>> # stub everything way up here at the top where these
>> # definitions are out of context (by means of position) with following examples
>> #
>> # stub controller requirments
>> # stub logged in requirement
>> # stub account requirement
>> # stub no account requirement
>> # stub account owns person
>> # stub account doesn't own person
>>
>>
>> PeopleController with before filters
>> - should require user
>>
>> PeopleController with a logged in user
>> - should find user
>>
>> PeopleController with a logged in user who has an account
>> - should find account
>>
>> PeopleController with a logged in user who doesnt have an account
>> - shouldn't find account
>> - should redirect ...
>>
>> PeopleController with a logged in user who has an account the person belongs to
>> - should find person
>> - should assign person for the view
>>
>> PeopleController with a logged in user who has an account the requested person does not belong to
>> - should not find person
>> - should ...
>>
>> ------------------------------------------------------------------------------------------------------------------------
>> PeopleController
>> # stub the minimum needed to get to the first example group up and running
>>
>> PeopleController with before filters
>> - should require user
>>
>> PeopleController with a logged in user
>> # stub logged in requirement
>> - should find user
>>
>> PeopleController with a logged in user who has an account
>> # stub account requirement
>> - should find account
>>
>> PeopleController with a logged in user who doesnt have an account
>> # stub no account requirement
>> - shouldn't find account
>> - should redirect ...
>>
>> PeopleController with a logged in user who has an account the person belongs to
>> # stub account owns person
>> - should find person
>> - should assign person for the view
>>
>> PeopleController with a logged in user who has an account the requested person does not belong to
>> # stub account doesn't own person
>> - should not find person
>> - should ...
>>
>> ------------------------------------------------------------------------------------------------------------------------
>>
>> I prefer the second group, but unfortunately I am not able to write my specs in this organized fashion.
>> Just sayin.
> 
> I appreciate the communication value you're looking for, and you can
> get it by stubbing everything you need to keep execution going
> before(:each) example and then set message expectations
> (should_receive) inside each example that help tell the story of that
> example.
> 
> PeopleController
> # stub everything way up here at the top where these
> # definitions are out of context (by means of position) with following examples
> #
> # stub controller requirments
> # stub logged in requirement
> # stub account requirement
> # stub no account requirement
> # stub account owns person
> # stub account doesn't own person
> 
> PeopleController with before filters
> - should require user
> 
> PeopleController with a logged in user
> # expect logged in query
> - should find user
> 
> PeopleController with a logged in user who has an account
> # expect logged in query
> # expect account query
> - should find account
> 
> etc
> 
> HTH,
> David

Yep, thats exactly what I've been practicing, and while its not exactly what I want, it does work nicely.
Thank you David

_________________________________________________________________
The i?m Talkaton. Can 30-days of conversation change the world?
http://www.imtalkathon.com/?source=EML_WLH_Talkathon_ChangeWorld

From cdemyanovich at gmail.com  Wed Jul  2 13:33:05 2008
From: cdemyanovich at gmail.com (Craig Demyanovich)
Date: Wed, 2 Jul 2008 13:33:05 -0400
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
	<443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
Message-ID: <61c885db0807021033g785716d8l16c463b594c0a078@mail.gmail.com>

My pair and I struggled with this a little bit last week. We decided
to just use a hash to represent cookies in specs, since that's how
we're interacting with it. You can see the specs that we wrote here:
http://pastie.org/226443 .

Regards,
Craig

From chris at cobaltedge.com  Wed Jul  2 13:42:24 2008
From: chris at cobaltedge.com (Christopher Bailey)
Date: Wed, 2 Jul 2008 10:42:24 -0700
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
	<443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
Message-ID: <443c240c0807021042k5a243dbapcce1e64c8089ea1@mail.gmail.com>

First, nevermind!  Oy!  I finally figured it out.  The reason it
wasn't working in my controller code was that I was checking for
"cookies[:cookie_key]", not "request.cookies[:cookie_key]"!  It's a
bit strange how that manifested, given the fact that referencing just
"cookies" was a hash with values, but alas, that's what was happening.

So, thank you very much for your time (that I essentially wasted :(

On Wed, Jul 2, 2008 at 9:57 AM, Christopher Bailey <chris at cobaltedge.com> wrote:
> On Wed, Jul 2, 2008 at 9:41 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
>> On Jul 2, 2008, at 11:15 AM, Christopher Bailey wrote:
>>
>>> On Wed, Jul 2, 2008 at 4:06 AM, David Chelimsky <dchelimsky at gmail.com>
>>> wrote:
>>> <snip>
>>>>
>>>> This is just one of those goofy things in Rails testing. I'm not sure
>>>> the best way to make it easier in rspec without breaking existing
>>>> examples in the process. Regardless, here's how you interact with
>>>> cookies from an example:
>>>>
>>>> To set a cookie:
>>>>
>>>> request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key', 'cookie
>>>> value')
>>>
>>> When I do this, in order to get to this cookie in my controller code,
>>> I have to do
>>>
>>>  cookies[:cookie_key][:cookie_key]
>>
>> Sorry Christopher - try this:
>>
>> request.cookies[:cookie_key] = 'cookie value'
>
> I tried that (see below in my email - I just mistakenly wrote it
> without the "request." at the beginning).  When I do this, it appears
> to set it, but then trying to retrieve it in my controller fails (even
> though the key is there, and the value is there, when then requesting
> cookies[:cookie_key] I get no value back).  Pretty weird.
>
>
>> Cheers,
>> David
>>
>>> Basically, it appears that what it does is assign that key a hash of
>>> its own.  That makes sense of course, as I realize a cookie is really
>>> a hash of name, value, path, expires, and so on.  However, it doesn't
>>> jive with the retrieval, as you shouldn't have to double reference it
>>> (which I believe is essentially the point of the [] method on
>>> ActionController::CookieJar and is not how things are documented).
>>>
>>> However, what's really behaving weird, is if I do:
>>>
>>>  cookies[:cookie_key] = "1234"
>>>
>>> Then, in my controller code, if I look at "cookies", it shows that
>>> cookies is a hash, and if I call .keys on it, it spits out
>>> ":cookie_key", and if I call .values on it, it says "1234", but if I
>>> then go and do cookies[:cookie_key], it gives me nil.
>>>
>>> Again, I have to suspect something weird going on with Rails test
>>> environment/RSpec, since all this works fine outside of tests.  Any
>>> suggestions on how to debug this further or what might be wrong?
>>>
>>> I should note I'm using Rails 2.1, and RSpec and rspec-rails from
>>> about a week ago (from GitHub).
>>>
>>>> To read a cookie
>>>>
>>>> response.cookies[:cookie_key].should == ["expected value"]
>>>>
>>>> or
>>>>
>>>> cookies[:cookie_key].should == ["expected value"]
>>>>
>>>> Rails provides a cookies object that is actually response.cookies, so
>>>> you don't *have* to reference it through the response object. I would,
>>>> however, as I've been known to try to set a cookie in an example using
>>>> cookies when I should have been using request.cookies. So I try to
>>>> keep them explicit.
>>>>
>>>> HTH,
>>>> David
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>
>>>
>>>
>>>
>>> --
>>> Christopher Bailey
>>> Cobalt Edge LLC
>>> http://cobaltedge.com
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Christopher Bailey
> Cobalt Edge LLC
> http://cobaltedge.com
>



-- 
Christopher Bailey
Cobalt Edge LLC
http://cobaltedge.com

From dchelimsky at gmail.com  Wed Jul  2 13:52:08 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 12:52:08 -0500
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <443c240c0807021042k5a243dbapcce1e64c8089ea1@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
	<443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
	<443c240c0807021042k5a243dbapcce1e64c8089ea1@mail.gmail.com>
Message-ID: <91498BAC-722B-4924-BF50-43CB0C61071C@gmail.com>

On Jul 2, 2008, at 12:42 PM, Christopher Bailey wrote:

> First, nevermind!  Oy!  I finally figured it out.  The reason it
> wasn't working in my controller code was that I was checking for
> "cookies[:cookie_key]", not "request.cookies[:cookie_key]"!  It's a
> bit strange how that manifested, given the fact that referencing just
> "cookies" was a hash with values, but alas, that's what was happening.

According to the rails API docs you shouldn't have to do that:

http://api.rubyonrails.org/classes/ActionController/Cookies.html

I figured out how to make this work. Here were the steps I took to get  
there and the solution:

   def some_action
     puts cookies.inspect, cookies[:cookie_key], cookies.class
   end

=> {:cookie_key=>"cookie value"}
=> nil
=> ActionController::CookieJar

So the object is not a Hash, it's a CookieJar, which acts as a proxy  
to a Hash. And guess what it does when it accesses the Hash?

   @cookies[name.to_s]

:)

So .........

This will actually work! I've proven it with an example that I've  
added to rspec-rails - http://github.com/dchelimsky/rspec-rails/tree/master/spec/rails/example/controller_spec_spec.rb 
  (look for "should support setting a cookie in the request"):

   request.cookies['cookie_key'] =  
CGI::Cookie.new('cookie_key','cookie value')

That will let you access the cookies as documented in the action.

I'm going to add some sort of support to rspec to make this a bit more  
user-friendly and less error prone. I'll follow up when I've done so.

Cheers,
David


>
>
> So, thank you very much for your time (that I essentially wasted :(
>
> On Wed, Jul 2, 2008 at 9:57 AM, Christopher Bailey <chris at cobaltedge.com 
> > wrote:
>> On Wed, Jul 2, 2008 at 9:41 AM, David Chelimsky  
>> <dchelimsky at gmail.com> wrote:
>>> On Jul 2, 2008, at 11:15 AM, Christopher Bailey wrote:
>>>
>>>> On Wed, Jul 2, 2008 at 4:06 AM, David Chelimsky <dchelimsky at gmail.com 
>>>> >
>>>> wrote:
>>>> <snip>
>>>>>
>>>>> This is just one of those goofy things in Rails testing. I'm not  
>>>>> sure
>>>>> the best way to make it easier in rspec without breaking existing
>>>>> examples in the process. Regardless, here's how you interact with
>>>>> cookies from an example:
>>>>>
>>>>> To set a cookie:
>>>>>
>>>>> request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key',  
>>>>> 'cookie
>>>>> value')
>>>>
>>>> When I do this, in order to get to this cookie in my controller  
>>>> code,
>>>> I have to do
>>>>
>>>> cookies[:cookie_key][:cookie_key]
>>>
>>> Sorry Christopher - try this:
>>>
>>> request.cookies[:cookie_key] = 'cookie value'
>>
>> I tried that (see below in my email - I just mistakenly wrote it
>> without the "request." at the beginning).  When I do this, it appears
>> to set it, but then trying to retrieve it in my controller fails  
>> (even
>> though the key is there, and the value is there, when then requesting
>> cookies[:cookie_key] I get no value back).  Pretty weird.
>>
>>
>>> Cheers,
>>> David
>>>
>>>> Basically, it appears that what it does is assign that key a hash  
>>>> of
>>>> its own.  That makes sense of course, as I realize a cookie is  
>>>> really
>>>> a hash of name, value, path, expires, and so on.  However, it  
>>>> doesn't
>>>> jive with the retrieval, as you shouldn't have to double  
>>>> reference it
>>>> (which I believe is essentially the point of the [] method on
>>>> ActionController::CookieJar and is not how things are documented).
>>>>
>>>> However, what's really behaving weird, is if I do:
>>>>
>>>> cookies[:cookie_key] = "1234"
>>>>
>>>> Then, in my controller code, if I look at "cookies", it shows that
>>>> cookies is a hash, and if I call .keys on it, it spits out
>>>> ":cookie_key", and if I call .values on it, it says "1234", but  
>>>> if I
>>>> then go and do cookies[:cookie_key], it gives me nil.
>>>>
>>>> Again, I have to suspect something weird going on with Rails test
>>>> environment/RSpec, since all this works fine outside of tests.  Any
>>>> suggestions on how to debug this further or what might be wrong?
>>>>
>>>> I should note I'm using Rails 2.1, and RSpec and rspec-rails from
>>>> about a week ago (from GitHub).
>>>>
>>>>> To read a cookie
>>>>>
>>>>> response.cookies[:cookie_key].should == ["expected value"]
>>>>>
>>>>> or
>>>>>
>>>>> cookies[:cookie_key].should == ["expected value"]
>>>>>
>>>>> Rails provides a cookies object that is actually  
>>>>> response.cookies, so
>>>>> you don't *have* to reference it through the response object. I  
>>>>> would,
>>>>> however, as I've been known to try to set a cookie in an example  
>>>>> using
>>>>> cookies when I should have been using request.cookies. So I try to
>>>>> keep them explicit.
>>>>>
>>>>> HTH,
>>>>> David
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Christopher Bailey
>>>> Cobalt Edge LLC
>>>> http://cobaltedge.com
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>> --
>> Christopher Bailey
>> Cobalt Edge LLC
>> http://cobaltedge.com
>>
>
>
>
> -- 
> Christopher Bailey
> Cobalt Edge LLC
> http://cobaltedge.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From chris at cobaltedge.com  Wed Jul  2 14:21:12 2008
From: chris at cobaltedge.com (Christopher Bailey)
Date: Wed, 2 Jul 2008 11:21:12 -0700
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <91498BAC-722B-4924-BF50-43CB0C61071C@gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
	<443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
	<443c240c0807021042k5a243dbapcce1e64c8089ea1@mail.gmail.com>
	<91498BAC-722B-4924-BF50-43CB0C61071C@gmail.com>
Message-ID: <443c240c0807021121m64669937i79961a8de044188f@mail.gmail.com>

On Wed, Jul 2, 2008 at 10:52 AM, David Chelimsky <dchelimsky at gmail.com> wrote:
> On Jul 2, 2008, at 12:42 PM, Christopher Bailey wrote:
>
>> First, nevermind!  Oy!  I finally figured it out.  The reason it
>> wasn't working in my controller code was that I was checking for
>> "cookies[:cookie_key]", not "request.cookies[:cookie_key]"!  It's a
>> bit strange how that manifested, given the fact that referencing just
>> "cookies" was a hash with values, but alas, that's what was happening.
>
> According to the rails API docs you shouldn't have to do that:
>
> http://api.rubyonrails.org/classes/ActionController/Cookies.html
>
> I figured out how to make this work. Here were the steps I took to get there
> and the solution:
>
>  def some_action
>    puts cookies.inspect, cookies[:cookie_key], cookies.class
>  end
>
> => {:cookie_key=>"cookie value"}
> => nil
> => ActionController::CookieJar
>
> So the object is not a Hash, it's a CookieJar, which acts as a proxy to a
> Hash. And guess what it does when it accesses the Hash?
>
>  @cookies[name.to_s]
>
> :)
>
> So .........
>
> This will actually work! I've proven it with an example that I've added to
> rspec-rails -
> http://github.com/dchelimsky/rspec-rails/tree/master/spec/rails/example/controller_spec_spec.rb (look
> for "should support setting a cookie in the request"):
>
>  request.cookies['cookie_key'] = CGI::Cookie.new('cookie_key','cookie
> value')
>
> That will let you access the cookies as documented in the action.
>
> I'm going to add some sort of support to rspec to make this a bit more
> user-friendly and less error prone. I'll follow up when I've done so.

And really, from my interpretation and experiments, if you look at
CookieJar, you can set the value by just passing a string, or a hash.
Passing an actual CGI::Cookie object you're sort of getting lucky due
to how CGI::Cookie.new happens to parse the "value" key/value pair in
the Hash that it gets sent by CookieJar.[]= method.  Unless I'm not
reading it right, what happens when you do:

  request.cookies['cookie_key'] = CGI::Cookie.new('cookie_key','cookie value')

is that in CookieJar.[]=, it will wind up doing:

  CGI::Cookie.new( { "name" => name.to_s, "value" =>
the_cookie_object_you_passed } )

If you try that in script/console for example, you'll find that
CGI::Cookie.new happens to parse the value (your cookie object
instance) properly and extract out the actual value.  But instead, you
can just simplify that all by simply doing:

  request.cookies['cookie_key'] = 'cookie value'

This seems like one of those cases where people were trying to be too
tricky with Ruby code, and mixing symbols and strings in unclear ways
and so on.


> Cheers,
> David
>
>
>>
>>
>> So, thank you very much for your time (that I essentially wasted :(
>>
>> On Wed, Jul 2, 2008 at 9:57 AM, Christopher Bailey <chris at cobaltedge.com>
>> wrote:
>>>
>>> On Wed, Jul 2, 2008 at 9:41 AM, David Chelimsky <dchelimsky at gmail.com>
>>> wrote:
>>>>
>>>> On Jul 2, 2008, at 11:15 AM, Christopher Bailey wrote:
>>>>
>>>>> On Wed, Jul 2, 2008 at 4:06 AM, David Chelimsky <dchelimsky at gmail.com>
>>>>> wrote:
>>>>> <snip>
>>>>>>
>>>>>> This is just one of those goofy things in Rails testing. I'm not sure
>>>>>> the best way to make it easier in rspec without breaking existing
>>>>>> examples in the process. Regardless, here's how you interact with
>>>>>> cookies from an example:
>>>>>>
>>>>>> To set a cookie:
>>>>>>
>>>>>> request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key', 'cookie
>>>>>> value')
>>>>>
>>>>> When I do this, in order to get to this cookie in my controller code,
>>>>> I have to do
>>>>>
>>>>> cookies[:cookie_key][:cookie_key]
>>>>
>>>> Sorry Christopher - try this:
>>>>
>>>> request.cookies[:cookie_key] = 'cookie value'
>>>
>>> I tried that (see below in my email - I just mistakenly wrote it
>>> without the "request." at the beginning).  When I do this, it appears
>>> to set it, but then trying to retrieve it in my controller fails (even
>>> though the key is there, and the value is there, when then requesting
>>> cookies[:cookie_key] I get no value back).  Pretty weird.
>>>
>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> Basically, it appears that what it does is assign that key a hash of
>>>>> its own.  That makes sense of course, as I realize a cookie is really
>>>>> a hash of name, value, path, expires, and so on.  However, it doesn't
>>>>> jive with the retrieval, as you shouldn't have to double reference it
>>>>> (which I believe is essentially the point of the [] method on
>>>>> ActionController::CookieJar and is not how things are documented).
>>>>>
>>>>> However, what's really behaving weird, is if I do:
>>>>>
>>>>> cookies[:cookie_key] = "1234"
>>>>>
>>>>> Then, in my controller code, if I look at "cookies", it shows that
>>>>> cookies is a hash, and if I call .keys on it, it spits out
>>>>> ":cookie_key", and if I call .values on it, it says "1234", but if I
>>>>> then go and do cookies[:cookie_key], it gives me nil.
>>>>>
>>>>> Again, I have to suspect something weird going on with Rails test
>>>>> environment/RSpec, since all this works fine outside of tests.  Any
>>>>> suggestions on how to debug this further or what might be wrong?
>>>>>
>>>>> I should note I'm using Rails 2.1, and RSpec and rspec-rails from
>>>>> about a week ago (from GitHub).
>>>>>
>>>>>> To read a cookie
>>>>>>
>>>>>> response.cookies[:cookie_key].should == ["expected value"]
>>>>>>
>>>>>> or
>>>>>>
>>>>>> cookies[:cookie_key].should == ["expected value"]
>>>>>>
>>>>>> Rails provides a cookies object that is actually response.cookies, so
>>>>>> you don't *have* to reference it through the response object. I would,
>>>>>> however, as I've been known to try to set a cookie in an example using
>>>>>> cookies when I should have been using request.cookies. So I try to
>>>>>> keep them explicit.
>>>>>>
>>>>>> HTH,
>>>>>> David
>>>>>> _______________________________________________
>>>>>> rspec-users mailing list
>>>>>> rspec-users at rubyforge.org
>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Christopher Bailey
>>>>> Cobalt Edge LLC
>>>>> http://cobaltedge.com
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Christopher Bailey
>>> Cobalt Edge LLC
>>> http://cobaltedge.com
>>>
>>
>>
>>
>> --
>> Christopher Bailey
>> Cobalt Edge LLC
>> http://cobaltedge.com
>> _______________________________________________
>> 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
>



-- 
Christopher Bailey
Cobalt Edge LLC
http://cobaltedge.com

From dchelimsky at gmail.com  Wed Jul  2 14:27:06 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 13:27:06 -0500
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <443c240c0807021121m64669937i79961a8de044188f@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
	<443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
	<443c240c0807021042k5a243dbapcce1e64c8089ea1@mail.gmail.com>
	<91498BAC-722B-4924-BF50-43CB0C61071C@gmail.com>
	<443c240c0807021121m64669937i79961a8de044188f@mail.gmail.com>
Message-ID: <08DD9E54-26E2-4052-8D71-8DFC83CDAF4E@gmail.com>


On Jul 2, 2008, at 1:21 PM, Christopher Bailey wrote:

> On Wed, Jul 2, 2008 at 10:52 AM, David Chelimsky  
> <dchelimsky at gmail.com> wrote:
>> On Jul 2, 2008, at 12:42 PM, Christopher Bailey wrote:
>>
>>> First, nevermind!  Oy!  I finally figured it out.  The reason it
>>> wasn't working in my controller code was that I was checking for
>>> "cookies[:cookie_key]", not "request.cookies[:cookie_key]"!  It's a
>>> bit strange how that manifested, given the fact that referencing  
>>> just
>>> "cookies" was a hash with values, but alas, that's what was  
>>> happening.
>>
>> According to the rails API docs you shouldn't have to do that:
>>
>> http://api.rubyonrails.org/classes/ActionController/Cookies.html
>>
>> I figured out how to make this work. Here were the steps I took to  
>> get there
>> and the solution:
>>
>> def some_action
>>   puts cookies.inspect, cookies[:cookie_key], cookies.class
>> end
>>
>> => {:cookie_key=>"cookie value"}
>> => nil
>> => ActionController::CookieJar
>>
>> So the object is not a Hash, it's a CookieJar, which acts as a  
>> proxy to a
>> Hash. And guess what it does when it accesses the Hash?
>>
>> @cookies[name.to_s]
>>
>> :)
>>
>> So .........
>>
>> This will actually work! I've proven it with an example that I've  
>> added to
>> rspec-rails -
>> http://github.com/dchelimsky/rspec-rails/tree/master/spec/rails/example/controller_spec_spec.rb 
>>  (look
>> for "should support setting a cookie in the request"):
>>
>> request.cookies['cookie_key'] = CGI::Cookie.new('cookie_key','cookie
>> value')
>>
>> That will let you access the cookies as documented in the action.
>>
>> I'm going to add some sort of support to rspec to make this a bit  
>> more
>> user-friendly and less error prone. I'll follow up when I've done so.
>
> And really, from my interpretation and experiments, if you look at
> CookieJar, you can set the value by just passing a string, or a hash.
> Passing an actual CGI::Cookie object you're sort of getting lucky due
> to how CGI::Cookie.new happens to parse the "value" key/value pair in
> the Hash that it gets sent by CookieJar.[]= method.  Unless I'm not
> reading it right, what happens when you do:
>
>  request.cookies['cookie_key'] =  
> CGI::Cookie.new('cookie_key','cookie value')
>
> is that in CookieJar.[]=, it will wind up doing:
>
>  CGI::Cookie.new( { "name" => name.to_s, "value" =>
> the_cookie_object_you_passed } )
>
> If you try that in script/console for example, you'll find that
> CGI::Cookie.new happens to parse the value (your cookie object
> instance) properly and extract out the actual value.  But instead, you
> can just simplify that all by simply doing:
>
>  request.cookies['cookie_key'] = 'cookie value'
>
> This seems like one of those cases where people were trying to be too
> tricky with Ruby code, and mixing symbols and strings in unclear ways
> and so on.

I'm thinking of replacing the existing cookies() method (in the  
example) with one that returns a CookieJarProxy that will allow you to  
do any of the following:

cookies['cookie_key'] = 'cookie value'
cookies[:cookie_key] = 'cookie value'

cookies['cookie_key'].should == 'cookie value'
cookies[:cookie_key].should == 'cookie value'

WDYT about that?


>
>
>
>> Cheers,
>> David
>>
>>
>>>
>>>
>>> So, thank you very much for your time (that I essentially wasted :(
>>>
>>> On Wed, Jul 2, 2008 at 9:57 AM, Christopher Bailey <chris at cobaltedge.com 
>>> >
>>> wrote:
>>>>
>>>> On Wed, Jul 2, 2008 at 9:41 AM, David Chelimsky <dchelimsky at gmail.com 
>>>> >
>>>> wrote:
>>>>>
>>>>> On Jul 2, 2008, at 11:15 AM, Christopher Bailey wrote:
>>>>>
>>>>>> On Wed, Jul 2, 2008 at 4:06 AM, David Chelimsky <dchelimsky at gmail.com 
>>>>>> >
>>>>>> wrote:
>>>>>> <snip>
>>>>>>>
>>>>>>> This is just one of those goofy things in Rails testing. I'm  
>>>>>>> not sure
>>>>>>> the best way to make it easier in rspec without breaking  
>>>>>>> existing
>>>>>>> examples in the process. Regardless, here's how you interact  
>>>>>>> with
>>>>>>> cookies from an example:
>>>>>>>
>>>>>>> To set a cookie:
>>>>>>>
>>>>>>> request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key',  
>>>>>>> 'cookie
>>>>>>> value')
>>>>>>
>>>>>> When I do this, in order to get to this cookie in my controller  
>>>>>> code,
>>>>>> I have to do
>>>>>>
>>>>>> cookies[:cookie_key][:cookie_key]
>>>>>
>>>>> Sorry Christopher - try this:
>>>>>
>>>>> request.cookies[:cookie_key] = 'cookie value'
>>>>
>>>> I tried that (see below in my email - I just mistakenly wrote it
>>>> without the "request." at the beginning).  When I do this, it  
>>>> appears
>>>> to set it, but then trying to retrieve it in my controller fails  
>>>> (even
>>>> though the key is there, and the value is there, when then  
>>>> requesting
>>>> cookies[:cookie_key] I get no value back).  Pretty weird.
>>>>
>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>> Basically, it appears that what it does is assign that key a  
>>>>>> hash of
>>>>>> its own.  That makes sense of course, as I realize a cookie is  
>>>>>> really
>>>>>> a hash of name, value, path, expires, and so on.  However, it  
>>>>>> doesn't
>>>>>> jive with the retrieval, as you shouldn't have to double  
>>>>>> reference it
>>>>>> (which I believe is essentially the point of the [] method on
>>>>>> ActionController::CookieJar and is not how things are  
>>>>>> documented).
>>>>>>
>>>>>> However, what's really behaving weird, is if I do:
>>>>>>
>>>>>> cookies[:cookie_key] = "1234"
>>>>>>
>>>>>> Then, in my controller code, if I look at "cookies", it shows  
>>>>>> that
>>>>>> cookies is a hash, and if I call .keys on it, it spits out
>>>>>> ":cookie_key", and if I call .values on it, it says "1234", but  
>>>>>> if I
>>>>>> then go and do cookies[:cookie_key], it gives me nil.
>>>>>>
>>>>>> Again, I have to suspect something weird going on with Rails test
>>>>>> environment/RSpec, since all this works fine outside of tests.   
>>>>>> Any
>>>>>> suggestions on how to debug this further or what might be wrong?
>>>>>>
>>>>>> I should note I'm using Rails 2.1, and RSpec and rspec-rails from
>>>>>> about a week ago (from GitHub).
>>>>>>
>>>>>>> To read a cookie
>>>>>>>
>>>>>>> response.cookies[:cookie_key].should == ["expected value"]
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> cookies[:cookie_key].should == ["expected value"]
>>>>>>>
>>>>>>> Rails provides a cookies object that is actually  
>>>>>>> response.cookies, so
>>>>>>> you don't *have* to reference it through the response object.  
>>>>>>> I would,
>>>>>>> however, as I've been known to try to set a cookie in an  
>>>>>>> example using
>>>>>>> cookies when I should have been using request.cookies. So I  
>>>>>>> try to
>>>>>>> keep them explicit.
>>>>>>>
>>>>>>> HTH,
>>>>>>> David
>>>>>>> _______________________________________________
>>>>>>> rspec-users mailing list
>>>>>>> rspec-users at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Christopher Bailey
>>>>>> Cobalt Edge LLC
>>>>>> http://cobaltedge.com
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Christopher Bailey
>>>> Cobalt Edge LLC
>>>> http://cobaltedge.com
>>>>
>>>
>>>
>>>
>>> --
>>> Christopher Bailey
>>> Cobalt Edge LLC
>>> http://cobaltedge.com
>>> _______________________________________________
>>> 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
>>
>
>
>
> -- 
> Christopher Bailey
> Cobalt Edge LLC
> http://cobaltedge.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From dchelimsky at gmail.com  Wed Jul  2 14:37:19 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 13:37:19 -0500
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <443c240c0807021121m64669937i79961a8de044188f@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
	<443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
	<443c240c0807021042k5a243dbapcce1e64c8089ea1@mail.gmail.com>
	<91498BAC-722B-4924-BF50-43CB0C61071C@gmail.com>
	<443c240c0807021121m64669937i79961a8de044188f@mail.gmail.com>
Message-ID: <21C595CB-5516-4F52-A48F-D8B3B8C25BDC@gmail.com>


On Jul 2, 2008, at 1:21 PM, Christopher Bailey wrote:

> On Wed, Jul 2, 2008 at 10:52 AM, David Chelimsky  
> <dchelimsky at gmail.com> wrote:
>> On Jul 2, 2008, at 12:42 PM, Christopher Bailey wrote:
>>
>>> First, nevermind!  Oy!  I finally figured it out.  The reason it
>>> wasn't working in my controller code was that I was checking for
>>> "cookies[:cookie_key]", not "request.cookies[:cookie_key]"!  It's a
>>> bit strange how that manifested, given the fact that referencing  
>>> just
>>> "cookies" was a hash with values, but alas, that's what was  
>>> happening.
>>
>> According to the rails API docs you shouldn't have to do that:
>>
>> http://api.rubyonrails.org/classes/ActionController/Cookies.html
>>
>> I figured out how to make this work. Here were the steps I took to  
>> get there
>> and the solution:
>>
>> def some_action
>>   puts cookies.inspect, cookies[:cookie_key], cookies.class
>> end
>>
>> => {:cookie_key=>"cookie value"}
>> => nil
>> => ActionController::CookieJar
>>
>> So the object is not a Hash, it's a CookieJar, which acts as a  
>> proxy to a
>> Hash. And guess what it does when it accesses the Hash?
>>
>> @cookies[name.to_s]
>>
>> :)
>>
>> So .........
>>
>> This will actually work! I've proven it with an example that I've  
>> added to
>> rspec-rails -
>> http://github.com/dchelimsky/rspec-rails/tree/master/spec/rails/example/controller_spec_spec.rb 
>>  (look
>> for "should support setting a cookie in the request"):
>>
>> request.cookies['cookie_key'] = CGI::Cookie.new('cookie_key','cookie
>> value')
>>
>> That will let you access the cookies as documented in the action.
>>
>> I'm going to add some sort of support to rspec to make this a bit  
>> more
>> user-friendly and less error prone. I'll follow up when I've done so.
>
> And really, from my interpretation and experiments, if you look at
> CookieJar, you can set the value by just passing a string, or a hash.
> Passing an actual CGI::Cookie object you're sort of getting lucky due
> to how CGI::Cookie.new happens to parse the "value" key/value pair in
> the Hash that it gets sent by CookieJar.[]= method.  Unless I'm not
> reading it right, what happens when you do:
>
>  request.cookies['cookie_key'] =  
> CGI::Cookie.new('cookie_key','cookie value')
>
> is that in CookieJar.[]=, it will wind up doing:
>
>  CGI::Cookie.new( { "name" => name.to_s, "value" =>
> the_cookie_object_you_passed } )
>
> If you try that in script/console for example, you'll find that
> CGI::Cookie.new happens to parse the value (your cookie object
> instance) properly and extract out the actual value.  But instead, you
> can just simplify that all by simply doing:
>
>  request.cookies['cookie_key'] = 'cookie value'

This doesn't work for me unless I reference request.cookies in the  
controller, which I shouldn't have to do according to the rails docs.  
So for the moment, I'm sticking with:

   request.cookies['cookie_key'] = CGI::Cookie.new('cookie_key',  
'cookie value')

> This seems like one of those cases where people were trying to be too
> tricky with Ruby code, and mixing symbols and strings in unclear ways
> and so on.

Totally agree.

>>> So, thank you very much for your time (that I essentially wasted :(

This is NOT at all a waste of time.

Cheers,
David

>>>
>>>
>>> On Wed, Jul 2, 2008 at 9:57 AM, Christopher Bailey <chris at cobaltedge.com 
>>> >
>>> wrote:
>>>>
>>>> On Wed, Jul 2, 2008 at 9:41 AM, David Chelimsky <dchelimsky at gmail.com 
>>>> >
>>>> wrote:
>>>>>
>>>>> On Jul 2, 2008, at 11:15 AM, Christopher Bailey wrote:
>>>>>
>>>>>> On Wed, Jul 2, 2008 at 4:06 AM, David Chelimsky <dchelimsky at gmail.com 
>>>>>> >
>>>>>> wrote:
>>>>>> <snip>
>>>>>>>
>>>>>>> This is just one of those goofy things in Rails testing. I'm  
>>>>>>> not sure
>>>>>>> the best way to make it easier in rspec without breaking  
>>>>>>> existing
>>>>>>> examples in the process. Regardless, here's how you interact  
>>>>>>> with
>>>>>>> cookies from an example:
>>>>>>>
>>>>>>> To set a cookie:
>>>>>>>
>>>>>>> request.cookies[:cookie_key] = CGI::Cookie.new('cookie_key',  
>>>>>>> 'cookie
>>>>>>> value')
>>>>>>
>>>>>> When I do this, in order to get to this cookie in my controller  
>>>>>> code,
>>>>>> I have to do
>>>>>>
>>>>>> cookies[:cookie_key][:cookie_key]
>>>>>
>>>>> Sorry Christopher - try this:
>>>>>
>>>>> request.cookies[:cookie_key] = 'cookie value'
>>>>
>>>> I tried that (see below in my email - I just mistakenly wrote it
>>>> without the "request." at the beginning).  When I do this, it  
>>>> appears
>>>> to set it, but then trying to retrieve it in my controller fails  
>>>> (even
>>>> though the key is there, and the value is there, when then  
>>>> requesting
>>>> cookies[:cookie_key] I get no value back).  Pretty weird.
>>>>
>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>> Basically, it appears that what it does is assign that key a  
>>>>>> hash of
>>>>>> its own.  That makes sense of course, as I realize a cookie is  
>>>>>> really
>>>>>> a hash of name, value, path, expires, and so on.  However, it  
>>>>>> doesn't
>>>>>> jive with the retrieval, as you shouldn't have to double  
>>>>>> reference it
>>>>>> (which I believe is essentially the point of the [] method on
>>>>>> ActionController::CookieJar and is not how things are  
>>>>>> documented).
>>>>>>
>>>>>> However, what's really behaving weird, is if I do:
>>>>>>
>>>>>> cookies[:cookie_key] = "1234"
>>>>>>
>>>>>> Then, in my controller code, if I look at "cookies", it shows  
>>>>>> that
>>>>>> cookies is a hash, and if I call .keys on it, it spits out
>>>>>> ":cookie_key", and if I call .values on it, it says "1234", but  
>>>>>> if I
>>>>>> then go and do cookies[:cookie_key], it gives me nil.
>>>>>>
>>>>>> Again, I have to suspect something weird going on with Rails test
>>>>>> environment/RSpec, since all this works fine outside of tests.   
>>>>>> Any
>>>>>> suggestions on how to debug this further or what might be wrong?
>>>>>>
>>>>>> I should note I'm using Rails 2.1, and RSpec and rspec-rails from
>>>>>> about a week ago (from GitHub).
>>>>>>
>>>>>>> To read a cookie
>>>>>>>
>>>>>>> response.cookies[:cookie_key].should == ["expected value"]
>>>>>>>
>>>>>>> or
>>>>>>>
>>>>>>> cookies[:cookie_key].should == ["expected value"]
>>>>>>>
>>>>>>> Rails provides a cookies object that is actually  
>>>>>>> response.cookies, so
>>>>>>> you don't *have* to reference it through the response object.  
>>>>>>> I would,
>>>>>>> however, as I've been known to try to set a cookie in an  
>>>>>>> example using
>>>>>>> cookies when I should have been using request.cookies. So I  
>>>>>>> try to
>>>>>>> keep them explicit.
>>>>>>>
>>>>>>> HTH,
>>>>>>> David
>>>>>>> _______________________________________________
>>>>>>> rspec-users mailing list
>>>>>>> rspec-users at rubyforge.org
>>>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Christopher Bailey
>>>>>> Cobalt Edge LLC
>>>>>> http://cobaltedge.com
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Christopher Bailey
>>>> Cobalt Edge LLC
>>>> http://cobaltedge.com
>>>>
>>>
>>>
>>>
>>> --
>>> Christopher Bailey
>>> Cobalt Edge LLC
>>> http://cobaltedge.com
>>> _______________________________________________
>>> 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
>>
>
>
>
> -- 
> Christopher Bailey
> Cobalt Edge LLC
> http://cobaltedge.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From cdemyanovich at gmail.com  Wed Jul  2 14:44:01 2008
From: cdemyanovich at gmail.com (Craig Demyanovich)
Date: Wed, 2 Jul 2008 14:44:01 -0400
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <08DD9E54-26E2-4052-8D71-8DFC83CDAF4E@gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
	<443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
	<443c240c0807021042k5a243dbapcce1e64c8089ea1@mail.gmail.com>
	<91498BAC-722B-4924-BF50-43CB0C61071C@gmail.com>
	<443c240c0807021121m64669937i79961a8de044188f@mail.gmail.com>
	<08DD9E54-26E2-4052-8D71-8DFC83CDAF4E@gmail.com>
Message-ID: <61c885db0807021144w47ec4accid4d176f9eb35a56b@mail.gmail.com>

> I'm thinking of replacing the existing cookies() method (in the example)
> with one that returns a CookieJarProxy that will allow you to do any of the
> following:
>
> cookies['cookie_key'] = 'cookie value'
> cookies[:cookie_key] = 'cookie value'
>
> cookies['cookie_key'].should == 'cookie value'
> cookies[:cookie_key].should == 'cookie value'
>
> WDYT about that?

David, do you plan to allow checks that other values are set as we'd
expect? Other values include:

* :value
* :path
* :domain
* :expires
* :secure
* :http_only

http://www.railsbrain.com/api/rails-2.1.0/doc/index.html?a=M000352&name=cookies

For example, I'd like to verify that I update the value and expiration date:

it "resets the cookie with the value and new expiration date" do
  get_index
  cookies[:project_sort][:value].should == "name"
  cookies[:project_sort][:expires].beginning_of_day.should ==
1.year.from_now.beginning_of_day
end

Thanks,
Craig

From dchelimsky at gmail.com  Wed Jul  2 14:45:13 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 13:45:13 -0500
Subject: [rspec-users] Cookies - how to set in controller specs?
In-Reply-To: <61c885db0807021144w47ec4accid4d176f9eb35a56b@mail.gmail.com>
References: <443c240c0807011637i61a2764bl3dfe460e3ae8745a@mail.gmail.com>
	<57c63afe0807020406s5ef2209em34d32dffc5d6dbb0@mail.gmail.com>
	<443c240c0807020915h1ba1817nd8c6b7286d04600e@mail.gmail.com>
	<A90002F8-0E8C-4337-9F93-7E66EB711549@gmail.com>
	<443c240c0807020957y47bfa81ds35423ee533cb8de6@mail.gmail.com>
	<443c240c0807021042k5a243dbapcce1e64c8089ea1@mail.gmail.com>
	<91498BAC-722B-4924-BF50-43CB0C61071C@gmail.com>
	<443c240c0807021121m64669937i79961a8de044188f@mail.gmail.com>
	<08DD9E54-26E2-4052-8D71-8DFC83CDAF4E@gmail.com>
	<61c885db0807021144w47ec4accid4d176f9eb35a56b@mail.gmail.com>
Message-ID: <91E5FC73-62E4-49C1-9FB9-DCEA9FF5151C@gmail.com>

On Jul 2, 2008, at 1:44 PM, Craig Demyanovich wrote:

>> I'm thinking of replacing the existing cookies() method (in the  
>> example)
>> with one that returns a CookieJarProxy that will allow you to do  
>> any of the
>> following:
>>
>> cookies['cookie_key'] = 'cookie value'
>> cookies[:cookie_key] = 'cookie value'
>>
>> cookies['cookie_key'].should == 'cookie value'
>> cookies[:cookie_key].should == 'cookie value'
>>
>> WDYT about that?
>
> David, do you plan to allow checks that other values are set as we'd
> expect? Other values include:
>
> * :value
> * :path
> * :domain
> * :expires
> * :secure
> * :http_only
>
> http://www.railsbrain.com/api/rails-2.1.0/doc/index.html?a=M000352&name=cookies
>
> For example, I'd like to verify that I update the value and  
> expiration date:
>
> it "resets the cookie with the value and new expiration date" do
>  get_index
>  cookies[:project_sort][:value].should == "name"
>  cookies[:project_sort][:expires].beginning_of_day.should ==
> 1.year.from_now.beginning_of_day

I had not planned that, no :)

Let me get the basics working first and we can talk about beefing it  
up like this later.

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


From jimfreeze at gmail.com  Wed Jul  2 15:53:11 2008
From: jimfreeze at gmail.com (Jim Freeze)
Date: Wed, 2 Jul 2008 14:53:11 -0500
Subject: [rspec-users] [ANN] Lone Star Ruby Conference 2008 - Registration
	Now Open
Message-ID: <5cd596d60807021253u3775bf75vdfaf242d6e5ad384@mail.gmail.com>

(Pardon the interruption)

Greetings

The Lone Star Ruby Conference, held in Austin, TX on September 4-6,

    is NOW OPEN for registration.

This year we have an amazing line-up of speakers, in addition to Matz,
the author
of Ruby. We have even added a second track to give you more choices of
talks to attend.

Also, there is a full day of training on Thursday, Sept 4, where you can
sign up for some of the best Ruby training around.

Check out the website for details http://LoneStarRubyConf.com and be
sure to sign
up early before all the seats are gone.

--
Jim Freeze
Lone Star Ruby Conference
http://LoneStarRubyConf.com

From srogers1 at gmail.com  Wed Jul  2 17:52:40 2008
From: srogers1 at gmail.com (Steve Rogers)
Date: Wed, 2 Jul 2008 16:52:40 -0500
Subject: [rspec-users] View spec issue
Message-ID: <62579436-FEBE-44D5-8B02-1533FA9517BF@gmail.com>

I've been having some view spec issues, and I think I finally traced  
it to ground - it seems like setting a value in assigns like:

   assigns[:foo] = "baz"

doesn't get used to build the path prefix for a route like:

   map.resources :widgets , :path_prefix => ':foo'

To test it out, I created an empty rails project, rspec-generated a  
controller/model/specs and all the tests worked. I then added a path  
prefix and modified the code and specs - everything works except for  
the view specs. There just doesn't seem to be a way to make it happy  
about any named route in a view. A route like:

< %= link_to 'New widget', new_widget_path %>

gets an error like:

ActionView::TemplateError in '/widgets/index.html.erb should render  
list of widgets'
new_widget_url failed to generate from  
{:controller=>"widgets", :action=>"new"} - you may have ambiguous  
routes, or you may need to supply additional parameters for this  
route.  content_url has the following required parameters: [:foo,  
"widgets", "new"] - are they all satisfied?

Anyone else seeing something like that?  I'm using the head version of  
rspec/rspec-rails from github and Rails 2.1

SR

From ml at e4net.com  Wed Jul  2 20:12:43 2008
From: ml at e4net.com (Jim Morris)
Date: Wed, 02 Jul 2008 17:12:43 -0700
Subject: [rspec-users] unable to access flash from rails helper spec since
	upgrade to 1.1.4
Message-ID: <486C197B.2000307@e4net.com>

Hi,

Many moons ago I wrote this blog entry...

http://blog.wolfman.com/articles/2007/07/14/using-rspec-to-test-haml-helpers

I just upgraded that rails project to use rspec 1.1.4 and associated rspec_rails.

It seems that my helper when called from the helper specs no longer are able to access flash, 
controller etc as they did before.

I already prepended all helper calls with helper. so I fixed those changes, but I have been unable 
to figure out how to access flash etc...

Here is a simplified example...

in ApplicationHelper.rb

  def test_flash
     for name in [:notice, :warning, :error]
       if flash[name]
         return "#{flash[name]}"
       end
     end
     nil
   end

In my rails/spec/helpers/application_helper_spec.rb

require File.dirname(__FILE__) + '/../spec_helper'

describe ApplicationHelper do

   it "should test flash" do
     for name in [:notice, :warning, :error]
       flash[name]= "flash #{name.to_s} message"
       helper.test_flash.should match(/.*#{name}.*/)
       flash[name]= nil
     end
   end

end

I get this error trace...
1)
NoMethodError in 'ApplicationHelper should test flash'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occurred while evaluating nil.[]
/.../app/helpers/application_helper.rb:23:in `test_flash'
...

flash is nil, this used to work, so what is the new magic incantation to get this to work again?

Thanks


-- 
Jim Morris, http://blog.wolfman.com

From mileshosky at hotmail.com  Wed Jul  2 22:58:00 2008
From: mileshosky at hotmail.com (Britt Mileshosky)
Date: Wed, 2 Jul 2008 19:58:00 -0700
Subject: [rspec-users] Stopping Example Execution?
In-Reply-To: <BLU146-W199A415EA35CCF5816862AD7990@phx.gbl>
References: <BLU146-W4326878715F7908584B6EBD79F0@phx.gbl>
	<57c63afe0807020415m9df6bdfmfed02ba908746e00@mail.gmail.com> 
	<BLU146-W199A415EA35CCF5816862AD7990@phx.gbl>
Message-ID: <BLU146-W32C34F2A42176C71C4216CD7980@phx.gbl>



----------------------------------------
> From: mileshosky at hotmail.com
> To: rspec-users at rubyforge.org
> Date: Wed, 2 Jul 2008 10:13:59 -0700
> Subject: Re: [rspec-users] Stopping Example Execution?
> 
> 
> 
> ----------------------------------------
>> Date: Wed, 2 Jul 2008 06:15:10 -0500
>> From: dchelimsky at gmail.com
>> To: rspec-users at rubyforge.org
>> Subject: Re: [rspec-users] Stopping Example Execution?
>> 
>> On Mon, Jun 30, 2008 at 5:11 PM, Britt Mileshosky
>>  wrote:
>>>
>>> n Sun, Jun 29, 2008 at 12:20 PM, David Chelimsky wrote:
>>> On Jun 29, 2008, at 11:18 AM, Britt Mileshosky wrote:
>>>
>>> However, do you see where something like a return statement or end example statement could be beneficial?
>>> If you are working from the top down with your controller action execution, then you only need to test your expectation
>>> and then bail out of your action. No need to further test or meet requirements on anything else in that action because your
>>> single test has been met.
>>>
>>> - in my example for making sure I find a user, I'd like to end execution once I DID find the user, i shouldn't have to satisfy
>>> requirements about finding an account and a person... I'll write those expectations later in another nested describe group, as you
>>> can see here, in a top down process
>>>
>>> PeopleController with a logged in user
>>> - should find user
>>>
>>> PeopleController with a logged in user who has an account
>>> - should find account
>>>
>>> PeopleController with a logged in user who doesnt have an account
>>> - shouldn't find account
>>> - should redirect ...
>>>
>>> PeopleController with a logged in user who has an account the person belongs to
>>> - should find person
>>> - should assign person for the view
>>>
>>> PeopleController with a logged in user who has an account the requested person does not belong to
>>> - should not find person
>>> - should ...
>>>
>>> My instinct about this is that it would encourage long methods because it would make it less painful to test them, so I would be adverse to anything that let's you short circuit the method.
>>>
>>> Anybody else have opinions on that?
>>>
>>>
>>>
>>> I'm just catching up on email now after being sick for the past six days, but health aside my opinion is that I agree with David's opinion. Rather than focusing on how-to write easier tests that complain less, start focusing on how-to write the right tests that complain when necessary.
>>>
>>> One of the benefits associated with feeling the pain of a test is that it may be a sign to re-assess and refactor your code. This usually happens early enough that it only takes a few minutes. Short circuiting essentially gives you the ability to not feel the pain. Its like CIPA [0], but for code. I would fear that the code would get so bad that by the time the test cried with pain your code was already beyond easy repair and instead required invasive surgery.
>>>
>>> Tests are part of the nervous system of your application. When they hurt, they're telling you something isn't right and that it should be addressed,
>>>
>>>
>>>
>>> I wouldn't really say that anything I have been presenting has been a result of 'pains',
>>> more so an observation on how an example group with other example groups can be much more readable
>>> for myself and for other developers when they need to read the specs. Stubbing everything at the top doesn't
>>> make complete sense. Why not stub inside the example group that has a NICE describe statement telling you
>>> what this stubbing is related to. We can't do this because the first examples will blow up due to having to execute
>>> all the code.
>>>
>>> Take the 2 examples:
>>>
>>> ------------------------------------------------------------------------------------------------------------------------
>>> PeopleController
>>> # stub everything way up here at the top where these
>>> # definitions are out of context (by means of position) with following examples
>>> #
>>> # stub controller requirments
>>> # stub logged in requirement
>>> # stub account requirement
>>> # stub no account requirement
>>> # stub account owns person
>>> # stub account doesn't own person
>>>
>>>
>>> PeopleController with before filters
>>> - should require user
>>>
>>> PeopleController with a logged in user
>>> - should find user
>>>
>>> PeopleController with a logged in user who has an account
>>> - should find account
>>>
>>> PeopleController with a logged in user who doesnt have an account
>>> - shouldn't find account
>>> - should redirect ...
>>>
>>> PeopleController with a logged in user who has an account the person belongs to
>>> - should find person
>>> - should assign person for the view
>>>
>>> PeopleController with a logged in user who has an account the requested person does not belong to
>>> - should not find person
>>> - should ...
>>>
>>> ------------------------------------------------------------------------------------------------------------------------
>>> PeopleController
>>> # stub the minimum needed to get to the first example group up and running
>>>
>>> PeopleController with before filters
>>> - should require user
>>>
>>> PeopleController with a logged in user
>>> # stub logged in requirement
>>> - should find user
>>>
>>> PeopleController with a logged in user who has an account
>>> # stub account requirement
>>> - should find account
>>>
>>> PeopleController with a logged in user who doesnt have an account
>>> # stub no account requirement
>>> - shouldn't find account
>>> - should redirect ...
>>>
>>> PeopleController with a logged in user who has an account the person belongs to
>>> # stub account owns person
>>> - should find person
>>> - should assign person for the view
>>>
>>> PeopleController with a logged in user who has an account the requested person does not belong to
>>> # stub account doesn't own person
>>> - should not find person
>>> - should ...
>>>
>>> ------------------------------------------------------------------------------------------------------------------------
>>>
>>> I prefer the second group, but unfortunately I am not able to write my specs in this organized fashion.
>>> Just sayin.
>> 
>> I appreciate the communication value you're looking for, and you can
>> get it by stubbing everything you need to keep execution going
>> before(:each) example and then set message expectations
>> (should_receive) inside each example that help tell the story of that
>> example.
>> 
>> PeopleController
>> # stub everything way up here at the top where these
>> # definitions are out of context (by means of position) with following examples
>> #
>> # stub controller requirments
>> # stub logged in requirement
>> # stub account requirement
>> # stub no account requirement
>> # stub account owns person
>> # stub account doesn't own person
>> 
>> PeopleController with before filters
>> - should require user
>> 
>> PeopleController with a logged in user
>> # expect logged in query
>> - should find user
>> 
>> PeopleController with a logged in user who has an account
>> # expect logged in query
>> # expect account query
>> - should find account
>> 
>> etc
>> 
>> HTH,
>> David
> 
> Yep, thats exactly what I've been practicing, and while its not exactly what I want, it does work nicely.
> Thank you David


I'm gonna make another REALLY strong case for allowing the ability to stop example execution and test code incrementally. I currently have over  1700 examples for the current application I'm working on, and one little line of code that I added in my App controller ( before_filter :set_location ) brought on almost 1100 errors across my tests.  Now I know people will say that the requirements weren't understood at the beginning of the application and that it could have been avoided with better planning... but this isn't the case.

I now have to go into each of my controller tests and add the stub into every before declaration to clear up my errors.  Not fun, and could've been avoided completely.

Britt

_________________________________________________________________
Enter the Zune-A-Day Giveaway for your chance to win ? day after day after day
http://www.windowslive-hotmail.com/ZuneADay/?locale=en-US&ocid=TXT_TAGLM_Mobile_Zune_V1

From dchelimsky at gmail.com  Wed Jul  2 23:19:07 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 22:19:07 -0500
Subject: [rspec-users] Stopping Example Execution?
In-Reply-To: <BLU146-W32C34F2A42176C71C4216CD7980@phx.gbl>
References: <BLU146-W4326878715F7908584B6EBD79F0@phx.gbl>
	<57c63afe0807020415m9df6bdfmfed02ba908746e00@mail.gmail.com>
	<BLU146-W199A415EA35CCF5816862AD7990@phx.gbl>
	<BLU146-W32C34F2A42176C71C4216CD7980@phx.gbl>
Message-ID: <1D58DB37-395B-4D4B-9C0C-DA5D604957AA@gmail.com>

On Jul 2, 2008, at 9:58 PM, Britt Mileshosky wrote:

> ----------------------------------------
>> From: mileshosky at hotmail.com
>> To: rspec-users at rubyforge.org
>> Date: Wed, 2 Jul 2008 10:13:59 -0700
>> Subject: Re: [rspec-users] Stopping Example Execution?
>>
>>
>>
>> ----------------------------------------
>>> Date: Wed, 2 Jul 2008 06:15:10 -0500
>>> From: dchelimsky at gmail.com
>>> To: rspec-users at rubyforge.org
>>> Subject: Re: [rspec-users] Stopping Example Execution?
>>>
>>> On Mon, Jun 30, 2008 at 5:11 PM, Britt Mileshosky
>>> wrote:
>>>>
>>>> n Sun, Jun 29, 2008 at 12:20 PM, David Chelimsky wrote:
>>>> On Jun 29, 2008, at 11:18 AM, Britt Mileshosky wrote:
>>>>
>>>> However, do you see where something like a return statement or  
>>>> end example statement could be beneficial?
>>>> If you are working from the top down with your controller action  
>>>> execution, then you only need to test your expectation
>>>> and then bail out of your action. No need to further test or meet  
>>>> requirements on anything else in that action because your
>>>> single test has been met.
>>>>
>>>> - in my example for making sure I find a user, I'd like to end  
>>>> execution once I DID find the user, i shouldn't have to satisfy
>>>> requirements about finding an account and a person... I'll write  
>>>> those expectations later in another nested describe group, as you
>>>> can see here, in a top down process
>>>>
>>>> PeopleController with a logged in user
>>>> - should find user
>>>>
>>>> PeopleController with a logged in user who has an account
>>>> - should find account
>>>>
>>>> PeopleController with a logged in user who doesnt have an account
>>>> - shouldn't find account
>>>> - should redirect ...
>>>>
>>>> PeopleController with a logged in user who has an account the  
>>>> person belongs to
>>>> - should find person
>>>> - should assign person for the view
>>>>
>>>> PeopleController with a logged in user who has an account the  
>>>> requested person does not belong to
>>>> - should not find person
>>>> - should ...
>>>>
>>>> My instinct about this is that it would encourage long methods  
>>>> because it would make it less painful to test them, so I would be  
>>>> adverse to anything that let's you short circuit the method.
>>>>
>>>> Anybody else have opinions on that?
>>>>
>>>>
>>>>
>>>> I'm just catching up on email now after being sick for the past  
>>>> six days, but health aside my opinion is that I agree with  
>>>> David's opinion. Rather than focusing on how-to write easier  
>>>> tests that complain less, start focusing on how-to write the  
>>>> right tests that complain when necessary.
>>>>
>>>> One of the benefits associated with feeling the pain of a test is  
>>>> that it may be a sign to re-assess and refactor your code. This  
>>>> usually happens early enough that it only takes a few minutes.  
>>>> Short circuiting essentially gives you the ability to not feel  
>>>> the pain. Its like CIPA [0], but for code. I would fear that the  
>>>> code would get so bad that by the time the test cried with pain  
>>>> your code was already beyond easy repair and instead required  
>>>> invasive surgery.
>>>>
>>>> Tests are part of the nervous system of your application. When  
>>>> they hurt, they're telling you something isn't right and that it  
>>>> should be addressed,
>>>>
>>>>
>>>>
>>>> I wouldn't really say that anything I have been presenting has  
>>>> been a result of 'pains',
>>>> more so an observation on how an example group with other example  
>>>> groups can be much more readable
>>>> for myself and for other developers when they need to read the  
>>>> specs. Stubbing everything at the top doesn't
>>>> make complete sense. Why not stub inside the example group that  
>>>> has a NICE describe statement telling you
>>>> what this stubbing is related to. We can't do this because the  
>>>> first examples will blow up due to having to execute
>>>> all the code.
>>>>
>>>> Take the 2 examples:
>>>>
>>>> ------------------------------------------------------------------------------------------------------------------------
>>>> PeopleController
>>>> # stub everything way up here at the top where these
>>>> # definitions are out of context (by means of position) with  
>>>> following examples
>>>> #
>>>> # stub controller requirments
>>>> # stub logged in requirement
>>>> # stub account requirement
>>>> # stub no account requirement
>>>> # stub account owns person
>>>> # stub account doesn't own person
>>>>
>>>>
>>>> PeopleController with before filters
>>>> - should require user
>>>>
>>>> PeopleController with a logged in user
>>>> - should find user
>>>>
>>>> PeopleController with a logged in user who has an account
>>>> - should find account
>>>>
>>>> PeopleController with a logged in user who doesnt have an account
>>>> - shouldn't find account
>>>> - should redirect ...
>>>>
>>>> PeopleController with a logged in user who has an account the  
>>>> person belongs to
>>>> - should find person
>>>> - should assign person for the view
>>>>
>>>> PeopleController with a logged in user who has an account the  
>>>> requested person does not belong to
>>>> - should not find person
>>>> - should ...
>>>>
>>>> ------------------------------------------------------------------------------------------------------------------------
>>>> PeopleController
>>>> # stub the minimum needed to get to the first example group up  
>>>> and running
>>>>
>>>> PeopleController with before filters
>>>> - should require user
>>>>
>>>> PeopleController with a logged in user
>>>> # stub logged in requirement
>>>> - should find user
>>>>
>>>> PeopleController with a logged in user who has an account
>>>> # stub account requirement
>>>> - should find account
>>>>
>>>> PeopleController with a logged in user who doesnt have an account
>>>> # stub no account requirement
>>>> - shouldn't find account
>>>> - should redirect ...
>>>>
>>>> PeopleController with a logged in user who has an account the  
>>>> person belongs to
>>>> # stub account owns person
>>>> - should find person
>>>> - should assign person for the view
>>>>
>>>> PeopleController with a logged in user who has an account the  
>>>> requested person does not belong to
>>>> # stub account doesn't own person
>>>> - should not find person
>>>> - should ...
>>>>
>>>> ------------------------------------------------------------------------------------------------------------------------
>>>>
>>>> I prefer the second group, but unfortunately I am not able to  
>>>> write my specs in this organized fashion.
>>>> Just sayin.
>>>
>>> I appreciate the communication value you're looking for, and you can
>>> get it by stubbing everything you need to keep execution going
>>> before(:each) example and then set message expectations
>>> (should_receive) inside each example that help tell the story of  
>>> that
>>> example.
>>>
>>> PeopleController
>>> # stub everything way up here at the top where these
>>> # definitions are out of context (by means of position) with  
>>> following examples
>>> #
>>> # stub controller requirments
>>> # stub logged in requirement
>>> # stub account requirement
>>> # stub no account requirement
>>> # stub account owns person
>>> # stub account doesn't own person
>>>
>>> PeopleController with before filters
>>> - should require user
>>>
>>> PeopleController with a logged in user
>>> # expect logged in query
>>> - should find user
>>>
>>> PeopleController with a logged in user who has an account
>>> # expect logged in query
>>> # expect account query
>>> - should find account
>>>
>>> etc
>>>
>>> HTH,
>>> David
>>
>> Yep, thats exactly what I've been practicing, and while its not  
>> exactly what I want, it does work nicely.
>> Thank you David
>
>
> I'm gonna make another REALLY strong case for allowing the ability  
> to stop example execution and test code incrementally. I currently  
> have over  1700 examples for the current application I'm working on,  
> and one little line of code that I added in my App controller  
> ( before_filter :set_location ) brought on almost 1100 errors across  
> my tests.  Now I know people will say that the requirements weren't  
> understood at the beginning of the application and that it could  
> have been avoided with better planning...

RSpec < BDD < Agile < Embrace Change. I don't think you'd see that  
argument here.

> but this isn't the case.
>
> I now have to go into each of my controller tests and add the stub  
> into every before declaration to clear up my errors.  Not fun, and  
> could've been avoided completely.

Yes, it could have, with the existing tools! Try this next time:

Spec::Runner.configure do |config|
   config.before(:each, :type => :controller) do
     controller.stub!(:set_location) if controller.respond_to? 
(:set_location)
   end
end

Hey Britt - I appreciate your passion for this feature, but I have to  
say that I'm as passionately against it as you are for it, for reasons  
I've cited and others have echoed.

That said, this is open source. If you want to make this happen then  
you have a few options.  You can write your own gem that extends rspec  
to do it. You can even fork rspec and add it to your fork, though I  
think we'd all be better served if you did it in a separate gem. In  
either case, that would get you the feature you want and give other  
people a chance to try it out. And if it evolves into an essential  
feature that a lot of people find real value in, I'd be willing to  
look at it again. But until such time as its proven itself otherwise,  
this feature seems more potentially harmful than useful to me.

FWIW,
David

From dchelimsky at gmail.com  Wed Jul  2 23:54:40 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 2 Jul 2008 22:54:40 -0500
Subject: [rspec-users] unable to access flash from rails helper spec
	since upgrade to 1.1.4
In-Reply-To: <486C197B.2000307@e4net.com>
References: <486C197B.2000307@e4net.com>
Message-ID: <1C4A805E-789E-4778-AA8E-58FBB0F376DA@gmail.com>

On Jul 2, 2008, at 7:12 PM, Jim Morris wrote:

> Hi,
>
> Many moons ago I wrote this blog entry...
>
> http://blog.wolfman.com/articles/2007/07/14/using-rspec-to-test-haml-helpers
>
> I just upgraded that rails project to use rspec 1.1.4 and associated  
> rspec_rails.
>
> It seems that my helper when called from the helper specs no longer  
> are able to access flash, controller etc as they did before.
>
> I already prepended all helper calls with helper. so I fixed those  
> changes, but I have been unable to figure out how to access flash  
> etc...
>
> Here is a simplified example...
>
> in ApplicationHelper.rb
>
> def test_flash
>    for name in [:notice, :warning, :error]
>      if flash[name]
>        return "#{flash[name]}"
>      end
>    end
>    nil
>  end
>
> In my rails/spec/helpers/application_helper_spec.rb
>
> require File.dirname(__FILE__) + '/../spec_helper'
>
> describe ApplicationHelper do
>
>  it "should test flash" do
>    for name in [:notice, :warning, :error]
>      flash[name]= "flash #{name.to_s} message"
>      helper.test_flash.should match(/.*#{name}.*/)
>      flash[name]= nil
>    end
>  end
>
> end
>
> I get this error trace...
> 1)
> NoMethodError in 'ApplicationHelper should test flash'
> You have a nil object when you didn't expect it!
> You might have expected an instance of Array.
> The error occurred while evaluating nil.[]
> /.../app/helpers/application_helper.rb:23:in `test_flash'
> ...
>
> flash is nil, this used to work, so what is the new magic  
> incantation to get this to work again?

Hey Jim - I fixed this in http://github.com/dchelimsky/rspec-rails/commit/40a0916325dbe9a1631849146d078e330fca71f2 
, so you can either grab the very latest from github or wait for the  
1.1.5 release (coming in the next few days).

Cheers,
David

From zach.dennis at gmail.com  Thu Jul  3 00:03:14 2008
From: zach.dennis at gmail.com (Zach Dennis)
Date: Thu, 3 Jul 2008 00:03:14 -0400
Subject: [rspec-users] Stopping Example Execution?
In-Reply-To: <BLU146-W32C34F2A42176C71C4216CD7980@phx.gbl>
References: <BLU146-W4326878715F7908584B6EBD79F0@phx.gbl>
	<57c63afe0807020415m9df6bdfmfed02ba908746e00@mail.gmail.com>
	<BLU146-W199A415EA35CCF5816862AD7990@phx.gbl>
	<BLU146-W32C34F2A42176C71C4216CD7980@phx.gbl>
Message-ID: <85d99afe0807022103t6783a64bw86d95c05cc5fea6e@mail.gmail.com>

One good way (IMO) to approach before filters is to always stub them when it
comes time to testing a controller action. And to test the filter separately
in isolation. For example if you need to define an application level before
filter in ApplicationController, then test the filter in isolation using an
application_controller_spec.

If you'd like to know that your controllers which subclass
ApplicationController use them, you can easily add a declarative style "it"
helper which verifies that the filter is being used, but doesn't test the
filter (since you already did that in your application_controller_spec.

I know this doesn't help you now, but it is a useful technique which you can
use in the future to limit the maintenance nightmare that can come along
with things like before filters,

Zach

On Wed, Jul 2, 2008 at 10:58 PM, Britt Mileshosky <mileshosky at hotmail.com>
wrote:

>
>
> ----------------------------------------
> > From: mileshosky at hotmail.com
> > To: rspec-users at rubyforge.org
> > Date: Wed, 2 Jul 2008 10:13:59 -0700
> > Subject: Re: [rspec-users] Stopping Example Execution?
> >
> >
> >
> > ----------------------------------------
> >> Date: Wed, 2 Jul 2008 06:15:10 -0500
> >> From: dchelimsky at gmail.com
> >> To: rspec-users at rubyforge.org
> >> Subject: Re: [rspec-users] Stopping Example Execution?
> >>
> >> On Mon, Jun 30, 2008 at 5:11 PM, Britt Mileshosky
> >>  wrote:
> >>>
> >>> n Sun, Jun 29, 2008 at 12:20 PM, David Chelimsky wrote:
> >>> On Jun 29, 2008, at 11:18 AM, Britt Mileshosky wrote:
> >>>
> >>> However, do you see where something like a return statement or end
> example statement could be beneficial?
> >>> If you are working from the top down with your controller action
> execution, then you only need to test your expectation
> >>> and then bail out of your action. No need to further test or meet
> requirements on anything else in that action because your
> >>> single test has been met.
> >>>
> >>> - in my example for making sure I find a user, I'd like to end
> execution once I DID find the user, i shouldn't have to satisfy
> >>> requirements about finding an account and a person... I'll write those
> expectations later in another nested describe group, as you
> >>> can see here, in a top down process
> >>>
> >>> PeopleController with a logged in user
> >>> - should find user
> >>>
> >>> PeopleController with a logged in user who has an account
> >>> - should find account
> >>>
> >>> PeopleController with a logged in user who doesnt have an account
> >>> - shouldn't find account
> >>> - should redirect ...
> >>>
> >>> PeopleController with a logged in user who has an account the person
> belongs to
> >>> - should find person
> >>> - should assign person for the view
> >>>
> >>> PeopleController with a logged in user who has an account the requested
> person does not belong to
> >>> - should not find person
> >>> - should ...
> >>>
> >>> My instinct about this is that it would encourage long methods because
> it would make it less painful to test them, so I would be adverse to
> anything that let's you short circuit the method.
> >>>
> >>> Anybody else have opinions on that?
> >>>
> >>>
> >>>
> >>> I'm just catching up on email now after being sick for the past six
> days, but health aside my opinion is that I agree with David's opinion.
> Rather than focusing on how-to write easier tests that complain less, start
> focusing on how-to write the right tests that complain when necessary.
> >>>
> >>> One of the benefits associated with feeling the pain of a test is that
> it may be a sign to re-assess and refactor your code. This usually happens
> early enough that it only takes a few minutes. Short circuiting essentially
> gives you the ability to not feel the pain. Its like CIPA [0], but for code.
> I would fear that the code would get so bad that by the time the test cried
> with pain your code was already beyond easy repair and instead required
> invasive surgery.
> >>>
> >>> Tests are part of the nervous system of your application. When they
> hurt, they're telling you something isn't right and that it should be
> addressed,
> >>>
> >>>
> >>>
> >>> I wouldn't really say that anything I have been presenting has been a
> result of 'pains',
> >>> more so an observation on how an example group with other example
> groups can be much more readable
> >>> for myself and for other developers when they need to read the specs.
> Stubbing everything at the top doesn't
> >>> make complete sense. Why not stub inside the example group that has a
> NICE describe statement telling you
> >>> what this stubbing is related to. We can't do this because the first
> examples will blow up due to having to execute
> >>> all the code.
> >>>
> >>> Take the 2 examples:
> >>>
> >>>
> ------------------------------------------------------------------------------------------------------------------------
> >>> PeopleController
> >>> # stub everything way up here at the top where these
> >>> # definitions are out of context (by means of position) with following
> examples
> >>> #
> >>> # stub controller requirments
> >>> # stub logged in requirement
> >>> # stub account requirement
> >>> # stub no account requirement
> >>> # stub account owns person
> >>> # stub account doesn't own person
> >>>
> >>>
> >>> PeopleController with before filters
> >>> - should require user
> >>>
> >>> PeopleController with a logged in user
> >>> - should find user
> >>>
> >>> PeopleController with a logged in user who has an account
> >>> - should find account
> >>>
> >>> PeopleController with a logged in user who doesnt have an account
> >>> - shouldn't find account
> >>> - should redirect ...
> >>>
> >>> PeopleController with a logged in user who has an account the person
> belongs to
> >>> - should find person
> >>> - should assign person for the view
> >>>
> >>> PeopleController with a logged in user who has an account the requested
> person does not belong to
> >>> - should not find person
> >>> - should ...
> >>>
> >>>
> ------------------------------------------------------------------------------------------------------------------------
> >>> PeopleController
> >>> # stub the minimum needed to get to the first example group up and
> running
> >>>
> >>> PeopleController with before filters
> >>> - should require user
> >>>
> >>> PeopleController with a logged in user
> >>> # stub logged in requirement
> >>> - should find user
> >>>
> >>> PeopleController with a logged in user who has an account
> >>> # stub account requirement
> >>> - should find account
> >>>
> >>> PeopleController with a logged in user who doesnt have an account
> >>> # stub no account requirement
> >>> - shouldn't find account
> >>> - should redirect ...
> >>>
> >>> PeopleController with a logged in user who has an account the person
> belongs to
> >>> # stub account owns person
> >>> - should find person
> >>> - should assign person for the view
> >>>
> >>> PeopleController with a logged in user who has an account the requested
> person does not belong to
> >>> # stub account doesn't own person
> >>> - should not find person
> >>> - should ...
> >>>
> >>>
> ------------------------------------------------------------------------------------------------------------------------
> >>>
> >>> I prefer the second group, but unfortunately I am not able to write my
> specs in this organized fashion.
> >>> Just sayin.
> >>
> >> I appreciate the communication value you're looking for, and you can
> >> get it by stubbing everything you need to keep execution going
> >> before(:each) example and then set message expectations
> >> (should_receive) inside each example that help tell the story of that
> >> example.
> >>
> >> PeopleController
> >> # stub everything way up here at the top where these
> >> # definitions are out of context (by means of position) with following
> examples
> >> #
> >> # stub controller requirments
> >> # stub logged in requirement
> >> # stub account requirement
> >> # stub no account requirement
> >> # stub account owns person
> >> # stub account doesn't own person
> >>
> >> PeopleController with before filters
> >> - should require user
> >>
> >> PeopleController with a logged in user
> >> # expect logged in query
> >> - should find user
> >>
> >> PeopleController with a logged in user who has an account
> >> # expect logged in query
> >> # expect account query
> >> - should find account
> >>
> >> etc
> >>
> >> HTH,
> >> David
> >
> > Yep, thats exactly what I've been practicing, and while its not exactly
> what I want, it does work nicely.
> > Thank you David
>
>
> I'm gonna make another REALLY strong case for allowing the ability to stop
> example execution and test code incrementally. I currently have over  1700
> examples for the current application I'm working on, and one little line of
> code that I added in my App controller ( before_filter :set_location )
> brought on almost 1100 errors across my tests.  Now I know people will say
> that the requirements weren't understood at the beginning of the application
> and that it could have been avoided with better planning... but this isn't
> the case.
>
> I now have to go into each of my controller tests and add the stub into
> every before declaration to clear up my errors.  Not fun, and could've been
> avoided completely.
>
> Britt
>
> _________________________________________________________________
> Enter the Zune-A-Day Giveaway for your chance to win ? day after day after
> day
>
> http://www.windowslive-hotmail.com/ZuneADay/?locale=en-US&ocid=TXT_TAGLM_Mobile_Zune_V1
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>



-- 
Zach Dennis
http://www.continuousthinking.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20080703/35195ea2/attachment.html>

From pergesu at gmail.com  Thu Jul  3 01:57:30 2008
From: pergesu at gmail.com (Pat Maddox)
Date: Wed, 2 Jul 2008 22:57:30 -0700
Subject: [rspec-users] Stopping example execution?
In-Reply-To: <BLU146-W41A722FCB9943D8A3F86ECD79C0@phx.gbl>
References: <BLU146-W12D9E0CCBB129CA789F2AD79D0@phx.gbl>
	<60f3810c0806281624y3130ba6eq7674b71f9b9c1e8f@mail.gmail.com>
	<BLU146-W1321301A106879993D1E88D79C0@phx.gbl>
	<62D4CE49-947E-4027-BF34-CD6326643F83@gmail.com>
	<BLU146-W41A722FCB9943D8A3F86ECD79C0@phx.gbl>
Message-ID: <810a540e0807022257n3711dc88rc7f7daf63f852ca1@mail.gmail.com>

On Sun, Jun 29, 2008 at 9:18 AM, Britt Mileshosky
<mileshosky at hotmail.com> wrote:
>
> However, do you see where something like a return statement or end example statement could be beneficial?
> If you are working from the top down with your controller action execution, then you only need to test your expectation
> and then bail out of your action.  No need to further test or meet requirements on anything else in that action because your
> single test has been met.
>
> - in my example for making sure I find a user, I'd like to end execution once I DID find the user, i shouldn't have to satisfy
> requirements about finding an account and a person... I'll write those expectations later in another nested describe group, as you
> can see here, in a top down process
>
> PeopleController with a logged in user
> - should find user
>
> PeopleController with a logged in user who has an account
> - should find account
>
> PeopleController with a logged in user who doesnt have an account
> - shouldn't find account
> - should redirect ...
>
> PeopleController with a logged in user who has an account the person belongs to
> - should find person
> - should assign person for the view
>
> PeopleController with a logged in user who has an account the requested person does not belong to
> - should not find person
> - should ...

Hi Britt,

Quick little thought experiment for you:

Imagine you write the examples as you have described, stubbing only
the minimum amount of things necessary and then ending the example
once you've reached a certain point.  So for the action

def some_action
  @user = self.current_user
  @account = self.current_account if self.has_account?
  @person = @account.people.find(params[:person])
end

your first example only runs until current_user, your second example
runs only until has_account, and your third one runs only until
account.people.find.  So far so good.

What happens when you change the implementation to:

def some_action
  @user = self.current_user
  if self.has_account?
    @account = self.current_account
    @person = @account.people.find(params[:person])
  end
end

which I could totally see doing, given that the original
implementation will raise an error on the @account.people call on
those occasions where has_account? returns false, making @account nil.

Can you spot the problem?  Your specs will now fail because you had
only stubbed enough to get to a particular line.  The specs are very
tightly coupled to the implementation, which sucks.

Also, if you were to do this incremental stubbing, you would have a
hard time moving examples around, because the nested examples would
rely on context set up by the parents.

This technique, after looking a bit more deeply at it, would lead to
specs that are tightly coupled to the implementation and to each
other.  Tight coupling is usually bad, and tight coupling from both
angles is a recipe for total frustration.

I hope that is helpful.

Pat

From ml at e4net.com  Thu Jul  3 02:29:53 2008
From: ml at e4net.com (Jim Morris)
Date: Wed, 02 Jul 2008 23:29:53 -0700
Subject: [rspec-users] unable to access flash from rails helper
 spec	since upgrade to 1.1.4
In-Reply-To: <1C4A805E-789E-4778-AA8E-58FBB0F376DA@gmail.com>
References: <486C197B.2000307@e4net.com>
	<1C4A805E-789E-4778-AA8E-58FBB0F376DA@gmail.com>
Message-ID: <486C71E1.8010804@e4net.com>

Hi David,

Thanks that worked, and fixed that problem.

Now I have run into another problem, from the same blog example (which I'll update once I get it all 
to work).

Within the application helper I call haml_tag, which works fine when the app runs. (used to be 
called open).

However when I try to test that helper in my helper spec I get...

NoMethodError in 'ApplicationHelper should display flash'
undefined method `haml_tag' for #<Spec::Rails::Example::HelperExampleGroup::HelperObject:0xb71ced20>

For some reason it doesn't know anything about haml when run from the spec.

I guess I need to inject a require haml or something into the HelperObject? I just don't know how to 
do that.

I am using the latest version of HAML but I am still using rails 1.2.6

Any ideas?

Thanks
Jim

David Chelimsky wrote:
> On Jul 2, 2008, at 7:12 PM, Jim Morris wrote:
> 
>> Hi,
>>
>> Many moons ago I wrote this blog entry...
>>
>> http://blog.wolfman.com/articles/2007/07/14/using-rspec-to-test-haml-helpers 
>>
>>
>> I just upgraded that rails project to use rspec 1.1.4 and associated 
>> rspec_rails.
>>
>> It seems that my helper when called from the helper specs no longer 
>> are able to access flash, controller etc as they did before.
>>
>> I already prepended all helper calls with helper. so I fixed those 
>> changes, but I have been unable to figure out how to access flash etc...
>>
>> Here is a simplified example...
>>
>> in ApplicationHelper.rb
>>
>> def test_flash
>>    for name in [:notice, :warning, :error]
>>      if flash[name]
>>        return "#{flash[name]}"
>>      end
>>    end
>>    nil
>>  end
>>
>> In my rails/spec/helpers/application_helper_spec.rb
>>
>> require File.dirname(__FILE__) + '/../spec_helper'
>>
>> describe ApplicationHelper do
>>
>>  it "should test flash" do
>>    for name in [:notice, :warning, :error]
>>      flash[name]= "flash #{name.to_s} message"
>>      helper.test_flash.should match(/.*#{name}.*/)
>>      flash[name]= nil
>>    end
>>  end
>>
>> end
>>
>> I get this error trace...
>> 1)
>> NoMethodError in 'ApplicationHelper should test flash'
>> You have a nil object when you didn't expect it!
>> You might have expected an instance of Array.
>> The error occurred while evaluating nil.[]
>> /.../app/helpers/application_helper.rb:23:in `test_flash'
>> ...
>>
>> flash is nil, this used to work, so what is the new magic incantation 
>> to get this to work again?
> 
> Hey Jim - I fixed this in 
> http://github.com/dchelimsky/rspec-rails/commit/40a0916325dbe9a1631849146d078e330fca71f2, 
> so you can either grab the very latest from github or wait for the 1.1.5 
> release (coming in the next few days).
> 
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
> 


-- 
Jim Morris, http://blog.wolfman.com

From lists at ruby-forum.com  Thu Jul  3 03:24:15 2008
From: lists at ruby-forum.com (Damian Terentiev)
Date: Thu, 3 Jul 2008 09:24:15 +0200
Subject: [rspec-users] Controller spec gives strange error
Message-ID: <f0c7c61f449006870ebd594d1e603a89@ruby-forum.com>

Good day!

I have a Rails app with a controller that sets an instance variable in a
before_filter, like this:

class PostsController < ApplicationController

  before_filter :set_site_language

  def set_site_language
    @site_language = cookie['lang'] ?
      Language.find_by_code(cookie['lang']) :
      Language.find(:first)
  end

  def index
    @posts = Post.find_by_language_id(@site_language.id)
  end

end

The controller has the following spec:

describe PostsController do

  it "should show home page" do
    get :index
    response.should be_success
  end

end

And the equivalent test:

class PostsControllerTest < ActionController::TestCase

  def test_should_show_home_page
    get :index
    assert_response :success
  end

end

The test runs fine, but the spec fails with the following error on line
with `@posts = Post.find_by_language_id(@site_language.id)`:

RuntimeError in 'PostsController should show home page'
Called id for nil, which would mistakenly be 4 -- if you really wanted
the id of nil, use object_id

Seems that @site_language does not get assigned when spec runs. Could
you please help me solve this problem?

Yours,
Damian
-- 
Posted via http://www.ruby-forum.com/.

From dchelimsky at gmail.com  Thu Jul  3 03:39:18 2008
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 3 Jul 2008 02:39:18 -0500
Subject: [rspec-users] unable to access flash from rails helper
	spec	since upgrade to 1.1.4
In-Reply-To: <486C71E1.8010804@e4net.com>
References: <486C197B.2000307@e4net.com>
	<1C4A805E-789E-4778-AA8E-58FBB0F376DA@gmail.com>
	<486C71E1.8010804@e4net.com>
Message-ID: <5F49DCC8-F8BE-4178-A11E-7D2F234D72EC@gmail.com>

On Jul 3, 2008, at 1:29 AM, Jim Morris wrote:

> Hi David,
>
> Thanks that worked, and fixed that problem.
>
> Now I have run into another problem, from the same blog example  
> (which I'll update once I get it all to work).
>
> Within the application helper I call haml_tag, which works fine when  
> the app runs. (used to be called open).
>
> However when I try to test that helper in my helper spec I get...
>
> NoMethodError in 'ApplicationHelper should display flash'
> undefined method `haml_tag' for  
> #<Spec::Rails::Example::HelperExampleGroup::HelperObject:0xb71ced20>
>
> For some reason it doesn't know anything about haml when run from  
> the spec.
>
> I guess I need to inject a require haml or something into the  
> HelperObject? I just don't know how to do that.

Try this:

before(:each) do
   helper.extend Haml::Helpers
end

it "should ...." do
   ...
end


>
>
> I am using the latest version of HAML but I am still using rails 1.2.6
>
> Any ideas?
>
> Thanks
> Jim
>
> David Chelimsky wrote:
>> On Jul 2, 2008, at 7:12 PM, Jim Morris wrote:
>>> Hi,
>>>
>>> Many moons ago I wrote this blog entry...
>>>
>>> http://blog.wolfman.com/articles/2007/07/14/using-rspec-to-test-haml-helpers
>>>
>>> I just upgraded that rails project to use rspec 1.1.4 and  
>>> associated rspec_rails.
>>>
>>> It seems that my helper when called from the helper specs no  
>>> longer are able to access flash, controller etc as they did before.
>>>
>>> I already prepended all helper calls with helper. so I fixed those  
>>> changes, but I have been unable to figure out how to access flash  
>>> etc...
>>>
>>> Here is a simplified example...
>>>
>>> in ApplicationHelper.rb
>>>
>>> def test_flash
>>>   for name in [:notice, :warning, :error]
>>>     if flash[name]
>>>       return "#{flash[name]}"
>>>     end
>>>   end
>>>   nil
>>> end
>>>
>>> In my rails/spec/helpers/application_helper_spec.rb
>>>
>>> require File.dirname(__FILE__) + '/../spec_helper'
>>>
>>> describe ApplicationHelper do
>>>
>>> it "should test flash" do
>>>   for name in [:notice, :warning, :error]
>>>     flash[name]= "flash #{name.to_s} message"
>>>     helper.test_flash.should match(/.*#{name}.*/)
>>>     flash[name]= nil
>>>   end
>>> end
>>>
>>> end
>>>
>>> I get this error trace...
>>> 1)
>>> NoMethodError in 'ApplicationHelper should test flash'
>>> You have a nil object when you didn't expect it!
>>> You might have expected an instance of Array.
>>> The error occurred while evaluating nil.[]
>>> /.../app/helpers/application_helper.rb:23:in `test_flash'
>>> ...
>>>
>>> flash is nil, this used to work, so what is the new magic  
>>> incantation to get this to work again?
>> Hey Jim - I fixed this in http://github.com/dchelimsky/rspec-rails/commit/40a0916325dbe9a1631849146d078e330fca71f2 
>> , so you can either grab the very latest from github or wait for  
>> the 1.1.5 release (coming in the next few days).
>> Cheers,
>> David
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
> -- 
> Jim Morris, http://blog.wolfman.com
> _______________________________________________
> rspec-users