From mike.pence at gmail.com  Wed Nov  1 12:46:25 2006
From: mike.pence at gmail.com (Mike Pence)
Date: Wed, 1 Nov 2006 12:46:25 -0500
Subject: [Rspec-users] Referencing a plugin in a spec
Message-ID: <d8ee51740611010946g4cc0287ak7e403fd0d17a3faf@mail.gmail.com>

I am writing some specs that use ActiveMerchant to talk to a cc provider.

When I try to "include ActiveMerchant::Billing" in my spec, it tells
me it can't find the plugin:

./activesupport/lib/active_support/dependencies.rb:123:in
`const_missing': uninitialized constant ActiveMerchant (NameError)

Do I need to explicity require the main plugin file?

Thanks,
Mike Pence

From george at benevolentcode.com  Wed Nov  1 13:01:55 2006
From: george at benevolentcode.com (George Anderson)
Date: Wed, 1 Nov 2006 13:01:55 -0500
Subject: [Rspec-users] How to run edge RSpec (on Rails)?
In-Reply-To: <57c63afe0610312037i162e9d07rcf19f8e577145107@mail.gmail.com>
References: <782d66f30610310914k294b5472jf073c7ac5ec9daba@mail.gmail.com>
	<57c63afe0610312037i162e9d07rcf19f8e577145107@mail.gmail.com>
Message-ID: <782d66f30611011001i2d76c8e4q794b39445d4577c5@mail.gmail.com>

Thanks, David.

I successfully built and installed the gem, but I'm running into an
issue similar to one Aslak reported:

http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149

I've added the details of my issue as a followup to his ticket.

Thanks again,

George

On 10/31/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 10/31/06, George Anderson <george at benevolentcode.com> wrote:
> > I'm interested in tracking edge development of the RSpec on Rails
> > plugin and I'm a bit confused.
> >
> > The installation guide
> > (http://rspec.rubyforge.org/documentation/rails/install.html) says,
> > "You'll have to install the RSpec core gem first."  It also says,
> > "Take note of what rspec version you're installing ? it's very
> > important that you install a compatible RSpec on Rails plugin."
> >
> > >From the "Installation" section (for RSpec on Rails) I understand how
> > to track the HEAD of trunk for the plugin development, but I'm not
> > sure if I can use the edge plugin with the RSpec core gem (via "gem
> > install rspec").
> >
> > In order to use the edge plugin, do I also need to use edge rspec?
>
> Yes.
>
> > If so, how do I install edge rspec and ensure it gets used instead of
> > the RSpec gem (0.6.4)?
>
> check out the trunk
> read the README - that should tell you what you need to build rspec
> once you have the dependencies in place you should be able to do this:
>
> rake gem
> gem install pkg/rspec-X.X.X.gem
>
> Let us know if that works for you.
>
> Cheers,
> David
>
> >
> > I've done my best to RTFM, but I'm still climbing the Ruby curve and
> > apparently missing some key bits to pull this together.
> >
> > Thanks for any direction you might provide.
> >
> > /george
> > _______________________________________________
> > Rspec-users mailing list
> > Rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From mike.pence at gmail.com  Wed Nov  1 13:14:04 2006
From: mike.pence at gmail.com (Mike Pence)
Date: Wed, 1 Nov 2006 13:14:04 -0500
Subject: [Rspec-users] Referencing a plugin in a spec
In-Reply-To: <d8ee51740611010946g4cc0287ak7e403fd0d17a3faf@mail.gmail.com>
References: <d8ee51740611010946g4cc0287ak7e403fd0d17a3faf@mail.gmail.com>
Message-ID: <d8ee51740611011014w66cba2aalbdd2b7e5c889cdbb@mail.gmail.com>

Nevermind. :)

On 11/1/06, Mike Pence <mike.pence at gmail.com> wrote:
> I am writing some specs that use ActiveMerchant to talk to a cc provider.
>
> When I try to "include ActiveMerchant::Billing" in my spec, it tells
> me it can't find the plugin:
>
> ./activesupport/lib/active_support/dependencies.rb:123:in
> `const_missing': uninitialized constant ActiveMerchant (NameError)
>
> Do I need to explicity require the main plugin file?
>
> Thanks,
> Mike Pence
>

From aslak.hellesoy at gmail.com  Wed Nov  1 14:07:09 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 1 Nov 2006 20:07:09 +0100
Subject: [Rspec-users] How to run edge RSpec (on Rails)?
In-Reply-To: <782d66f30611011001i2d76c8e4q794b39445d4577c5@mail.gmail.com>
References: <782d66f30610310914k294b5472jf073c7ac5ec9daba@mail.gmail.com>
	<57c63afe0610312037i162e9d07rcf19f8e577145107@mail.gmail.com>
	<782d66f30611011001i2d76c8e4q794b39445d4577c5@mail.gmail.com>
Message-ID: <8d961d900611011107ie0747e9j966a1e086b55b425@mail.gmail.com>

On 11/1/06, George Anderson <george at benevolentcode.com> wrote:
> Thanks, David.
>
> I successfully built and installed the gem, but I'm running into an
> issue similar to one Aslak reported:
>
> http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149
>
> I've added the details of my issue as a followup to his ticket.
>

Your problem seems to be unrelated to the issue I reported (your
exception is completely different than mine). It looks like your RSpec
on Rails is incompatible with your RSpec gem.

1) What RSpec version do you have? (a downloaded gem? self-built gem/svn rev?)
2) Are you running RSpec on Rails from trunk/HEAD or a particular svn
tagged revision?

Aslak

> Thanks again,
>
> George
>
> On 10/31/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 10/31/06, George Anderson <george at benevolentcode.com> wrote:
> > > I'm interested in tracking edge development of the RSpec on Rails
> > > plugin and I'm a bit confused.
> > >
> > > The installation guide
> > > (http://rspec.rubyforge.org/documentation/rails/install.html) says,
> > > "You'll have to install the RSpec core gem first."  It also says,
> > > "Take note of what rspec version you're installing ? it's very
> > > important that you install a compatible RSpec on Rails plugin."
> > >
> > > >From the "Installation" section (for RSpec on Rails) I understand how
> > > to track the HEAD of trunk for the plugin development, but I'm not
> > > sure if I can use the edge plugin with the RSpec core gem (via "gem
> > > install rspec").
> > >
> > > In order to use the edge plugin, do I also need to use edge rspec?
> >
> > Yes.
> >
> > > If so, how do I install edge rspec and ensure it gets used instead of
> > > the RSpec gem (0.6.4)?
> >
> > check out the trunk
> > read the README - that should tell you what you need to build rspec
> > once you have the dependencies in place you should be able to do this:
> >
> > rake gem
> > gem install pkg/rspec-X.X.X.gem
> >
> > Let us know if that works for you.
> >
> > Cheers,
> > David
> >
> > >
> > > I've done my best to RTFM, but I'm still climbing the Ruby curve and
> > > apparently missing some key bits to pull this together.
> > >
> > > Thanks for any direction you might provide.
> > >
> > > /george
> > > _______________________________________________
> > > Rspec-users mailing list
> > > Rspec-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> > _______________________________________________
> > Rspec-users mailing list
> > Rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From george at benevolentcode.com  Wed Nov  1 21:46:31 2006
From: george at benevolentcode.com (George Anderson)
Date: Wed, 1 Nov 2006 21:46:31 -0500
Subject: [rspec-users] [Rspec-users] How to run edge RSpec (on Rails)?
In-Reply-To: <8d961d900611011107ie0747e9j966a1e086b55b425@mail.gmail.com>
References: <782d66f30610310914k294b5472jf073c7ac5ec9daba@mail.gmail.com>
	<57c63afe0610312037i162e9d07rcf19f8e577145107@mail.gmail.com>
	<782d66f30611011001i2d76c8e4q794b39445d4577c5@mail.gmail.com>
	<8d961d900611011107ie0747e9j966a1e086b55b425@mail.gmail.com>
Message-ID: <782d66f30611011846o7d29476bp331a3896baa1aa9b@mail.gmail.com>

Thanks, Aslak.  I *think* I've got it straight now. And my apologies for
injecting noise into the tracker.  My mistake.

Does this sound like the proper way to track edge RSpec and RSpec on Rails
development?


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Check out RSpec trunk from: svn://rubyforge.org/var/svn/rspec/trunk
Check out RSpec trunk into its own project, or if you're interested in
using/learning RSpec for a particular Rails project, consider using
svn:externals to check out RSpec trunk into your [RailsRoot]/vendor
directory:

svn propset svn:externals "rspec svn://rubyforge.org/var/svn/rspec/trunk"
vendor

then update to grab the latest code from RSpec trunk:

svn update vendor

Next, build the gem.  You have to be standing in vendor/rspec if you're
using svn:externals (as described above) or the root of RSpec if you checked
it out as its own project.

rake gem

then install it:

gem install pkg/rspec-X.X.X.gem (where X.X.X is the version number reported
in the output from "rake gem")

(Note: you can always uninstall the *edge* RSpec gem via "gem uninstall
rspec")


Now that you've installed the *edge* RSpec gem, you MUST install the *edge*
RSpec on Rails plugin:

script/plugin install -x
svn://rubyforge.org/var/svn/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec

This will install the RSpec on Rails plugin via svn:externals so it will
always track trunk development.


One last, MANDATORY step:  you must bootstrap your Rails app with RSpec.
Standing in [RailsRoot]:

script/generate rspec

Be sure to overwrite files if prompted.

In summary:
1. check out RSpec trunk
2. build the gem
3. install the gem
4. install the RSpec on Rails plugin from trunk
5. bootstrap you Rails app with RSpec
6. there is no step 6! (with apologies to Instiki)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think those steps are fairly accurate, but I'd appreciate any critical
input.

I'd be happy to markup the steps for inclusion in
http://rspec.rubyforge.org/documentation/rails/ if it would be appropriate.

Thanks again for your help,

George

On 11/1/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 11/1/06, George Anderson <george at benevolentcode.com> wrote:
> > Thanks, David.
> >
> > I successfully built and installed the gem, but I'm running into an
> > issue similar to one Aslak reported:
> >
> >
http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149
> >
> > I've added the details of my issue as a followup to his ticket.
> >
>
> Your problem seems to be unrelated to the issue I reported (your
> exception is completely different than mine). It looks like your RSpec
> on Rails is incompatible with your RSpec gem.
>
> 1) What RSpec version do you have? (a downloaded gem? self-built gem/svn
rev?)
> 2) Are you running RSpec on Rails from trunk/HEAD or a particular svn
> tagged revision?
>
> Aslak
>
> > Thanks again,
> >
> > George
> >
> > On 10/31/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 10/31/06, George Anderson <george at benevolentcode.com> wrote:
> > > > I'm interested in tracking edge development of the RSpec on Rails
> > > > plugin and I'm a bit confused.
> > > >
> > > > The installation guide
> > > > (http://rspec.rubyforge.org/documentation/rails/install.html) says,
> > > > "You'll have to install the RSpec core gem first."  It also says,
> > > > "Take note of what rspec version you're installing ? it's very
> > > > important that you install a compatible RSpec on Rails plugin."
> > > >
> > > > >From the "Installation" section (for RSpec on Rails) I understand
how
> > > > to track the HEAD of trunk for the plugin development, but I'm not
> > > > sure if I can use the edge plugin with the RSpec core gem (via "gem
> > > > install rspec").
> > > >
> > > > In order to use the edge plugin, do I also need to use edge rspec?
> > >
> > > Yes.
> > >
> > > > If so, how do I install edge rspec and ensure it gets used instead
of
> > > > the RSpec gem (0.6.4)?
> > >
> > > check out the trunk
> > > read the README - that should tell you what you need to build rspec
> > > once you have the dependencies in place you should be able to do this:
> > >
> > > rake gem
> > > gem install pkg/rspec-X.X.X.gem
> > >
> > > Let us know if that works for you.
> > >
> > > Cheers,
> > > David
> > >
> > > >
> > > > I've done my best to RTFM, but I'm still climbing the Ruby curve and
> > > > apparently missing some key bits to pull this together.
> > > >
> > > > Thanks for any direction you might provide.
> > > >
> > > > /george
> > > > _______________________________________________
> > > > Rspec-users mailing list
> > > > Rspec-users at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-users
> > > >
> > > _______________________________________________
> > > Rspec-users mailing list
> > > Rspec-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> > _______________________________________________
> > Rspec-users mailing list
> > Rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061101/1b55233f/attachment.html 

From dchelimsky at gmail.com  Wed Nov  1 22:32:56 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 1 Nov 2006 22:32:56 -0500
Subject: [rspec-users] [Rspec-users] How to run edge RSpec (on Rails)?
In-Reply-To: <782d66f30611011846o7d29476bp331a3896baa1aa9b@mail.gmail.com>
References: <782d66f30610310914k294b5472jf073c7ac5ec9daba@mail.gmail.com>
	<57c63afe0610312037i162e9d07rcf19f8e577145107@mail.gmail.com>
	<782d66f30611011001i2d76c8e4q794b39445d4577c5@mail.gmail.com>
	<8d961d900611011107ie0747e9j966a1e086b55b425@mail.gmail.com>
	<782d66f30611011846o7d29476bp331a3896baa1aa9b@mail.gmail.com>
Message-ID: <57c63afe0611011932v3a752f0fi1f67bca7670d5332@mail.gmail.com>

On 11/1/06, George Anderson <george at benevolentcode.com> wrote:
> Thanks, Aslak.  I *think* I've got it straight now. And my apologies for
> injecting noise into the tracker.  My mistake.
>
> Does this sound like the proper way to track edge RSpec and RSpec on Rails
> development?
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Check out RSpec trunk from:
> svn://rubyforge.org/var/svn/rspec/trunk
> Check out RSpec trunk into its own project, or if you're interested in
> using/learning RSpec for a particular Rails project, consider using
> svn:externals to check out RSpec trunk into your [RailsRoot]/vendor
> directory:
>
> svn propset svn:externals "rspec
> svn://rubyforge.org/var/svn/rspec/trunk" vendor
>
> then update to grab the latest code from RSpec trunk:
>
> svn update vendor
>
> Next, build the gem.  You have to be standing in vendor/rspec if you're
> using svn:externals (as described above) or the root of RSpec if you checked
> it out as its own project.
>
> rake gem
>
> then install it:
>
> gem install pkg/rspec-X.X.X.gem (where X.X.X is the version number reported
> in the output from "rake gem")
>
> (Note: you can always uninstall the *edge* RSpec gem via "gem uninstall
> rspec")
>
>
> Now that you've installed the *edge* RSpec gem, you MUST install the *edge*
> RSpec on Rails plugin:
>
> script/plugin install -x
> svn://rubyforge.org/var/svn/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec
>
> This will install the RSpec on Rails plugin via svn:externals so it will
> always track trunk development.
>
>
> One last, MANDATORY step:  you must bootstrap your Rails app with RSpec.
> Standing in [RailsRoot]:
>
> script/generate rspec
>
> Be sure to overwrite files if prompted.
>
> In summary:
> 1. check out RSpec trunk
> 2. build the gem
> 3. install the gem
> 4. install the RSpec on Rails plugin from trunk
> 5. bootstrap you Rails app with RSpec
> 6. there is no step 6! (with apologies to Instiki)
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I think those steps are fairly accurate, but I'd appreciate any critical
> input.
>
> I'd be happy to markup the steps for inclusion in
> http://rspec.rubyforge.org/documentation/rails/ if it would
> be appropriate.

Thanks for documenting this. I need to review to make sure it's
accurate, but will add a page on this to the website for the 0.7
release.

FYI - we generate the website using webgen, so marking it up in html
won't be useful for us - but thank you for the offer!

>
> Thanks again for your help,
>
> George
>
>
> On 11/1/06, aslak hellesoy < aslak.hellesoy at gmail.com> wrote:
> > On 11/1/06, George Anderson <george at benevolentcode.com> wrote:
> > > Thanks, David.
> > >
> > > I successfully built and installed the gem, but I'm running into an
> > > issue similar to one Aslak reported:
> > >
> > >
> http://rubyforge.org/tracker/index.php?func=detail&aid=6411&group_id=797&atid=3149
> > >
> > > I've added the details of my issue as a followup to his ticket.
> > >
> >
> > Your problem seems to be unrelated to the issue I reported (your
> > exception is completely different than mine). It looks like your RSpec
> > on Rails is incompatible with your RSpec gem.
> >
> > 1) What RSpec version do you have? (a downloaded gem? self-built gem/svn
> rev?)
> > 2) Are you running RSpec on Rails from trunk/HEAD or a particular svn
> > tagged revision?
> >
> > Aslak
> >
> > > Thanks again,
> > >
> > > George
> > >
> > > On 10/31/06, David Chelimsky < dchelimsky at gmail.com> wrote:
> > > > On 10/31/06, George Anderson <george at benevolentcode.com> wrote:
> > > > > I'm interested in tracking edge development of the RSpec on Rails
> > > > > plugin and I'm a bit confused.
> > > > >
> > > > > The installation guide
> > > > >
> (http://rspec.rubyforge.org/documentation/rails/install.html
> ) says,
> > > > > "You'll have to install the RSpec core gem first."  It also says,
> > > > > "Take note of what rspec version you're installing ? it's very
> > > > > important that you install a compatible RSpec on Rails plugin."
> > > > >
> > > > > >From the "Installation" section (for RSpec on Rails) I understand
> how
> > > > > to track the HEAD of trunk for the plugin development, but I'm not
>  > > > > sure if I can use the edge plugin with the RSpec core gem (via "gem
> > > > > install rspec").
> > > > >
> > > > > In order to use the edge plugin, do I also need to use edge rspec?
> > > >
> > > > Yes.
> > > >
> > > > > If so, how do I install edge rspec and ensure it gets used instead
> of
> > > > > the RSpec gem (0.6.4)?
> > > >
> > > > check out the trunk
> > > > read the README - that should tell you what you need to build rspec
> > > > once you have the dependencies in place you should be able to do this:
> > > >
> > > > rake gem
>  > > > gem install pkg/rspec-X.X.X.gem
> > > >
> > > > Let us know if that works for you.
> > > >
> > > > Cheers,
> > > > David
> > > >
> > > > >
> > > > > I've done my best to RTFM, but I'm still climbing the Ruby curve and
> > > > > apparently missing some key bits to pull this together.
> > > > >
> > > > > Thanks for any direction you might provide.
> > > > >
> > > > > /george
> > > > > _______________________________________________
> > > > > Rspec-users mailing list
> > > > > Rspec-users at rubyforge.org
> > > > > http://rubyforge.org/mailman/listinfo/rspec-users
> > > > >
> > > > _______________________________________________
> > > > Rspec-users mailing list
> > > > Rspec-users at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-users
> > > >
> > > _______________________________________________
> > > Rspec-users mailing list
> > > Rspec-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> >
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>

From pergesu at gmail.com  Fri Nov  3 18:38:54 2006
From: pergesu at gmail.com (Pat Maddox)
Date: Fri, 3 Nov 2006 16:38:54 -0700
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful scaffold
	generator with RSpec specifications
Message-ID: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>

rspec_resource_generator
========================

By Pat Maddox

Use this generator to generate RESTful scaffolding with RSpec specifications.

Syntax is exactly the same as the scaffold_resource generator:
./script/generate rspec_resource ModelName [field:type field:type]

When you run this generator, it will create a migration, model, and
model spec file.  In addition, it gives you a RESTful controller with
all the actions filled in, and a complete specification for the
controller.  Views are all hooked up too.

Generate the code, run the migration, and you've got 26 passing
RESTful controller specifications.  Salt and hot sauce to taste.

http://svn.flpr.org/public/plugins/rspec_resource_generator/

Most code shamelessly jacked from the scaffold_resource plugin.  I
did, however, write all the specs.  This code released under the
DoWhatYouWantWithIt license.

From contact at lukeredpath.co.uk  Fri Nov  3 21:40:43 2006
From: contact at lukeredpath.co.uk (Luke Redpath)
Date: Sat, 4 Nov 2006 02:40:43 +0000
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
Message-ID: <4A27CFE9-5A2D-4513-82DF-A4450682E3A0@lukeredpath.co.uk>

Ah Pat...so is this why you were quizzing me on speccing controllers  
today huh? ;)

Looks good mate. I'll give it a bash when I'm next in the office.

Cheers,
Luke Redpath
contact at lukeredpath.co.uk



On 3 Nov 2006, at 23:38, Pat Maddox wrote:

> rspec_resource_generator
> ========================
>
> By Pat Maddox
>
> Use this generator to generate RESTful scaffolding with RSpec  
> specifications.
>
> Syntax is exactly the same as the scaffold_resource generator:
> ./script/generate rspec_resource ModelName [field:type field:type]
>
> When you run this generator, it will create a migration, model, and
> model spec file.  In addition, it gives you a RESTful controller with
> all the actions filled in, and a complete specification for the
> controller.  Views are all hooked up too.
>
> Generate the code, run the migration, and you've got 26 passing
> RESTful controller specifications.  Salt and hot sauce to taste.
>
> http://svn.flpr.org/public/plugins/rspec_resource_generator/
>
> Most code shamelessly jacked from the scaffold_resource plugin.  I
> did, however, write all the specs.  This code released under the
> DoWhatYouWantWithIt license.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From aslak.hellesoy at gmail.com  Sat Nov  4 04:29:48 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 4 Nov 2006 10:29:48 +0100
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
Message-ID: <8d961d900611040129t21903850g8b158f7a7107af54@mail.gmail.com>

On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> rspec_resource_generator
> ========================
>
> By Pat Maddox
>
> Use this generator to generate RESTful scaffolding with RSpec specifications.
>
> Syntax is exactly the same as the scaffold_resource generator:
> ./script/generate rspec_resource ModelName [field:type field:type]
>
> When you run this generator, it will create a migration, model, and
> model spec file.  In addition, it gives you a RESTful controller with
> all the actions filled in, and a complete specification for the
> controller.  Views are all hooked up too.
>
> Generate the code, run the migration, and you've got 26 passing
> RESTful controller specifications.  Salt and hot sauce to taste.
>

That is awesome!

> http://svn.flpr.org/public/plugins/rspec_resource_generator/
>
> Most code shamelessly jacked from the scaffold_resource plugin.  I

The generators in Rails *will* evolve and copying/forking its code
will inevitably result in a maintenance nightmare (or obsoletion).

That's why the existing RSpec generators (rspec_model and
rspec_controller) _reuse_ the templates from Rails instead of forking
them. The only templates we wrote ourselves are the ones that generate
the specs. Maintaining that is easy - it's *our* code.

Would you consider refactoring your code according to this principle
and delete all the duplicated (copied) code? In that case we'll
include your contribution into RSpec on Rails.

There is already an RFE for it here:
http://rubyforge.org/tracker/index.php?func=detail&aid=6098&group_id=797&atid=9464

Cheers,
Aslak

> did, however, write all the specs.  This code released under the
> DoWhatYouWantWithIt license.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From pergesu at gmail.com  Sat Nov  4 11:42:22 2006
From: pergesu at gmail.com (Pat Maddox)
Date: Sat, 4 Nov 2006 09:42:22 -0700
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <4A27CFE9-5A2D-4513-82DF-A4450682E3A0@lukeredpath.co.uk>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
	<4A27CFE9-5A2D-4513-82DF-A4450682E3A0@lukeredpath.co.uk>
Message-ID: <810a540e0611040842m1c83556ep77951ba59818a5a6@mail.gmail.com>

Well I was just writing specs for one RESTful controller, then I
started writing nearly the exact same specs..obviously then it was
time for a plugin.

Sorry for not giving you credit earlier, I was at the end of a long
coding session and just wanted to get rid of it.  You're in there now
:)

Pat

On 11/3/06, Luke Redpath <contact at lukeredpath.co.uk> wrote:
> Ah Pat...so is this why you were quizzing me on speccing controllers
> today huh? ;)
>
> Looks good mate. I'll give it a bash when I'm next in the office.
>
> Cheers,
> Luke Redpath
> contact at lukeredpath.co.uk
>
>
>
> On 3 Nov 2006, at 23:38, Pat Maddox wrote:
>
> > rspec_resource_generator
> > ========================
> >
> > By Pat Maddox
> >
> > Use this generator to generate RESTful scaffolding with RSpec
> > specifications.
> >
> > Syntax is exactly the same as the scaffold_resource generator:
> > ./script/generate rspec_resource ModelName [field:type field:type]
> >
> > When you run this generator, it will create a migration, model, and
> > model spec file.  In addition, it gives you a RESTful controller with
> > all the actions filled in, and a complete specification for the
> > controller.  Views are all hooked up too.
> >
> > Generate the code, run the migration, and you've got 26 passing
> > RESTful controller specifications.  Salt and hot sauce to taste.
> >
> > http://svn.flpr.org/public/plugins/rspec_resource_generator/
> >
> > Most code shamelessly jacked from the scaffold_resource plugin.  I
> > did, however, write all the specs.  This code released under the
> > DoWhatYouWantWithIt license.
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From pergesu at gmail.com  Sat Nov  4 11:46:40 2006
From: pergesu at gmail.com (Pat Maddox)
Date: Sat, 4 Nov 2006 09:46:40 -0700
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <8d961d900611040129t21903850g8b158f7a7107af54@mail.gmail.com>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
	<8d961d900611040129t21903850g8b158f7a7107af54@mail.gmail.com>
Message-ID: <810a540e0611040846t4bf5017bgd492f26edfa39d0a@mail.gmail.com>

On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > http://svn.flpr.org/public/plugins/rspec_resource_generator/
> >
> > Most code shamelessly jacked from the scaffold_resource plugin.  I
>
> The generators in Rails *will* evolve and copying/forking its code
> will inevitably result in a maintenance nightmare (or obsoletion).
>
> That's why the existing RSpec generators (rspec_model and
> rspec_controller) _reuse_ the templates from Rails instead of forking
> them. The only templates we wrote ourselves are the ones that generate
> the specs. Maintaining that is easy - it's *our* code.
>
> Would you consider refactoring your code according to this principle
> and delete all the duplicated (copied) code? In that case we'll
> include your contribution into RSpec on Rails.
>
> There is already an RFE for it here:
> http://rubyforge.org/tracker/index.php?func=detail&aid=6098&group_id=797&atid=9464

All done.  The only template remaining is the controller_spec
template.  Everything else is pulled from the standard Rails
generators, and the rspec_model generator for the model spec.

Anything else that should be done with that?

Pat

From aslak.hellesoy at gmail.com  Sat Nov  4 16:10:18 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 4 Nov 2006 22:10:18 +0100
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <810a540e0611040846t4bf5017bgd492f26edfa39d0a@mail.gmail.com>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
	<8d961d900611040129t21903850g8b158f7a7107af54@mail.gmail.com>
	<810a540e0611040846t4bf5017bgd492f26edfa39d0a@mail.gmail.com>
Message-ID: <8d961d900611041310q6699ef03p128d1769ac4a9c05@mail.gmail.com>

On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > > http://svn.flpr.org/public/plugins/rspec_resource_generator/
> > >
> > > Most code shamelessly jacked from the scaffold_resource plugin.  I
> >
> > The generators in Rails *will* evolve and copying/forking its code
> > will inevitably result in a maintenance nightmare (or obsoletion).
> >
> > That's why the existing RSpec generators (rspec_model and
> > rspec_controller) _reuse_ the templates from Rails instead of forking
> > them. The only templates we wrote ourselves are the ones that generate
> > the specs. Maintaining that is easy - it's *our* code.
> >
> > Would you consider refactoring your code according to this principle
> > and delete all the duplicated (copied) code? In that case we'll
> > include your contribution into RSpec on Rails.
> >
> > There is already an RFE for it here:
> > http://rubyforge.org/tracker/index.php?func=detail&aid=6098&group_id=797&atid=9464
>
> All done.  The only template remaining is the controller_spec
> template.  Everything else is pulled from the standard Rails
> generators, and the rspec_model generator for the model spec.
>
> Anything else that should be done with that?
>

Not that I know of - sounds great! I'll take a look at it tonight.

Thanks a lot!

Aslak

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

From contact at lukeredpath.co.uk  Sat Nov  4 16:27:50 2006
From: contact at lukeredpath.co.uk (contact at lukeredpath.co.uk)
Date: 4 Nov 2006 21:27:50 +0000
Subject: [rspec-users]
	=?iso-8859-1?q?=5BPLUGIN=5D_rspec_resource_generato?=
	=?iso-8859-1?q?r_-_RESTfulscaffold_generator_with_RSpec_specificat?=
Message-ID: <20061104212848.5F2F7A970010@rubyforge.org>

Hi pat. You misunderstood me. I wasnt looking for credit. :) thanks anyway.

From dchelimsky at gmail.com  Sun Nov  5 01:45:21 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 5 Nov 2006 00:45:21 -0600
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <8d961d900611041310q6699ef03p128d1769ac4a9c05@mail.gmail.com>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
	<8d961d900611040129t21903850g8b158f7a7107af54@mail.gmail.com>
	<810a540e0611040846t4bf5017bgd492f26edfa39d0a@mail.gmail.com>
	<8d961d900611041310q6699ef03p128d1769ac4a9c05@mail.gmail.com>
Message-ID: <57c63afe0611042245q49b10b11la11ea04e5e4bbbdc@mail.gmail.com>

On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > > > http://svn.flpr.org/public/plugins/rspec_resource_generator/
> > > >
> > > > Most code shamelessly jacked from the scaffold_resource plugin.  I
> > >
> > > The generators in Rails *will* evolve and copying/forking its code
> > > will inevitably result in a maintenance nightmare (or obsoletion).
> > >
> > > That's why the existing RSpec generators (rspec_model and
> > > rspec_controller) _reuse_ the templates from Rails instead of forking
> > > them. The only templates we wrote ourselves are the ones that generate
> > > the specs. Maintaining that is easy - it's *our* code.
> > >
> > > Would you consider refactoring your code according to this principle
> > > and delete all the duplicated (copied) code? In that case we'll
> > > include your contribution into RSpec on Rails.
> > >
> > > There is already an RFE for it here:
> > > http://rubyforge.org/tracker/index.php?func=detail&aid=6098&group_id=797&atid=9464
> >
> > All done.  The only template remaining is the controller_spec
> > template.  Everything else is pulled from the standard Rails
> > generators, and the rspec_model generator for the model spec.
> >
> > Anything else that should be done with that?
> >
>
> Not that I know of - sounds great! I'll take a look at it tonight.
>
> Thanks a lot!

Agreed that this is great stuff.

We're about to do a release that has changed some things about which
there seem to be some assumptions in the controller_spec template.

What I'd propose is that we wait until after the release for this. We
can tweak it to fit the newer approaches and then add it to rspec for
the next release.

David

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

From aslak.hellesoy at gmail.com  Sun Nov  5 04:01:22 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 5 Nov 2006 10:01:22 +0100
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <57c63afe0611042245q49b10b11la11ea04e5e4bbbdc@mail.gmail.com>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
	<8d961d900611040129t21903850g8b158f7a7107af54@mail.gmail.com>
	<810a540e0611040846t4bf5017bgd492f26edfa39d0a@mail.gmail.com>
	<8d961d900611041310q6699ef03p128d1769ac4a9c05@mail.gmail.com>
	<57c63afe0611042245q49b10b11la11ea04e5e4bbbdc@mail.gmail.com>
Message-ID: <8d961d900611050101t30068f83r9f03f723d4f867e3@mail.gmail.com>

On 11/5/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > > On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > > > > http://svn.flpr.org/public/plugins/rspec_resource_generator/
> > > > >
> > > > > Most code shamelessly jacked from the scaffold_resource plugin.  I
> > > >
> > > > The generators in Rails *will* evolve and copying/forking its code
> > > > will inevitably result in a maintenance nightmare (or obsoletion).
> > > >
> > > > That's why the existing RSpec generators (rspec_model and
> > > > rspec_controller) _reuse_ the templates from Rails instead of forking
> > > > them. The only templates we wrote ourselves are the ones that generate
> > > > the specs. Maintaining that is easy - it's *our* code.
> > > >
> > > > Would you consider refactoring your code according to this principle
> > > > and delete all the duplicated (copied) code? In that case we'll
> > > > include your contribution into RSpec on Rails.
> > > >
> > > > There is already an RFE for it here:
> > > > http://rubyforge.org/tracker/index.php?func=detail&aid=6098&group_id=797&atid=9464
> > >
> > > All done.  The only template remaining is the controller_spec
> > > template.  Everything else is pulled from the standard Rails
> > > generators, and the rspec_model generator for the model spec.
> > >
> > > Anything else that should be done with that?
> > >
> >
> > Not that I know of - sounds great! I'll take a look at it tonight.
> >
> > Thanks a lot!
>
> Agreed that this is great stuff.
>
> We're about to do a release that has changed some things about which
> there seem to be some assumptions in the controller_spec template.
>
> What I'd propose is that we wait until after the release for this. We
> can tweak it to fit the newer approaches and then add it to rspec for
> the next release.
>

Agreed. Pat, is it ok for you if we steal your code and check it into
RSpec's svn when time is ripe?

You'll be credited here: http://rspec.rubyforge.org/team.html

Aslak

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

From pergesu at gmail.com  Sun Nov  5 08:31:50 2006
From: pergesu at gmail.com (Pat Maddox)
Date: Sun, 5 Nov 2006 06:31:50 -0700
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <8d961d900611050101t30068f83r9f03f723d4f867e3@mail.gmail.com>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
	<8d961d900611040129t21903850g8b158f7a7107af54@mail.gmail.com>
	<810a540e0611040846t4bf5017bgd492f26edfa39d0a@mail.gmail.com>
	<8d961d900611041310q6699ef03p128d1769ac4a9c05@mail.gmail.com>
	<57c63afe0611042245q49b10b11la11ea04e5e4bbbdc@mail.gmail.com>
	<8d961d900611050101t30068f83r9f03f723d4f867e3@mail.gmail.com>
Message-ID: <810a540e0611050531w65fd39e7v28178c17b0d6939e@mail.gmail.com>

On 11/5/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 11/5/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > > > On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > > On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > > > > > http://svn.flpr.org/public/plugins/rspec_resource_generator/
> > > > > >
> > > > > > Most code shamelessly jacked from the scaffold_resource plugin.  I
> > > > >
> > > > > The generators in Rails *will* evolve and copying/forking its code
> > > > > will inevitably result in a maintenance nightmare (or obsoletion).
> > > > >
> > > > > That's why the existing RSpec generators (rspec_model and
> > > > > rspec_controller) _reuse_ the templates from Rails instead of forking
> > > > > them. The only templates we wrote ourselves are the ones that generate
> > > > > the specs. Maintaining that is easy - it's *our* code.
> > > > >
> > > > > Would you consider refactoring your code according to this principle
> > > > > and delete all the duplicated (copied) code? In that case we'll
> > > > > include your contribution into RSpec on Rails.
> > > > >
> > > > > There is already an RFE for it here:
> > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=6098&group_id=797&atid=9464
> > > >
> > > > All done.  The only template remaining is the controller_spec
> > > > template.  Everything else is pulled from the standard Rails
> > > > generators, and the rspec_model generator for the model spec.
> > > >
> > > > Anything else that should be done with that?
> > > >
> > >
> > > Not that I know of - sounds great! I'll take a look at it tonight.
> > >
> > > Thanks a lot!
> >
> > Agreed that this is great stuff.
> >
> > We're about to do a release that has changed some things about which
> > there seem to be some assumptions in the controller_spec template.
> >
> > What I'd propose is that we wait until after the release for this. We
> > can tweak it to fit the newer approaches and then add it to rspec for
> > the next release.
> >
>
> Agreed. Pat, is it ok for you if we steal your code and check it into
> RSpec's svn when time is ripe?
>
> You'll be credited here: http://rspec.rubyforge.org/team.html
>
> Aslak

I'm not sure...that DoWhatYouWantWithIt license is pretty stringent :)

Feel free to put it in whenever you think is good, and make whatever
changes you feel appropriate as David mentioned.

Pat

From dchelimsky at gmail.com  Sun Nov  5 12:01:24 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 5 Nov 2006 11:01:24 -0600
Subject: [rspec-users] [PLUGIN] rspec_resource_generator - RESTful
	scaffold generator with RSpec specifications
In-Reply-To: <810a540e0611050531w65fd39e7v28178c17b0d6939e@mail.gmail.com>
References: <810a540e0611031538l307168d3mf590ed4df2adeea@mail.gmail.com>
	<8d961d900611040129t21903850g8b158f7a7107af54@mail.gmail.com>
	<810a540e0611040846t4bf5017bgd492f26edfa39d0a@mail.gmail.com>
	<8d961d900611041310q6699ef03p128d1769ac4a9c05@mail.gmail.com>
	<57c63afe0611042245q49b10b11la11ea04e5e4bbbdc@mail.gmail.com>
	<8d961d900611050101t30068f83r9f03f723d4f867e3@mail.gmail.com>
	<810a540e0611050531w65fd39e7v28178c17b0d6939e@mail.gmail.com>
Message-ID: <57c63afe0611050901i3ac36afctc3863eea2a479b4b@mail.gmail.com>

On 11/5/06, Pat Maddox <pergesu at gmail.com> wrote:
> On 11/5/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 11/5/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > > > > On 11/4/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > > > > On 11/4/06, Pat Maddox <pergesu at gmail.com> wrote:
> > > > > > > http://svn.flpr.org/public/plugins/rspec_resource_generator/
> > > > > > >
> > > > > > > Most code shamelessly jacked from the scaffold_resource plugin.  I
> > > > > >
> > > > > > The generators in Rails *will* evolve and copying/forking its code
> > > > > > will inevitably result in a maintenance nightmare (or obsoletion).
> > > > > >
> > > > > > That's why the existing RSpec generators (rspec_model and
> > > > > > rspec_controller) _reuse_ the templates from Rails instead of forking
> > > > > > them. The only templates we wrote ourselves are the ones that generate
> > > > > > the specs. Maintaining that is easy - it's *our* code.
> > > > > >
> > > > > > Would you consider refactoring your code according to this principle
> > > > > > and delete all the duplicated (copied) code? In that case we'll
> > > > > > include your contribution into RSpec on Rails.
> > > > > >
> > > > > > There is already an RFE for it here:
> > > > > > http://rubyforge.org/tracker/index.php?func=detail&aid=6098&group_id=797&atid=9464
> > > > >
> > > > > All done.  The only template remaining is the controller_spec
> > > > > template.  Everything else is pulled from the standard Rails
> > > > > generators, and the rspec_model generator for the model spec.
> > > > >
> > > > > Anything else that should be done with that?
> > > > >
> > > >
> > > > Not that I know of - sounds great! I'll take a look at it tonight.
> > > >
> > > > Thanks a lot!
> > >
> > > Agreed that this is great stuff.
> > >
> > > We're about to do a release that has changed some things about which
> > > there seem to be some assumptions in the controller_spec template.
> > >
> > > What I'd propose is that we wait until after the release for this. We
> > > can tweak it to fit the newer approaches and then add it to rspec for
> > > the next release.
> > >
> >
> > Agreed. Pat, is it ok for you if we steal your code and check it into
> > RSpec's svn when time is ripe?
> >
> > You'll be credited here: http://rspec.rubyforge.org/team.html
> >
> > Aslak
>
> I'm not sure...that DoWhatYouWantWithIt license is pretty stringent :)
>
> Feel free to put it in whenever you think is good, and make whatever
> changes you feel appropriate as David mentioned.

Great! Thank you Pat. This will actually serve as a great example of
how we think these specs should look.

Cheers,
David

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

From lists-rspec at shopwatch.org  Sun Nov  5 21:32:36 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Sun, 05 Nov 2006 21:32:36 -0500
Subject: [rspec-users] Integration testing: coupling of get and post on forms
Message-ID: <454E9EC4.2090904@jay.fm>

This is such a vague request it's not even worthy of a ticket, but:

When rspec does support integration testing, it'd be really nice to be 
able to do things like this plugin does for standard Rails tests:

http://www.jasongarber.com/articles/2006/10/24/easier-testing-of-forms-form_test_helper

In a nutshell, it finally closes the loop between "the empty form sent 
by a get" and "the filled-in form returned on a post".  Instead of 
blindly posting parameters, you're now actually filling in form fields 
in the tests.  Works with hidden fields and everything, too. 

It'd be nice to see rspec do something like that.

Jay Levitt


From dchelimsky at gmail.com  Sun Nov  5 21:49:34 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 5 Nov 2006 20:49:34 -0600
Subject: [rspec-users] Integration testing: coupling of get and post on
	forms
In-Reply-To: <454E9EC4.2090904@jay.fm>
References: <454E9EC4.2090904@jay.fm>
Message-ID: <57c63afe0611051849l460f5b58u7f357c378d57ef44@mail.gmail.com>

On 11/5/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> This is such a vague request it's not even worthy of a ticket, but:

This is completely worthy of a ticket. Please feel free to raise one.

>
> When rspec does support integration testing, it'd be really nice to be
> able to do things like this plugin does for standard Rails tests:
>
> http://www.jasongarber.com/articles/2006/10/24/easier-testing-of-forms-form_test_helper
>
> In a nutshell, it finally closes the loop between "the empty form sent
> by a get" and "the filled-in form returned on a post".  Instead of
> blindly posting parameters, you're now actually filling in form fields
> in the tests.  Works with hidden fields and everything, too.
>
> It'd be nice to see rspec do something like that.
>
> Jay Levitt
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Tue Nov  7 08:23:30 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 7 Nov 2006 07:23:30 -0600
Subject: [rspec-users] View Spec Tutorial
Message-ID: <57c63afe0611070523n3c7c8354me05c48735589fac7@mail.gmail.com>

I've put together a little tutorial to get you started on spec'ing views:

http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial

If you have questions or wish to provide feedback, please do so in
comments on the blog.

Thanks,
David

From phlip2005 at gmail.com  Tue Nov  7 11:37:11 2006
From: phlip2005 at gmail.com (Phlip)
Date: Tue, 7 Nov 2006 08:37:11 -0800
Subject: [rspec-users] Wiki -> RSpec -> Watir
Message-ID: <029e01c7028a$fafcc380$81a1b04c@Marley>

Rubies & Acceptance Testers:

For those of you not doing acceptance tests yet, I have a very slick test 
rig to show off. I haven't demo-ized it yet, so please accept these diverse 
audiovisual displays as if they were a united whole!

We start with MiniRubyWiki, at this demo:

http://www.zeroplayer.com/cgi-bin/wiki?TestFlea

Click on any of the green bars.

Now imagine if the left graphic were a thumbnail of a screenshot of a web 
page. You could click on the thumbnail and get the complete screenshot. This 
would be a copy of the tested website, in its tested state, with its 
intermediate data.

To drive that test, in the right panel I put RSpec and Watir. So the code to 
log into a website would look like this:

    input_text 'login', 'quentin'
    input_text 'password', 'test'
    click_button 'commit'
    @browser.should_contain('Logged in successfully')
    @browser.should_contain('greetings quentin')

The point of RSpec is syntactic sugar, and I have not yet learned how much 
sweeter I can make that. So far, I have learned how to use it to make 
well-formed English sentences (modulo all the _() delimiter crap!).

Writing acceptance tests with this system is just plain fun. Click one of 
the quill icons next to the green bars.

Before or after I write a new feature, I find a similar test and clone it. 
(Cloning a test is a best-practice in Acceptance Test land, so long as you 
frequently merge things back into features!) Then I edit the new test to 
advance its behavior.

The test cases all go into an XML file (_not_ a Wiki file!). At test time, 
Wiki calls a test runner to run one case in that file. The test runner 
without arguments runs all the cases in all the relevant XML files. It 
stitches together the RSpec environment, tests all the cases, and then 
changes each case's result_color to reflect its passing state.

What feature should I add next?

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


From lists-rspec at shopwatch.org  Tue Nov  7 14:31:22 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 07 Nov 2006 14:31:22 -0500
Subject: [rspec-users] should_redirect_to in advance - feels unnatural
Message-ID: <4550DF0A.8000001@jay.fm>

I can understand that it's easier for rspec to set up a mock in advance 
of the controller call.  But it makes it difficult to do something like:

context "The HarkController, given Louie the logged-in user" do
  setup do
    post :login, :username => 'louie', :password => 'atest'
  end

  specify "should redirect Louie to the home page"...

  specify "should set Louie to be the current user"...

end

Instead, I have to break out the should-redirect into its own call, 
since the post is done at setup time, but that's not an appropriate 
place for a spec.

What's the right solution?

Jay Levitt


From dchelimsky at gmail.com  Tue Nov  7 15:02:50 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 7 Nov 2006 14:02:50 -0600
Subject: [rspec-users] should_redirect_to in advance - feels unnatural
In-Reply-To: <4550DF0A.8000001@jay.fm>
References: <4550DF0A.8000001@jay.fm>
Message-ID: <57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>

On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> I can understand that it's easier for rspec to set up a mock in advance
> of the controller call.

This was a philosophical choice, not a cop-out to make it easier to
implement. That sounds more defensive than it is meant to be. I just
want to assure you that our goal is to create the right API.

> But it makes it difficult to do something like:
>
> context "The HarkController, given Louie the logged-in user" do
>   setup do
>     post :login, :username => 'louie', :password => 'atest'
>   end
>
>   specify "should redirect Louie to the home page"...
>
>   specify "should set Louie to be the current user"...
>
> end
>
> Instead, I have to break out the should-redirect into its own call,
> since the post is done at setup time, but that's not an appropriate
> place for a spec.

The BDD way, at least as I see it, is rooted in the TDD way:

1. setup objects in a known starting state (setup - perhaps stubs)
2. set expectations of how the object should react to an action (mocks)
3. perform the action
4. verify that the object reacted as expected (verify mocks plus
additional assert-like expectations)

The setup/specify structure is intended to let you step 1 (setup) in
the setup and do whatever combination of 2-4 that you like in specify.
In my view, the post is the action, and it belongs in the specify
block in this case.

The problem there is that it doesn't feel DRY. That's a problem I'm
interested in solving, but I'd prefer to do it in a way that helps to
express the behaviour-driven nature of BDD. What that means yet I'm
not sure. I have a couple of ideas that I'll share as they become
slightly more fully baked. I'd love to hear yours in the mean time.

What I'm doing for examples like yours above is adding a method for
the post and calling it from each of my specify blocks. Still not
completely DRY, but it tells the story. And that is much more
important to me than the risk of having to change something in more
than one place in a spec.

As for before or after the action, we did add
controller.should_have_rendered for after. We could do something
similar: controller.should_have_redirected_to. Or we could do what I
originally had in there which was that should_render was smart enough
to work on either side of the action. Looking at a few specs, I found
that to be more confusing and, hence, split into 'before' and 'after'
forms.

Of these options, what do you like, and what not?

Thanks for playing,
David


>
> What's the right solution?
>
> Jay Levitt
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From lists-rspec at shopwatch.org  Tue Nov  7 15:31:12 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 07 Nov 2006 15:31:12 -0500
Subject: [rspec-users] should_redirect_to in advance - feels unnatural
In-Reply-To: <57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>
References: <4550DF0A.8000001@jay.fm>
	<57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>
Message-ID: <4550ED10.4030704@rubyforge.org>

David Chelimsky wrote:
> On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>> I can understand that it's easier for rspec to set up a mock in advance
>> of the controller call.
> 
> This was a philosophical choice, not a cop-out to make it easier to
> implement. That sounds more defensive than it is meant to be. I just
> want to assure you that our goal is to create the right API.

No, I completely understand...

> 
>> But it makes it difficult to do something like:
>>
>> context "The HarkController, given Louie the logged-in user" do
>>   setup do
>>     post :login, :username => 'louie', :password => 'atest'
>>   end
> The BDD way, at least as I see it, is rooted in the TDD way:
> 
> 1. setup objects in a known starting state (setup - perhaps stubs)
> 2. set expectations of how the object should react to an action (mocks)
> 3. perform the action
> 4. verify that the object reacted as expected (verify mocks plus
> additional assert-like expectations)

I think the problem I'm having (and that David Lee is having as well) is 
that sometimes I'd like setup to involve an action.  It seems the answer 
may be that "the BDD way, at the controller-spec level, is to stub the 
initial action so you've got a known state."  I guess I've been writing 
semi-integration specs in that regard.
> 
> The problem there is that it doesn't feel DRY. That's a problem I'm
> interested in solving, but I'd prefer to do it in a way that helps to
> express the behaviour-driven nature of BDD. What that means yet I'm
> not sure. I have a couple of ideas that I'll share as they become
> slightly more fully baked. I'd love to hear yours in the mean time.

I don't suppose "It worked in 0.6.4!" counts as an idea?

Seriously, I suspect that the arrival of integration specs may solve 
this, because it could be argued that I've really been writing 
integration specs if my specs involve two or more controller actions.  I 
would intensely dislike the person who argued that, because they'd be 
making me write more thorough controller-level specs and dive into 
mocking, but I'd probably forgive them when this made my code more robust.

Of course, the problem is that now I don't have the integration-like 
functionality that 0.6.4 had, so while I can create stubs to do the 
right thing at the controller level, I've lost the ability to test "X 
works after logging in".

> What I'm doing for examples like yours above is adding a method for
> the post and calling it from each of my specify blocks. Still not
> completely DRY, but it tells the story. And that is much more
> important to me than the risk of having to change something in more
> than one place in a spec.

To me, that's what "setup" was for - but, again, can setup legitimately 
be a controller action?  Mmmmmaybe.

In any case, as I just discovered, putting the login in a method call 
won't work, because rspec no longer likes two controller actions in a 
single spec, period.

> As for before or after the action, we did add
> controller.should_have_rendered for after. We could do something
> similar: controller.should_have_redirected_to. Or we could do what I
> originally had in there which was that should_render was smart enough
> to work on either side of the action. Looking at a few specs, I found
> that to be more confusing and, hence, split into 'before' and 'after'
> forms.
> 
> Of these options, what do you like, and what not?

I would like "should_render" to be smart; I think the past-tense thing 
is confusing.  Ditto should_redirect_to.  But I don't have very strong 
feelings about that one.

Jay


From aslak.hellesoy at gmail.com  Tue Nov  7 15:43:54 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 7 Nov 2006 21:43:54 +0100
Subject: [rspec-users] should_redirect_to in advance - feels unnatural
In-Reply-To: <57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>
References: <4550DF0A.8000001@jay.fm>
	<57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>
Message-ID: <8d961d900611071243u5f59f04l7241b2e57938a77f@mail.gmail.com>

On 11/7/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> > I can understand that it's easier for rspec to set up a mock in advance
> > of the controller call.
>
> This was a philosophical choice, not a cop-out to make it easier to
> implement. That sounds more defensive than it is meant to be. I just
> want to assure you that our goal is to create the right API.
>
> > But it makes it difficult to do something like:
> >
> > context "The HarkController, given Louie the logged-in user" do
> >   setup do
> >     post :login, :username => 'louie', :password => 'atest'
> >   end
> >
> >   specify "should redirect Louie to the home page"...
> >
> >   specify "should set Louie to be the current user"...
> >
> > end
> >
> > Instead, I have to break out the should-redirect into its own call,
> > since the post is done at setup time, but that's not an appropriate
> > place for a spec.
>
> The BDD way, at least as I see it, is rooted in the TDD way:
>
> 1. setup objects in a known starting state (setup - perhaps stubs)
> 2. set expectations of how the object should react to an action (mocks)
> 3. perform the action
> 4. verify that the object reacted as expected (verify mocks plus
> additional assert-like expectations)
>
> The setup/specify structure is intended to let you step 1 (setup) in
> the setup and do whatever combination of 2-4 that you like in specify.
> In my view, the post is the action, and it belongs in the specify
> block in this case.
>

Agreed. Consider the GWT* format (which I encourage people to use). A
typical acceptance criterion similar to your example could be:

GIVEN A new HarkController
AND Louie logged in
WHEN Louie logs out
THEN He is redirected to the frontpage

context "A new HarkController and Louie logged in" do # GIVEN
  setup do # GIVEN
    controller.should_redirect_to :action => 'homepage'
    post :login, :username => 'louie', :password => 'atest'
  end

  specify "Should redirect Louie to the homepage when he logs out" #
THEN and WHEN
    controller.should_redirect_to :action => 'frontpage'
    post :logout
  end
end

* http://www.dannorth.net/introducing-bdd
* http://jayfields.blogspot.com/2006/11/story-card-format.html (My comment)

Thinking in terms of GWT and knowing how to map them to RSpec will
make spec writing much easier I think.

> The problem there is that it doesn't feel DRY. That's a problem I'm
> interested in solving, but I'd prefer to do it in a way that helps to
> express the behaviour-driven nature of BDD. What that means yet I'm
> not sure. I have a couple of ideas that I'll share as they become
> slightly more fully baked. I'd love to hear yours in the mean time.
>
> What I'm doing for examples like yours above is adding a method for
> the post and calling it from each of my specify blocks. Still not
> completely DRY, but it tells the story. And that is much more
> important to me than the risk of having to change something in more
> than one place in a spec.
>
> As for before or after the action, we did add
> controller.should_have_rendered for after. We could do something
> similar: controller.should_have_redirected_to. Or we could do what I
> originally had in there which was that should_render was smart enough
> to work on either side of the action. Looking at a few specs, I found
> that to be more confusing and, hence, split into 'before' and 'after'
> forms.
>
> Of these options, what do you like, and what not?
>
> Thanks for playing,
> David
>
>
> >
> > What's the right solution?
> >
> > Jay Levitt
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From aslak.hellesoy at gmail.com  Tue Nov  7 15:46:37 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 7 Nov 2006 21:46:37 +0100
Subject: [rspec-users] should_redirect_to in advance - feels unnatural
In-Reply-To: <8d961d900611071243u5f59f04l7241b2e57938a77f@mail.gmail.com>
References: <4550DF0A.8000001@jay.fm>
	<57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>
	<8d961d900611071243u5f59f04l7241b2e57938a77f@mail.gmail.com>
Message-ID: <8d961d900611071246y3406b964o7fc03c65cd1ebff6@mail.gmail.com>

On 11/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 11/7/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> > > I can understand that it's easier for rspec to set up a mock in advance
> > > of the controller call.
> >
> > This was a philosophical choice, not a cop-out to make it easier to
> > implement. That sounds more defensive than it is meant to be. I just
> > want to assure you that our goal is to create the right API.
> >
> > > But it makes it difficult to do something like:
> > >
> > > context "The HarkController, given Louie the logged-in user" do
> > >   setup do
> > >     post :login, :username => 'louie', :password => 'atest'
> > >   end
> > >
> > >   specify "should redirect Louie to the home page"...
> > >
> > >   specify "should set Louie to be the current user"...
> > >
> > > end
> > >
> > > Instead, I have to break out the should-redirect into its own call,
> > > since the post is done at setup time, but that's not an appropriate
> > > place for a spec.
> >
> > The BDD way, at least as I see it, is rooted in the TDD way:
> >
> > 1. setup objects in a known starting state (setup - perhaps stubs)
> > 2. set expectations of how the object should react to an action (mocks)
> > 3. perform the action
> > 4. verify that the object reacted as expected (verify mocks plus
> > additional assert-like expectations)
> >
> > The setup/specify structure is intended to let you step 1 (setup) in
> > the setup and do whatever combination of 2-4 that you like in specify.
> > In my view, the post is the action, and it belongs in the specify
> > block in this case.
> >
>
> Agreed. Consider the GWT* format (which I encourage people to use). A
> typical acceptance criterion similar to your example could be:
>
> GIVEN A new HarkController
> AND Louie logged in
> WHEN Louie logs out
> THEN He is redirected to the frontpage
>
> context "A new HarkController and Louie logged in" do # GIVEN
>   setup do # GIVEN
>     controller.should_redirect_to :action => 'homepage'
>     post :login, :username => 'louie', :password => 'atest'

# Or better, since it doesn't do the extra action:
session[:user] = User.new

>   end
>
>   specify "Should redirect Louie to the homepage when he logs out" #
> THEN and WHEN
>     controller.should_redirect_to :action => 'frontpage'
>     post :logout
>   end
> end
>
> * http://www.dannorth.net/introducing-bdd
> * http://jayfields.blogspot.com/2006/11/story-card-format.html (My comment)
>
> Thinking in terms of GWT and knowing how to map them to RSpec will
> make spec writing much easier I think.
>
> > The problem there is that it doesn't feel DRY. That's a problem I'm
> > interested in solving, but I'd prefer to do it in a way that helps to
> > express the behaviour-driven nature of BDD. What that means yet I'm
> > not sure. I have a couple of ideas that I'll share as they become
> > slightly more fully baked. I'd love to hear yours in the mean time.
> >
> > What I'm doing for examples like yours above is adding a method for
> > the post and calling it from each of my specify blocks. Still not
> > completely DRY, but it tells the story. And that is much more
> > important to me than the risk of having to change something in more
> > than one place in a spec.
> >
> > As for before or after the action, we did add
> > controller.should_have_rendered for after. We could do something
> > similar: controller.should_have_redirected_to. Or we could do what I
> > originally had in there which was that should_render was smart enough
> > to work on either side of the action. Looking at a few specs, I found
> > that to be more confusing and, hence, split into 'before' and 'after'
> > forms.
> >
> > Of these options, what do you like, and what not?
> >
> > Thanks for playing,
> > David
> >
> >
> > >
> > > What's the right solution?
> > >
> > > Jay Levitt
> > >
> > > _______________________________________________
> > > rspec-users mailing list
> > > rspec-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>

From dchelimsky at gmail.com  Tue Nov  7 15:52:02 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 7 Nov 2006 14:52:02 -0600
Subject: [rspec-users] should_redirect_to in advance - feels unnatural
In-Reply-To: <4550ED10.4030704@rubyforge.org>
References: <4550DF0A.8000001@jay.fm>
	<57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>
	<4550ED10.4030704@rubyforge.org>
Message-ID: <57c63afe0611071252j25c31433m224501ba063dc46b@mail.gmail.com>

On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> David Chelimsky wrote:
> > On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> >> I can understand that it's easier for rspec to set up a mock in advance
> >> of the controller call.
> >
> > This was a philosophical choice, not a cop-out to make it easier to
> > implement. That sounds more defensive than it is meant to be. I just
> > want to assure you that our goal is to create the right API.
>
> No, I completely understand...
>
> >
> >> But it makes it difficult to do something like:
> >>
> >> context "The HarkController, given Louie the logged-in user" do
> >>   setup do
> >>     post :login, :username => 'louie', :password => 'atest'
> >>   end
> > The BDD way, at least as I see it, is rooted in the TDD way:
> >
> > 1. setup objects in a known starting state (setup - perhaps stubs)
> > 2. set expectations of how the object should react to an action (mocks)
> > 3. perform the action
> > 4. verify that the object reacted as expected (verify mocks plus
> > additional assert-like expectations)
>
> I think the problem I'm having (and that David Lee is having as well) is
> that sometimes I'd like setup to involve an action.  It seems the answer
> may be that "the BDD way, at the controller-spec level, is to stub the
> initial action so you've got a known state."  I guess I've been writing
> semi-integration specs in that regard.

I can see this if you need one action to get you to a state and
another to set expectations about. I wonder if we can get the state
correct a different way - like setting the user in the session.

The problem becomes when the login breaks for some reason, under some
conditions, and other specs fail because you're using the login action
everywhere. Make sense?
> >
> > The problem there is that it doesn't feel DRY. That's a problem I'm
> > interested in solving, but I'd prefer to do it in a way that helps to
> > express the behaviour-driven nature of BDD. What that means yet I'm
> > not sure. I have a couple of ideas that I'll share as they become
> > slightly more fully baked. I'd love to hear yours in the mean time.
>
> I don't suppose "It worked in 0.6.4!" counts as an idea?

:)

The original plugin was a great solution to the wrong problem. It was
a way to get rails coverage in rspec as a test/unit substitute w/ sexy
should_be_this_and_that syntax. Everyone (including me) was excited to
be able to do SOMETHING vis a vis rails. It was not, however,
considered very deeply in the context of a BDD framework.

Until we get to 1.0, I think we all just need to live w/ some changes
to the API. I'm confident that what is in place now will not change
significantly, and that we'll mostly be adding to it and not changing
what's there. That said, I feel, and I think I speak for the rest of
the committers, that it's more important to get the right API than to
be constrained by the hacks that came before. If we start living
within that constraint, we'll have no choice but to stop adding new
stuff at the rate at which we do.

Make sense?

> Seriously, I suspect that the arrival of integration specs may solve
> this, because it could be argued that I've really been writing
> integration specs if my specs involve two or more controller actions.  I
> would intensely dislike the person who argued that, because they'd be
> making me write more thorough controller-level specs and dive into
> mocking, but I'd probably forgive them when this made my code more robust.
>
> Of course, the problem is that now I don't have the integration-like
> functionality that 0.6.4 had, so while I can create stubs to do the
> right thing at the controller level, I've lost the ability to test "X
> works after logging in".

That's a problem - we'll solve it.

>
> > What I'm doing for examples like yours above is adding a method for
> > the post and calling it from each of my specify blocks. Still not
> > completely DRY, but it tells the story. And that is much more
> > important to me than the risk of having to change something in more
> > than one place in a spec.
>
> To me, that's what "setup" was for - but, again, can setup legitimately
> be a controller action?  Mmmmmaybe.

Ditto what I was saying before. You could argue that you should be
able to do anything you need to do in the setup to get you there. I'd
agree with that argument. But I'd hate to have dependencies across two
actions in what are supposed to be very granular specs.

>
> In any case, as I just discovered, putting the login in a method call
> won't work, because rspec no longer likes two controller actions in a
> single spec, period.

We're going to have to solve that for integration specs. When we do,
we'll be able to support it in controller specs too.

> > As for before or after the action, we did add
> > controller.should_have_rendered for after. We could do something
> > similar: controller.should_have_redirected_to. Or we could do what I
> > originally had in there which was that should_render was smart enough
> > to work on either side of the action. Looking at a few specs, I found
> > that to be more confusing and, hence, split into 'before' and 'after'
> > forms.
> >
> > Of these options, what do you like, and what not?
>
> I would like "should_render" to be smart; I think the past-tense thing
> is confusing.  Ditto should_redirect_to.  But I don't have very strong
> feelings about that one.

My thinking right now is that we'll support definitely before and
after one way or the other. The question then becomes whether we use
the past tense or not. My inclination is to use it in order to expose
the differences between before and after. I think it will help to
understand failures when you go back to look at a spec you wrote some
time ago.

Other opinions?

>
> Jay

Again, thanks for playing. This is the sort of feedback we need more of.

Cheers,
David

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

From lists-rspec at shopwatch.org  Tue Nov  7 16:28:31 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 07 Nov 2006 16:28:31 -0500
Subject: [rspec-users] RSpec/Selenium start_browser_once patch?
Message-ID: <4550FA7F.5030700@shopwatch.org>

The 0.7.0 vendor/selenium/README.txt references a 
"start_browser_once.patch" file.  This doesn't seem to be included in 
either the rspec or selenium-rc distributions, and Google finds 
nothing... where might I find that patch?

Jay Levitt


From jerry.west at ntlworld.com  Tue Nov  7 16:56:23 2006
From: jerry.west at ntlworld.com (Jerry West)
Date: Tue, 07 Nov 2006 21:56:23 +0000
Subject: [rspec-users] include Helper in context?
Message-ID: <45510107.5040308@ntlworld.com>

Brandon,

can you get your Helpers to work in rspec 0.7 ?  I'm including them in 
the context but the render fails to see it.

If you have it working, I'll go back and bang my head against it some 
more, otherwise I'll file a bug!

Many thanks,
  Jerry

context "account/login (view)" do 
  include StandardHelpers
  specify 'displays title "Login"' do
    self.methods.should_include 'title'
    render 'account/login'
    response.should_have_tag 'h1', :content => 'Login'
  end
end
# fails with:
ActionView::TemplateError in 'account/login (view) displays title "Login"'
undefined method `title' for #<#<Class:0xb73154ac>:0xb7314f70>
On line #1 of app/views/account/login.rhtml

    1: <% title 'Login' %>		(a yield block in the layout)

Note that methods.should_include 'title' passes!


From lists-rspec at shopwatch.org  Tue Nov  7 17:41:16 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 07 Nov 2006 17:41:16 -0500
Subject: [rspec-users] Should Selenium support be doing rollbacks?
Message-ID: <45510B8C.6090402@jay.fm>

Now that 0.7.0 is forcing me to write properly compartmented specs, I 
thought I'd give the "dead easy Selenium support" a try.

Is it supposed to all the things that rspec normally does for me, or is 
it just for using rspec-like grammar to surround Selenium tests?  
Specifically, should it roll back the database between specifications?  
I just did a quick test, and the result of running a Selenium test seems 
to stay in the database.

Jay Levitt


From lists-rspec at shopwatch.org  Tue Nov  7 17:53:21 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 07 Nov 2006 17:53:21 -0500
Subject: [rspec-users] Should Selenium support be doing rollbacks?
In-Reply-To: <45510B8C.6090402@jay.fm>
References: <45510B8C.6090402@jay.fm>
Message-ID: <45510E61.2020407@rubyforge.org>

Jay Levitt wrote:
> Now that 0.7.0 is forcing me to write properly compartmented specs, I 
> thought I'd give the "dead easy Selenium support" a try.
> 
> Is it supposed to all the things that rspec normally does for me, or is 
> it just for using rspec-like grammar to surround Selenium tests?  
> Specifically, should it roll back the database between specifications?  

No, Jay, because there's no way it could possibly wrap the test in a 
transaction when the test is being executed by a different process...

That does leave the question of "how do I test things that create unique 
records when I can only do that once?", but that's a generic Selenium 
question, I suppose, not an rspec one.

Jay


From aslak.hellesoy at gmail.com  Tue Nov  7 19:53:36 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 8 Nov 2006 01:53:36 +0100
Subject: [rspec-users] RSpec/Selenium start_browser_once patch?
In-Reply-To: <4550FA7F.5030700@shopwatch.org>
References: <4550FA7F.5030700@shopwatch.org>
Message-ID: <8d961d900611071653w778904fqebc79e572368879d@mail.gmail.com>

On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> The 0.7.0 vendor/selenium/README.txt references a
> "start_browser_once.patch" file.  This doesn't seem to be included in
> either the rspec or selenium-rc distributions, and Google finds
> nothing... where might I find that patch?
>
> Jay Levitt

In Subversion ;-)

I have fixed the Rakefile so it will be in the next release distros.

Aslak

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

From dchelimsky at gmail.com  Tue Nov  7 20:10:28 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 7 Nov 2006 19:10:28 -0600
Subject: [rspec-users] include Helper in context?
In-Reply-To: <45510107.5040308@ntlworld.com>
References: <45510107.5040308@ntlworld.com>
Message-ID: <57c63afe0611071710i44067d19oc5d1a7d69b08b666@mail.gmail.com>

On 11/7/06, Jerry West <jerry.west at ntlworld.com> wrote:
> Brandon,
>
> can you get your Helpers to work in rspec 0.7 ?  I'm including them in
> the context but the render fails to see it.
>
> If you have it working, I'll go back and bang my head against it some
> more, otherwise I'll file a bug!
>
> Many thanks,
>   Jerry
>
> context "account/login (view)" do
>   include StandardHelpers
>   specify 'displays title "Login"' do
>     self.methods.should_include 'title'
>     render 'account/login'
>     response.should_have_tag 'h1', :content => 'Login'
>   end
> end

Is this a view spec or a helper spec? If it's a view spec, it must be
in a views directory:

spec/views/**/*_spec.rb

http://rspec.rubyforge.org/documentation/rails/writing/index.html

Let us know if that solves your problem.

Thanks,
David

> # fails with:
> ActionView::TemplateError in 'account/login (view) displays title "Login"'
> undefined method `title' for #<#<Class:0xb73154ac>:0xb7314f70>
> On line #1 of app/views/account/login.rhtml
>
>     1: <% title 'Login' %>              (a yield block in the layout)
>
> Note that methods.should_include 'title' passes!
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Tue Nov  7 20:14:54 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 7 Nov 2006 19:14:54 -0600
Subject: [rspec-users] should_redirect_to in advance - feels unnatural
In-Reply-To: <8d961d900611071246y3406b964o7fc03c65cd1ebff6@mail.gmail.com>
References: <4550DF0A.8000001@jay.fm>
	<57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>
	<8d961d900611071243u5f59f04l7241b2e57938a77f@mail.gmail.com>
	<8d961d900611071246y3406b964o7fc03c65cd1ebff6@mail.gmail.com>
Message-ID: <57c63afe0611071714h44b9e81fv38fdb2c9c847ea4@mail.gmail.com>

On 11/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 11/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 11/7/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 11/7/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> > > > I can understand that it's easier for rspec to set up a mock in advance
> > > > of the controller call.
> > >
> > > This was a philosophical choice, not a cop-out to make it easier to
> > > implement. That sounds more defensive than it is meant to be. I just
> > > want to assure you that our goal is to create the right API.
> > >
> > > > But it makes it difficult to do something like:
> > > >
> > > > context "The HarkController, given Louie the logged-in user" do
> > > >   setup do
> > > >     post :login, :username => 'louie', :password => 'atest'
> > > >   end
> > > >
> > > >   specify "should redirect Louie to the home page"...
> > > >
> > > >   specify "should set Louie to be the current user"...
> > > >
> > > > end
> > > >
> > > > Instead, I have to break out the should-redirect into its own call,
> > > > since the post is done at setup time, but that's not an appropriate
> > > > place for a spec.
> > >
> > > The BDD way, at least as I see it, is rooted in the TDD way:
> > >
> > > 1. setup objects in a known starting state (setup - perhaps stubs)
> > > 2. set expectations of how the object should react to an action (mocks)
> > > 3. perform the action
> > > 4. verify that the object reacted as expected (verify mocks plus
> > > additional assert-like expectations)
> > >
> > > The setup/specify structure is intended to let you step 1 (setup) in
> > > the setup and do whatever combination of 2-4 that you like in specify.
> > > In my view, the post is the action, and it belongs in the specify
> > > block in this case.
> > >
> >
> > Agreed. Consider the GWT* format (which I encourage people to use). A
> > typical acceptance criterion similar to your example could be:
> >
> > GIVEN A new HarkController
> > AND Louie logged in
> > WHEN Louie logs out
> > THEN He is redirected to the frontpage
> >
> > context "A new HarkController and Louie logged in" do # GIVEN
> >   setup do # GIVEN
> >     controller.should_redirect_to :action => 'homepage'
> >     post :login, :username => 'louie', :password => 'atest'
>
> # Or better, since it doesn't do the extra action:
> session[:user] = User.new

I like that a LOT better, because a failure in the login process won't
cause this spec to fail. Better isolation.

Thanks,
David

>
> >   end
> >
> >   specify "Should redirect Louie to the homepage when he logs out" #
> > THEN and WHEN
> >     controller.should_redirect_to :action => 'frontpage'
> >     post :logout
> >   end
> > end
> >
> > * http://www.dannorth.net/introducing-bdd
> > * http://jayfields.blogspot.com/2006/11/story-card-format.html (My comment)
> >
> > Thinking in terms of GWT and knowing how to map them to RSpec will
> > make spec writing much easier I think.
> >
> > > The problem there is that it doesn't feel DRY. That's a problem I'm
> > > interested in solving, but I'd prefer to do it in a way that helps to
> > > express the behaviour-driven nature of BDD. What that means yet I'm
> > > not sure. I have a couple of ideas that I'll share as they become
> > > slightly more fully baked. I'd love to hear yours in the mean time.
> > >
> > > What I'm doing for examples like yours above is adding a method for
> > > the post and calling it from each of my specify blocks. Still not
> > > completely DRY, but it tells the story. And that is much more
> > > important to me than the risk of having to change something in more
> > > than one place in a spec.
> > >
> > > As for before or after the action, we did add
> > > controller.should_have_rendered for after. We could do something
> > > similar: controller.should_have_redirected_to. Or we could do what I
> > > originally had in there which was that should_render was smart enough
> > > to work on either side of the action. Looking at a few specs, I found
> > > that to be more confusing and, hence, split into 'before' and 'after'
> > > forms.
> > >
> > > Of these options, what do you like, and what not?
> > >
> > > Thanks for playing,
> > > David
> > >
> > >
> > > >
> > > > What's the right solution?
> > > >
> > > > Jay Levitt
> > > >
> > > > _______________________________________________
> > > > rspec-users mailing list
> > > > rspec-users at rubyforge.org
> > > > http://rubyforge.org/mailman/listinfo/rspec-users
> > > >
> > > _______________________________________________
> > > rspec-users mailing list
> > > rspec-users at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-users
> > >
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From bhelmkamp at gmail.com  Wed Nov  8 02:53:06 2006
From: bhelmkamp at gmail.com (Bryan Helmkamp)
Date: Wed, 8 Nov 2006 02:53:06 -0500
Subject: [rspec-users] should_redirect_to in advance - feels unnatural
In-Reply-To: <57c63afe0611071714h44b9e81fv38fdb2c9c847ea4@mail.gmail.com>
References: <4550DF0A.8000001@jay.fm>
	<57c63afe0611071202t3b5fbe83t2397592d0c5ff43b@mail.gmail.com>
	<8d961d900611071243u5f59f04l7241b2e57938a77f@mail.gmail.com>
	<8d961d900611071246y3406b964o7fc03c65cd1ebff6@mail.gmail.com>
	<57c63afe0611071714h44b9e81fv38fdb2c9c847ea4@mail.gmail.com>
Message-ID: <c0b8beca0611072353n441809c8h6df73198d0b17d6f@mail.gmail.com>

On 11/7/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 11/7/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > # Or better, since it doesn't do the extra action:
> > session[:user] = User.new
>
> I like that a LOT better, because a failure in the login process won't
> cause this spec to fail. Better isolation.

On one of my projects, I do this in the setup method a lot:

@controller.expects(:logged_in?).returns(true)

That's a one liner that made me love mocks.

-Bryan

-- 
http://www.MyCongress.org/ -- coming soon

From jerry.west at ntlworld.com  Wed Nov  8 03:44:13 2006
From: jerry.west at ntlworld.com (Jerry West)
Date: Wed, 08 Nov 2006 08:44:13 +0000
Subject: [rspec-users] include Helper in context?
In-Reply-To: <57c63afe0611071710i44067d19oc5d1a7d69b08b666@mail.gmail.com>
References: <45510107.5040308@ntlworld.com>
	<57c63afe0611071710i44067d19oc5d1a7d69b08b666@mail.gmail.com>
Message-ID: <455198DD.2020807@ntlworld.com>

> Is this a view spec or a helper spec? If it's a view spec, it must be
> in a views directory:

It's a view spec and it is now in spec/views/account/login_spec.rb; but 
still fails :-( . I also do not know what is actually performing the 
render - what should I be examining in the debugger?  I've looked at 
self (within specify) and extended it manually with the helper module 
but to no avail.

I have also tried this:

class X
  include StandardHelpers
end

context "Given a fresh login" do
  include StandardHelpers  

  specify 'the account/login view should ask for the user\'s email' do
    X.new.should_respond_to 'title'    
    render 'account/login'
    response.should_have_tag 'hi', :content => 'Login'
  end
end


which still fails on the render but (presumably) the 
"X.new.should_respond_to 'title'" has worked which at least shows that 
StandardHelpers are available to be included.

Weird.

BTW:

setup do
  self.extend(StandardHelpers)
end

doesn't work either :-( .

Many thanks,
  Jerry

> Is this a view spec or a helper spec? If it's a view spec, it must be
> in a views directory:
>
> spec/views/**/*_spec.rb
>
> http://rspec.rubyforge.org/documentation/rails/writing/index.html
>
> Let us know if that solves your problem.
>
> Thanks,
> David
>
>   
>> # fails with:
>> ActionView::TemplateError in 'account/login (view) displays title "Login"'
>> undefined method `title' for #<#<Class:0xb73154ac>:0xb7314f70>
>> On line #1 of app/views/account/login.rhtml
>>
>>     1: <% title 'Login' %>              (a yield block in the layout)

From jerry.west at ntlworld.com  Wed Nov  8 04:00:37 2006
From: jerry.west at ntlworld.com (Jerry West)
Date: Wed, 08 Nov 2006 09:00:37 +0000
Subject: [rspec-users] include Helper in context?
In-Reply-To: <455198DD.2020807@ntlworld.com>
References: <45510107.5040308@ntlworld.com>
	<57c63afe0611071710i44067d19oc5d1a7d69b08b666@mail.gmail.com>
	<455198DD.2020807@ntlworld.com>
Message-ID: <45519CB5.6050802@ntlworld.com>

PS: making it a controller spec and calling integrate_views WORKS FINE.

(Sounds of quiet sobbing)

Jerry West wrote:
>> Is this a view spec or a helper spec? If it's a view spec, it must be
>> in a views directory:
>
> It's a view spec and it is now in spec/views/account/login_spec.rb; 
> but still fails :-( . I also do not know what is actually performing 
> the render - what should I be examining in the debugger?  I've looked 
> at self (within specify) and extended it manually with the helper 
> module but to no avail.
>
> I have also tried this:
>
> class X
>  include StandardHelpers
> end
>
> context "Given a fresh login" do
>  include StandardHelpers 
>  specify 'the account/login view should ask for the user\'s email' do
>    X.new.should_respond_to 'title'       render 'account/login'
>    response.should_have_tag 'hi', :content => 'Login'
>  end
> end
>
>
> which still fails on the render but (presumably) the 
> "X.new.should_respond_to 'title'" has worked which at least shows that 
> StandardHelpers are available to be included.
>
> Weird.
>
> BTW:
>
> setup do
>  self.extend(StandardHelpers)
> end
>
> doesn't work either :-( .
>
> Many thanks,
>  Jerry
>
>> Is this a view spec or a helper spec? If it's a view spec, it must be
>> in a views directory:
>>
>> spec/views/**/*_spec.rb
>>
>> http://rspec.rubyforge.org/documentation/rails/writing/index.html
>>
>> Let us know if that solves your problem.
>>
>> Thanks,
>> David
>>
>>  
>>> # fails with:
>>> ActionView::TemplateError in 'account/login (view) displays title 
>>> "Login"'
>>> undefined method `title' for #<#<Class:0xb73154ac>:0xb7314f70>
>>> On line #1 of app/views/account/login.rhtml
>>>
>>>     1: <% title 'Login' %>              (a yield block in the layout)
>

From dchelimsky at gmail.com  Wed Nov  8 04:55:43 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 8 Nov 2006 03:55:43 -0600
Subject: [rspec-users] controller.session not same as session?
Message-ID: <57c63afe0611080155k546a637fpef1b5c1f7c678446@mail.gmail.com>

> context "A user logging out" do
>    fixtures :users
>    controller_name :account
>
>    setup do
>      login_as :quentin
>      users(:quentin).remember_me
>      request.cookies["auth_token"] = cookie_for(:quentin)
>    end
>
>    def logout
>      get :logout
>    end
>
>    specify "should unset :user in session" do
>      logout
>      controller.session[:user].should_be_nil
>    end
>
>    specify "should unset :user in controller.session" do
>      logout
>      controller.session[:user].should_be_nil
>    end
> end
>
> The result:
>
> A user logging out
> - should unset :user in controller.session
> - should unset :user in session (FAILED - 1)
> - should be redirected
> - should delete remember_me token
>
> 1)
> Spec::Expectations::ExpectationNotMetError in 'A user logging out
> should unset :user in session'
> 1 should be nil
> ./spec/controllers/account_controller_spec.rb:149:in `should
> unset :user in session'
>
> Throwing a breakpoint in and examining the two reveals:
>
>  >> session
> => #<ActionController::TestSession:0x3a8e794 @attributes={:user=>1,
> "flash"=>{}}>
>  >> controller.session
> => #<ActionController::TestSession:0x3a797e0 @attributes=
> {:return_to=>nil, "flash"=>{:notice=>"You have been logged out."}}>
>  >>
>
> Am I doing something wrong?

The spec names say "session" and "controller.session", but both are
coded to go after "controller.session". Since each spec gets run in a
brand new instance of the context, it makes sense that these would be
two different objects. What doesn't make sense is that one passes and
one fails.

Would you kindly file a bug?

Thanks,
David

>
> Brandon

From dchelimsky at gmail.com  Wed Nov  8 05:02:09 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 8 Nov 2006 04:02:09 -0600
Subject: [rspec-users] controller.session not same as session?
In-Reply-To: <57c63afe0611080155k546a637fpef1b5c1f7c678446@mail.gmail.com>
References: <57c63afe0611080155k546a637fpef1b5c1f7c678446@mail.gmail.com>
Message-ID: <57c63afe0611080202x2d6f506v60ac39a1ff9b0176@mail.gmail.com>

Sorry - wrong list.

Cheers,
David

On 11/8/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > context "A user logging out" do
> >    fixtures :users
> >    controller_name :account
> >
> >    setup do
> >      login_as :quentin
> >      users(:quentin).remember_me
> >      request.cookies["auth_token"] = cookie_for(:quentin)
> >    end
> >
> >    def logout
> >      get :logout
> >    end
> >
> >    specify "should unset :user in session" do
> >      logout
> >      controller.session[:user].should_be_nil
> >    end
> >
> >    specify "should unset :user in controller.session" do
> >      logout
> >      controller.session[:user].should_be_nil
> >    end
> > end
> >
> > The result:
> >
> > A user logging out
> > - should unset :user in controller.session
> > - should unset :user in session (FAILED - 1)
> > - should be redirected
> > - should delete remember_me token
> >
> > 1)
> > Spec::Expectations::ExpectationNotMetError in 'A user logging out
> > should unset :user in session'
> > 1 should be nil
> > ./spec/controllers/account_controller_spec.rb:149:in `should
> > unset :user in session'
> >
> > Throwing a breakpoint in and examining the two reveals:
> >
> >  >> session
> > => #<ActionController::TestSession:0x3a8e794 @attributes={:user=>1,
> > "flash"=>{}}>
> >  >> controller.session
> > => #<ActionController::TestSession:0x3a797e0 @attributes=
> > {:return_to=>nil, "flash"=>{:notice=>"You have been logged out."}}>
> >  >>
> >
> > Am I doing something wrong?
>
> The spec names say "session" and "controller.session", but both are
> coded to go after "controller.session". Since each spec gets run in a
> brand new instance of the context, it makes sense that these would be
> two different objects. What doesn't make sense is that one passes and
> one fails.
>
> Would you kindly file a bug?
>
> Thanks,
> David
>
> >
> > Brandon
>

From bkeepers at gmail.com  Wed Nov  8 10:12:20 2006
From: bkeepers at gmail.com (Brandon Keepers)
Date: Wed, 8 Nov 2006 10:12:20 -0500
Subject: [rspec-users] running 0.6.4 and 0.7.0 side-by-side
Message-ID: <22602894-6202-476A-B13D-9FAEA13D8826@gmail.com>

For those trying to move projects to 0.7.0, but still using 0.6.4,  
RubyGems supports this arcane syntax for the bin stubs that allow you  
to specify a gem version:

	spec _0.6.4_ /path/to/your/specs

And for the ruby on rails plugin, you can make "rake spec" work by  
add the following two lines to the top of tasks/rspec.rake file:

	require 'rubygems'
	require_gem 'rspec', '0.6.4'

Hope that helps,
Brandon

From chad at theedgecase.com  Wed Nov  8 23:59:09 2006
From: chad at theedgecase.com (Chad Humphries)
Date: Wed, 8 Nov 2006 23:59:09 -0500
Subject: [rspec-users] Hi everybody!  Greetings from sunny Columbus, OH!
Message-ID: <E90A0F03-C02A-48E3-8D75-065AD8C59B3E@theedgecase.com>

Hey everyone, I just wanted to drop onto the list and say hi.  My  
name is Chad Humphries and I am a partner at a ruby and rails shop in  
Columbus, OH called EdgeCase.

Up until two months ago we were doing all of our dev work in  
test:unit.  I had read about RSpec before and after hearing Jim  
Weirich speak at the Columbus Ruby Brigade about similar ideas I  
decided to give it a go for a personal project.  Finally a framework  
that works the way I think for testing!  I quickly used my advanced  
powers of peer pressure to get Joe, Ken and Aaron at the office to  
look at it.  We are now doing all new development on RSpec for rails.

I've been actively involved in the past in many projects such as  
log4net/j, ibatis, and others.  Consider this my hello email and  
notice that I will try my best to submit patches, documentation, and  
general feedback in the upcoming days and weeks to help this great  
framework.

Chad Humphries
=======================
are you living on the edge?
work: theedgecase.com
play:  spicycode.com



From dchelimsky at gmail.com  Thu Nov  9 05:13:27 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 9 Nov 2006 04:13:27 -0600
Subject: [rspec-users] Hi everybody! Greetings from sunny Columbus, OH!
In-Reply-To: <E90A0F03-C02A-48E3-8D75-065AD8C59B3E@theedgecase.com>
References: <E90A0F03-C02A-48E3-8D75-065AD8C59B3E@theedgecase.com>
Message-ID: <57c63afe0611090213n2033d7dcv11ce6bd5e74531d7@mail.gmail.com>

On 11/8/06, Chad Humphries <chad at theedgecase.com> wrote:
> Hey everyone, I just wanted to drop onto the list and say hi.  My
> name is Chad Humphries and I am a partner at a ruby and rails shop in
> Columbus, OH called EdgeCase.
>
> Up until two months ago we were doing all of our dev work in
> test:unit.  I had read about RSpec before and after hearing Jim
> Weirich speak at the Columbus Ruby Brigade about similar ideas I
> decided to give it a go for a personal project.  Finally a framework
> that works the way I think for testing!  I quickly used my advanced
> powers of peer pressure to get Joe, Ken and Aaron at the office to
> look at it.  We are now doing all new development on RSpec for rails.
>
> I've been actively involved in the past in many projects such as
> log4net/j, ibatis, and others.  Consider this my hello email and
> notice that I will try my best to submit patches, documentation, and
> general feedback in the upcoming days and weeks to help this great
> framework.

Welcome Chad! Glad to hear you're enjoying rspec.

You may be interested in the rspec-devel list for more framework
development discussion. Also, please give this a read re:
contributing:

http://rspec.rubyforge.org/contribute.html

Looking forward to your feedback.

Thanks,
David

>
> Chad Humphries
> =======================
> are you living on the edge?
> work: theedgecase.com
> play:  spicycode.com
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From aslak.hellesoy at gmail.com  Thu Nov  9 06:03:06 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 9 Nov 2006 12:03:06 +0100
Subject: [rspec-users] Hi everybody! Greetings from sunny Columbus, OH!
In-Reply-To: <E90A0F03-C02A-48E3-8D75-065AD8C59B3E@theedgecase.com>
References: <E90A0F03-C02A-48E3-8D75-065AD8C59B3E@theedgecase.com>
Message-ID: <8d961d900611090303w6f5585bap568ea65d711bdeef@mail.gmail.com>

On 11/9/06, Chad Humphries <chad at theedgecase.com> wrote:
> Hey everyone, I just wanted to drop onto the list and say hi.  My
> name is Chad Humphries and I am a partner at a ruby and rails shop in
> Columbus, OH called EdgeCase.
>
> Up until two months ago we were doing all of our dev work in
> test:unit.  I had read about RSpec before and after hearing Jim
> Weirich speak at the Columbus Ruby Brigade about similar ideas I
> decided to give it a go for a personal project.  Finally a framework
> that works the way I think for testing!

Ooops. Typo. I think you meant "behaviour driving my code" ;-)

> I quickly used my advanced
> powers of peer pressure to get Joe, Ken and Aaron at the office to
> look at it.  We are now doing all new development on RSpec for rails.
>

That's awesome. Joe told me the same. (We're both ex-ThoughtWorks colleagues)

> I've been actively involved in the past in many projects such as
> log4net/j, ibatis, and others.  Consider this my hello email and
> notice that I will try my best to submit patches, documentation, and
> general feedback in the upcoming days and weeks to help this great
> framework.
>

Sweet. Although spec/rails has got some serious love lately I expect
that that's where most of the effort will be in the near future. If we
could get help cutting down on the RFEs and bugs recorded at RubyForge
that would be great.

Cheers,
Aslak

> Chad Humphries
> =======================
> are you living on the edge?
> work: theedgecase.com
> play:  spicycode.com
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From brian.takita at gmail.com  Thu Nov  9 13:38:33 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Thu, 9 Nov 2006 10:38:33 -0800
Subject: [rspec-users] Focused Specs/Tests in Non-Textmate editors
Message-ID: <1d7ddd110611091038n5be2e958pde3f003f75fa506e@mail.gmail.com>

Hello,

I wrote a script that runs a focused spec/test from the filename and line
number.
I bound this to an external tool in my Idea environment.

http://weblog.freeopinion.org/articles/2006/11/04/focused-unit-test-spec-script

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061109/6aa1b7f8/attachment.html 

From aslak.hellesoy at gmail.com  Thu Nov  9 18:50:45 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 10 Nov 2006 00:50:45 +0100
Subject: [rspec-users] Focused Specs/Tests in Non-Textmate editors
In-Reply-To: <1d7ddd110611091038n5be2e958pde3f003f75fa506e@mail.gmail.com>
References: <1d7ddd110611091038n5be2e958pde3f003f75fa506e@mail.gmail.com>
Message-ID: <8d961d900611091550p21e994c6y8c069502d492c808@mail.gmail.com>

On 11/9/06, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> I wrote a script that runs a focused spec/test from the filename and line
> number.
> I bound this to an external tool in my Idea environment.
>
> http://weblog.freeopinion.org/articles/2006/11/04/focused-unit-test-spec-script
>

Very cool. I think we should add a -l --line option to the spec
command to make this an inherent feature of RSpec. It would make tool
integration much easier. I implemented similar functionality in
RSpec.tmbundle (see my patch to Luke Redpath's code - spec_mate.rb
that I sent to the rspec-devel "Running specs with TextMate bundle"
thread yesterday).

Aslak

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

From aslak.hellesoy at gmail.com  Thu Nov  9 18:58:38 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 10 Nov 2006 00:58:38 +0100
Subject: [rspec-users] Focused Specs/Tests in Non-Textmate editors
In-Reply-To: <8d961d900611091550p21e994c6y8c069502d492c808@mail.gmail.com>
References: <1d7ddd110611091038n5be2e958pde3f003f75fa506e@mail.gmail.com>
	<8d961d900611091550p21e994c6y8c069502d492c808@mail.gmail.com>
Message-ID: <8d961d900611091558m35788d3bm768915725a6111e0@mail.gmail.com>

On 11/10/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 11/9/06, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > I wrote a script that runs a focused spec/test from the filename and line
> > number.
> > I bound this to an external tool in my Idea environment.
> >
> > http://weblog.freeopinion.org/articles/2006/11/04/focused-unit-test-spec-script
> >
>

Another noteworthy piece of news is that it's now much easier to
launch RSpec from Ruby without having to spawn a new ruby via the spec
command:

# Facade to run specs without having to fork a new ruby process (using
`spec ...`)
# Runs specs. +argv+ is the commandline args as per the spec
commandline API, +stderr+
# and +stdiout+ are the streams output will be written to, +exit+
tells whether or
# not a system exit should be called after the specs are run and
# +warn_if_no_files+ tells whether or not a warning (the help message)
# should be printed to +stderr+ in case no files are specified.
Spec::Runner::CommandLine.run(argv, stderr, stdout, exit, warn_if_no_files)

So with a little more work in RSpec you could just call that, passing
in --line as part of the args.

Aslak

> Very cool. I think we should add a -l --line option to the spec
> command to make this an inherent feature of RSpec. It would make tool
> integration much easier. I implemented similar functionality in
> RSpec.tmbundle (see my patch to Luke Redpath's code - spec_mate.rb
> that I sent to the rspec-devel "Running specs with TextMate bundle"
> thread yesterday).
>
> Aslak
>
> > Brian
> >
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> >
>

From lists-rspec at shopwatch.org  Thu Nov  9 20:48:29 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Thu, 09 Nov 2006 20:48:29 -0500
Subject: [rspec-users] Stubbing Time.now in trunk
Message-ID: <4553DA6D.6070409@jay.fm>

I'm a big fan of stubbing Time.now so it returns a known value.  I used 
to be able to use stubba and say:

@time_now = Time.parse("Jan 1 2001")
Time.stubs(:now).returns(lambda{@time_now})

However, something in trunk broke that.  Fine, rspec's got its own 
stubbing lib now, so I tried switching to that:

@time_now = Time.parse("Jan 1 2001")
Time.stub!(:now).and_return(lambda{@time_now})

This gives me some VERY odd errors.  For instance, if this is in a 
controller spec, and the next line is
  get 'index'

I get:

wrong number of arguments (1 for 0)
./spec/controllers/one_spec.rb:9:in `should render the index page'

Line 9 is the get 'index' line. If I delete that, so there is no next 
line, I get:

NoMethodError in 'the test app should render the index page'
undefined method `to_i' for 
#<Proc:0x04a0374c at ./spec/controllers/one_spec.rb:8>

Am I doing something wrong, or is this a bug in trunk?

Jay


From dchelimsky at gmail.com  Fri Nov 10 09:36:28 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 10 Nov 2006 08:36:28 -0600
Subject: [rspec-users] [ANN] RSpec-0.7.1
Message-ID: <57c63afe0611100636n70e84938i44c92f3f4b2e87eb@mail.gmail.com>

RSpec-0.7.1 is now available. It comprises some bug fixes and a couple
of new features.

This is recommended for anybody who has already upgraded to 0.7.0.

If you are running 0.6.x (or earlier), read this first:
http://rspec.rubyforge.org/upgrade.html

Install gem: gem install rspec
Download: http://rubyforge.org/frs/?group_id=797
Release Notes: http://rubyforge.org/frs/shownotes.php?release_id=7846
RSpec site: http://rspec.rubyforge.org/

Happy designing!

David

From aslak.hellesoy at gmail.com  Fri Nov 10 16:20:17 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 10 Nov 2006 22:20:17 +0100
Subject: [rspec-users] Stubbing Time.now in trunk
In-Reply-To: <4553DA6D.6070409@jay.fm>
References: <4553DA6D.6070409@jay.fm>
Message-ID: <8d961d900611101320o79ff700cn8d188580d89effdd@mail.gmail.com>

On 11/10/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> I'm a big fan of stubbing Time.now so it returns a known value.  I used
> to be able to use stubba and say:
>
> @time_now = Time.parse("Jan 1 2001")
> Time.stubs(:now).returns(lambda{@time_now})
>
> However, something in trunk broke that.  Fine, rspec's got its own
> stubbing lib now, so I tried switching to that:
>
> @time_now = Time.parse("Jan 1 2001")
> Time.stub!(:now).and_return(lambda{@time_now})
>
> This gives me some VERY odd errors.  For instance, if this is in a
> controller spec, and the next line is
>   get 'index'
>
> I get:
>
> wrong number of arguments (1 for 0)
> ./spec/controllers/one_spec.rb:9:in `should render the index page'
>
> Line 9 is the get 'index' line. If I delete that, so there is no next
> line, I get:
>
> NoMethodError in 'the test app should render the index page'
> undefined method `to_i' for
> #<Proc:0x04a0374c at ./spec/controllers/one_spec.rb:8>
>
> Am I doing something wrong, or is this a bug in trunk?
>

Could be a bug. Please submit a complete failing spec so we can
reproduce it faithfully.
http://rspec.rubyforge.org/contribute.html

Aslak

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

From dchelimsky at gmail.com  Fri Nov 10 16:35:59 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 10 Nov 2006 15:35:59 -0600
Subject: [rspec-users] Stubbing Time.now in trunk
In-Reply-To: <4553DA6D.6070409@jay.fm>
References: <4553DA6D.6070409@jay.fm>
Message-ID: <57c63afe0611101335s477ec975refaacc01a2ab8c2@mail.gmail.com>

Try this:

@time_now = Time.parse("Jan 1 2001")
Time.stub!(:now).and_return(@time_now)

OR

Time.stub!(:now).and_return lambda { @time_now }

What you were doing was returning a lambda. So the code that was
expecting a time value was getting a poor lambda that nobody is
calling :(

Mary had a little lambda....

Cheers,
David


On 11/9/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> I'm a big fan of stubbing Time.now so it returns a known value.  I used
> to be able to use stubba and say:
>
> @time_now = Time.parse("Jan 1 2001")
> Time.stubs(:now).returns(lambda{@time_now})
>
> However, something in trunk broke that.  Fine, rspec's got its own
> stubbing lib now, so I tried switching to that:
>
> @time_now = Time.parse("Jan 1 2001")
> Time.stub!(:now).and_return(lambda{@time_now})
>
> This gives me some VERY odd errors.  For instance, if this is in a
> controller spec, and the next line is
>   get 'index'
>
> I get:
>
> wrong number of arguments (1 for 0)
> ./spec/controllers/one_spec.rb:9:in `should render the index page'
>
> Line 9 is the get 'index' line. If I delete that, so there is no next
> line, I get:
>
> NoMethodError in 'the test app should render the index page'
> undefined method `to_i' for
> #<Proc:0x04a0374c at ./spec/controllers/one_spec.rb:8>
>
> Am I doing something wrong, or is this a bug in trunk?
>
> Jay
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From brandon at collectiveidea.com  Fri Nov 10 15:14:47 2006
From: brandon at collectiveidea.com (Brandon Keepers)
Date: Fri, 10 Nov 2006 15:14:47 -0500
Subject: [rspec-users] Specifying views
Message-ID: <0B20E4E6-8E26-4B9B-B28F-CA725C0AAB2F@collectiveidea.com>

I'm trying to spec my views with 0.7.1 on edge rails  per the  
instructions on the rspec site [1] and David's blog [2], but I'm not  
having much luck.  Here's my spec in specs/views/accounts/ 
new_view_spec.rb:

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

context "The new account form" do

   specify "should have an account name" do
     render 'accounts/new'
     response.should_have_tag 'input', :attributes => {:name =>  
'account[name]', :type => 'text'}
   end
end

and when I run that, I get:

1)
RuntimeError in 'The new account form should have an account name'
Deprecating @session, but it's already set to  
#<ActionController::TestSession:0x3c46870 @attributes={"flash"=>{}}>!  
Use the session= writer method instead of setting @session directly.
/Users/brandon/projects/finances/config/../vendor/rails/actionpack/ 
lib/action_controller/base.rb:1049:in `assign_deprecated_shortcuts'
/Users/brandon/projects/finances/config/../vendor/rails/actionpack/ 
lib/action_controller/base.rb:1044:in `assign_deprecated_shortcuts'
/Users/brandon/projects/finances/config/../vendor/rails/actionpack/ 
lib/action_controller/base.rb:1035:in `assign_shortcuts_without_flash'
/Users/brandon/projects/finances/config/../vendor/rails/actionpack/ 
lib/action_controller/flash.rb:140:in `assign_shortcuts'

I can't even tell what the error is.  It's giving a RuntimeError, but  
for what?  The deprecation warning? Anyone see anything obvious?

Thanks,
Brandon


[1] http://rspec.rubyforge.org/documentation/rails/writing/views.html
[2] http://blog.davidchelimsky.net/articles/2006/11/06/view-spec- 
tutorial
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/rspec-users/attachments/20061110/c9da7b1b/attachment.bin 

From dchelimsky at gmail.com  Fri Nov 10 17:28:58 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 10 Nov 2006 16:28:58 -0600
Subject: [rspec-users] Specifying views
In-Reply-To: <0B20E4E6-8E26-4B9B-B28F-CA725C0AAB2F@collectiveidea.com>
References: <0B20E4E6-8E26-4B9B-B28F-CA725C0AAB2F@collectiveidea.com>
Message-ID: <57c63afe0611101428r11e29021x5aa28f1ab1c0db8c@mail.gmail.com>

What version of zentest do you have?

On 11/10/06, Brandon Keepers <brandon at collectiveidea.com> wrote:
> I'm trying to spec my views with 0.7.1 on edge rails  per the
> instructions on the rspec site [1] and David's blog [2], but I'm not
> having much luck.  Here's my spec in specs/views/accounts/
> new_view_spec.rb:
>
> require File.dirname(__FILE__) + '/../../spec_helper'
>
> context "The new account form" do
>
>    specify "should have an account name" do
>      render 'accounts/new'
>      response.should_have_tag 'input', :attributes => {:name =>
> 'account[name]', :type => 'text'}
>    end
> end
>
> and when I run that, I get:
>
> 1)
> RuntimeError in 'The new account form should have an account name'
> Deprecating @session, but it's already set to
> #<ActionController::TestSession:0x3c46870 @attributes={"flash"=>{}}>!
> Use the session= writer method instead of setting @session directly.
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1049:in `assign_deprecated_shortcuts'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1044:in `assign_deprecated_shortcuts'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1035:in `assign_shortcuts_without_flash'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/flash.rb:140:in `assign_shortcuts'
>
> I can't even tell what the error is.  It's giving a RuntimeError, but
> for what?  The deprecation warning? Anyone see anything obvious?
>
> Thanks,
> Brandon
>
>
> [1] http://rspec.rubyforge.org/documentation/rails/writing/views.html
> [2] http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-
> tutorial
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>

From aslak.hellesoy at gmail.com  Fri Nov 10 17:42:44 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 10 Nov 2006 23:42:44 +0100
Subject: [rspec-users] Specifying views
In-Reply-To: <0B20E4E6-8E26-4B9B-B28F-CA725C0AAB2F@collectiveidea.com>
References: <0B20E4E6-8E26-4B9B-B28F-CA725C0AAB2F@collectiveidea.com>
Message-ID: <8d961d900611101442t1a3a7a3bu9704fc69a29b9f02@mail.gmail.com>

On 11/10/06, Brandon Keepers <brandon at collectiveidea.com> wrote:
> I'm trying to spec my views with 0.7.1 on edge rails  per the
> instructions on the rspec site [1] and David's blog [2], but I'm not
> having much luck.  Here's my spec in specs/views/accounts/
> new_view_spec.rb:
>
> require File.dirname(__FILE__) + '/../../spec_helper'
>
> context "The new account form" do
>
>    specify "should have an account name" do
>      render 'accounts/new'
>      response.should_have_tag 'input', :attributes => {:name =>
> 'account[name]', :type => 'text'}
>    end
> end
>
> and when I run that, I get:
>
> 1)
> RuntimeError in 'The new account form should have an account name'
> Deprecating @session, but it's already set to
> #<ActionController::TestSession:0x3c46870 @attributes={"flash"=>{}}>!
> Use the session= writer method instead of setting @session directly.
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1049:in `assign_deprecated_shortcuts'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1044:in `assign_deprecated_shortcuts'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1035:in `assign_shortcuts_without_flash'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/flash.rb:140:in `assign_shortcuts'
>
> I can't even tell what the error is.  It's giving a RuntimeError, but
> for what?  The deprecation warning? Anyone see anything obvious?
>

The obvious answer is that we haven't tested spec/rails agains edge
rails - only 1.1.6
It's on our TODO list

Aslak

> Thanks,
> Brandon
>
>
> [1] http://rspec.rubyforge.org/documentation/rails/writing/views.html
> [2] http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-
> tutorial
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>

From dchelimsky at gmail.com  Fri Nov 10 17:28:58 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 10 Nov 2006 16:28:58 -0600
Subject: [rspec-users] Specifying views
In-Reply-To: <0B20E4E6-8E26-4B9B-B28F-CA725C0AAB2F@collectiveidea.com>
References: <0B20E4E6-8E26-4B9B-B28F-CA725C0AAB2F@collectiveidea.com>
Message-ID: <57c63afe0611101428r11e29021x5aa28f1ab1c0db8c@mail.gmail.com>

What version of zentest do you have?

On 11/10/06, Brandon Keepers <brandon at collectiveidea.com> wrote:
> I'm trying to spec my views with 0.7.1 on edge rails  per the
> instructions on the rspec site [1] and David's blog [2], but I'm not
> having much luck.  Here's my spec in specs/views/accounts/
> new_view_spec.rb:
>
> require File.dirname(__FILE__) + '/../../spec_helper'
>
> context "The new account form" do
>
>    specify "should have an account name" do
>      render 'accounts/new'
>      response.should_have_tag 'input', :attributes => {:name =>
> 'account[name]', :type => 'text'}
>    end
> end
>
> and when I run that, I get:
>
> 1)
> RuntimeError in 'The new account form should have an account name'
> Deprecating @session, but it's already set to
> #<ActionController::TestSession:0x3c46870 @attributes={"flash"=>{}}>!
> Use the session= writer method instead of setting @session directly.
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1049:in `assign_deprecated_shortcuts'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1044:in `assign_deprecated_shortcuts'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/base.rb:1035:in `assign_shortcuts_without_flash'
> /Users/brandon/projects/finances/config/../vendor/rails/actionpack/
> lib/action_controller/flash.rb:140:in `assign_shortcuts'
>
> I can't even tell what the error is.  It's giving a RuntimeError, but
> for what?  The deprecation warning? Anyone see anything obvious?
>
> Thanks,
> Brandon
>
>
> [1] http://rspec.rubyforge.org/documentation/rails/writing/views.html
> [2] http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-
> tutorial
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>
>

From lists-rspec at shopwatch.org  Fri Nov 10 18:17:42 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Fri, 10 Nov 2006 18:17:42 -0500
Subject: [rspec-users] Stubbing Time.now in trunk
In-Reply-To: <57c63afe0611101335s477ec975refaacc01a2ab8c2@mail.gmail.com>
References: <4553DA6D.6070409@jay.fm>
	<57c63afe0611101335s477ec975refaacc01a2ab8c2@mail.gmail.com>
Message-ID: <45550896.2000207@shopwatch.org>

David Chelimsky wrote:
> Try this:
> 
> @time_now = Time.parse("Jan 1 2001")
> Time.stub!(:now).and_return(@time_now)

That works, but the effect I was trying to achieve was a changeable 
Time.now, as in:

@time_now = Time.parse("Jan 1 2001")
Time.stub!(:now).and_return(lambda{@time_now})
MyApp.do_something
@time_now = Time.parse("Oct 1 2001")
MyApp.should_be_expired


> 
> OR
> 
> Time.stub!(:now).and_return lambda { @time_now }

This is what I was trying, and was seeing those weird next-line errors.

What does seem to work is

Time.stub!(:now).and_return { @time_now }

e.g. just passing a block to and_return, instead of a lambda.  So I 
guess it's just a different syntax than I was used to with Mocha, which 
(now that I look at it) special-cases a return-value that is_a?(Proc).

Jay


From ppagel at 8thLight.com  Fri Nov 10 18:11:25 2006
From: ppagel at 8thLight.com (Paul W Pagel)
Date: Fri, 10 Nov 2006 17:11:25 -0600
Subject: [rspec-users] mock syntax order
Message-ID: <19C1F309-55F2-433F-969D-7FFE5EE6ABC5@8thLight.com>

I have the following statement

mock_requester.should_receive(:request_with).with 
("x").any_number_of_times.and_return(@object)

which works fine, but when i do it backwards, which makes the same  
amount of sense syntactically, it fails

  mock_requester.should_receive(:request_with).with("x").and_return 
(@object).any_number_of_times

are all of the mock options deterministic?  Can they be interchangeable?


Paul W Pagel
www.8thLight.com
blog.8thLight.com



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

From aslak.hellesoy at gmail.com  Fri Nov 10 18:42:20 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 11 Nov 2006 00:42:20 +0100
Subject: [rspec-users] mock syntax order
In-Reply-To: <19C1F309-55F2-433F-969D-7FFE5EE6ABC5@8thLight.com>
References: <19C1F309-55F2-433F-969D-7FFE5EE6ABC5@8thLight.com>
Message-ID: <8d961d900611101542y3e311b40y9a51a79ab3e8ac01@mail.gmail.com>

On 11/11/06, Paul W Pagel <ppagel at 8thlight.com> wrote:
> I have the following statement
>
> mock_requester.should_receive(:request_with).with("x").any_number_of_times.and_return(@object)
>
> which works fine, but when i do it backwards, which makes the same amount of
> sense syntactically, it fails
>

How does it fail? Can you submit a failing spec as described here?
http://rspec.rubyforge.org/contribute.html

>  mock_requester.should_receive(:request_with).with("x").and_return(@object).any_number_of_times
>
> are all of the mock options deterministic?  Can they be interchangeable?
>

I thought so. We'll see when we get your failing spec

>
>
> Paul W Pagel
> www.8thLight.com
> blog.8thLight.com
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>

From dchelimsky at gmail.com  Fri Nov 10 18:43:38 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 10 Nov 2006 17:43:38 -0600
Subject: [rspec-users] mock syntax order
In-Reply-To: <19C1F309-55F2-433F-969D-7FFE5EE6ABC5@8thLight.com>
References: <19C1F309-55F2-433F-969D-7FFE5EE6ABC5@8thLight.com>
Message-ID: <57c63afe0611101543q2fb21f8cy6eb8f1667a5a0719@mail.gmail.com>

On 11/10/06, Paul W Pagel <ppagel at 8thlight.com> wrote:
> I have the following statement
>
> mock_requester.should_receive(:request_with).with("x").any_number_of_times.and_return(@object)
>
> which works fine, but when i do it backwards, which makes the same amount of
> sense syntactically, it fails
>
> mock_requester.should_receive(:request_with).with("x").and_return(@object).any_number_of_times
>
> are all of the mock options deterministic?

Huh?

>  Can they be interchangeable?

Should be doable. Raise an RFE please.

>
>
>
> Paul W Pagel
> www.8thLight.com
> blog.8thLight.com
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>

From bkeepers at gmail.com  Sat Nov 11 00:30:57 2006
From: bkeepers at gmail.com (Brandon Keepers)
Date: Sat, 11 Nov 2006 00:30:57 -0500
Subject: [rspec-users] Specifying views
In-Reply-To: <57c63afe0611101428r11e29021x5aa28f1ab1c0db8c@mail.gmail.com>
References: <0B20E4E6-8E26-4B9B-B28F-CA725C0AAB2F@collectiveidea.com>
	<57c63afe0611101428r11e29021x5aa28f1ab1c0db8c@mail.gmail.com>
Message-ID: <116DC75A-41A4-48A1-A21F-979934714B23@gmail.com>


On Nov 10, 2006, at 5:28 PM, David Chelimsky wrote:
> What version of zentest do you have?

$ gem list ZenTest

*** LOCAL GEMS ***

ZenTest (3.4.1, 3.4.0)
     ZenTest provides 4 different tools and 1 library: zentest,
     unit_diff, autotest, multiruby, and Test::Rails.


From micah at 8thlight.com  Thu Nov 16 12:37:26 2006
From: micah at 8thlight.com (Micah Martin)
Date: Thu, 16 Nov 2006 11:37:26 -0600
Subject: [rspec-users] helpers not rendered in views?
Message-ID: <F0715612-3F7D-4A8C-85AD-88E47A16DA84@8thlight.com>

https://rubyforge.org/tracker/index.php? 
func=detail&aid=6713&group_id=797&atid=3150

I'm not sure if this is true of all helper methods but it is for the  
following.  In this case the forn_remote_tag is rendered as an empty  
line.

Apprently helpers are not rendered in view tests...

template _xyz:
<div>
	<% form_remote_tag :update => "some_div", :url => {:action  
=> :something } %>
		<textarea style="width: 100%" rows="2">Enter text here.</textarea>
	<% end_form_tag %>
</div>


failing spec:
   specify "Form is rendered" do

     render "/controller/_xyz"
     response.should_have_tag 'form', :parent => { :tag => "div" }
   end


Micah Martin
8th Light, Inc.
www.8thlight.com



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

From dchelimsky at gmail.com  Sun Nov 19 08:29:48 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 19 Nov 2006 07:29:48 -0600
Subject: [rspec-users] artificial sugar causes cancer
Message-ID: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com>

All,

If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149
 you'll see that Chad (the submitter) found the source of the bug.
Unfortunately, the source of *this* bug is the *solution* to a
*previous bug* in which Rails was replacing RSpec's method missing
with its own.

When we settled on underscores, my one reservation was that we'd keep
running into this particular problem - RSpec's method_missing
conflicting with others.

I have a proposition that preserves the underscore syntax, makes some
examples even more clear, and eliminates this problem once and for
all.

1. Eliminate reliance on method missing to handle expectations by
adding all of the documented should_x_y_z methods directly to Object.
These would all delegate off to Spec::Expectations::Should, ::Not,
::Have, etc, so the design wouldn't change much and Object itself,
though bloated w/ methods, would not be bloated w/ implementation.

This would also give us a single expectations module that we add to
Object, providing several benefits including:
# more clarity in the API
# a place to put meaningful rdoc
# a potential formal plugin point

2. Change should_be to ONLY handle arbitrary predicates (not serve as
an alias for should_equal):

subject.should_be :empty => passes if subject.empty?
subject.should_be :instance_of, SomeClass => passes if
subject.instance_of? SomeClass
etc...

In my opinion (feel free to disagree), this actually makes these
examples more readable. Consider these two:

@bdd_framework.should_be_adopted_quickly #current
@bdd_framework.should_be :adopted_quickly #proposed

In my view, these read equally well from a language perspective AND
they make it easier for a developer to mentally separate the
expectation (should_be) from the expected value (adopted_quickly?).

This WOULD require changes to existing specs. I think for those of you
who don't wrap expectation args in parens that a trivial script would
handle this for you. If you do use parens, the script might be more
complex. Perhaps if we *do* choose this direction, one of you would
like to contribute such a script.

I fully recognize that this would cause some pain, but it is my
feeling that not addressing this leaves us in a crippled position in
which we commit to being sidetracked by this issue constantly
returning instead of focusing on enhancing the API.

I also think that this is a better option than any of the following
that also crossed my mind:
* revert to dots
* figure out a sexy way to intercept all attempts to rewrite method
missing and re-inject RSpec's method missing in its place (perhaps
this does sound sexy, but I doth believe that there is a venereal
disease hiding in its midst)
* leave things as they are and continue to add ugly hacks like
NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get
so call it that)
* hang myself from the nearest bridge

Of course, if you have any solutions to propose, I'm all eyes.

Thoughts?

Thanks,
David

From dchelimsky at gmail.com  Sun Nov 19 16:34:35 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 19 Nov 2006 15:34:35 -0600
Subject: [rspec-users] underscores, sugar, and more and more bugs
Message-ID: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com>

I sent this earlier under with the subject "artificial sugar causes
cancer" and I think some spam filters ate it. Here it is again:
======================================

All,

If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149
 you'll see that Chad (the submitter) found the source of the bug.
Unfortunately, the source of *this* bug is the *solution* to a
*previous bug* in which Rails was replacing RSpec's method missing
with its own.

When we settled on underscores, my one reservation was that we'd keep
running into this particular problem - RSpec's method_missing
conflicting with others.

I have a proposition that preserves the underscore syntax, makes some
examples even more clear, and eliminates this problem once and for
all.

1. Eliminate reliance on method missing to handle expectations by
adding all of the documented should_x_y_z methods directly to Object.
These would all delegate off to Spec::Expectations::Should, ::Not,
::Have, etc, so the design wouldn't change much and Object itself,
though bloated w/ methods, would not be bloated w/ implementation.

This would also give us a single expectations module that we add to
Object, providing several benefits including:
# more clarity in the API
# a place to put meaningful rdoc
# a potential formal plugin point

2. Change should_be to ONLY handle arbitrary predicates (not serve as
an alias for should_equal):

subject.should_be :empty => passes if subject.empty?
subject.should_be :instance_of, SomeClass => passes if
subject.instance_of? SomeClass
etc...

In my opinion (feel free to disagree), this actually makes these
examples more readable. Consider these two:

@bdd_framework.should_be_adopted_quickly #current
@bdd_framework.should_be :adopted_quickly #proposed

In my view, these read equally well from a language perspective AND
they make it easier for a developer to mentally separate the
expectation (should_be) from the expected value (adopted_quickly?).

This WOULD require changes to existing specs. I think for those of you
who don't wrap expectation args in parens that a trivial script would
handle this for you. If you do use parens, the script might be more
complex. Perhaps if we *do* choose this direction, one of you would
like to contribute such a script.

I fully recognize that this would cause some pain, but it is my
feeling that not addressing this leaves us in a crippled position in
which we commit to being sidetracked by this issue constantly
returning instead of focusing on enhancing the API.

I also think that this is a better option than any of the following
that also crossed my mind:
* revert to dots
* figure out a sexy way to intercept all attempts to rewrite method
missing and re-inject RSpec's method missing in its place (perhaps
this does sound sexy, but I doth believe that there is a venereal
disease hiding in its midst)
* leave things as they are and continue to add ugly hacks like
NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get
so call it that)
* hang myself from the nearest bridge

Of course, if you have any solutions to propose, I'm all eyes.

Thoughts?

Thanks,
David

From aslak.hellesoy at gmail.com  Mon Nov 20 10:00:24 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 20 Nov 2006 16:00:24 +0100
Subject: [rspec-users] artificial sugar causes cancer
In-Reply-To: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com>
References: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com>
Message-ID: <8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com>

On 11/19/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> All,
>
> If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149
>  you'll see that Chad (the submitter) found the source of the bug.
> Unfortunately, the source of *this* bug is the *solution* to a
> *previous bug* in which Rails was replacing RSpec's method missing
> with its own.
>
> When we settled on underscores, my one reservation was that we'd keep
> running into this particular problem - RSpec's method_missing
> conflicting with others.
>
> I have a proposition that preserves the underscore syntax, makes some
> examples even more clear, and eliminates this problem once and for
> all.
>
> 1. Eliminate reliance on method missing to handle expectations by
> adding all of the documented should_x_y_z methods directly to Object.
> These would all delegate off to Spec::Expectations::Should, ::Not,
> ::Have, etc, so the design wouldn't change much and Object itself,
> though bloated w/ methods, would not be bloated w/ implementation.
>
> This would also give us a single expectations module that we add to
> Object, providing several benefits including:
> # more clarity in the API
> # a place to put meaningful rdoc
> # a potential formal plugin point
>

Good

> 2. Change should_be to ONLY handle arbitrary predicates (not serve as
> an alias for should_equal):
>

What would I say instead of flag.should_be true
flag.should == true

?

> subject.should_be :empty => passes if subject.empty?
> subject.should_be :instance_of, SomeClass => passes if
> subject.instance_of? SomeClass
> etc...
>
> In my opinion (feel free to disagree), this actually makes these
> examples more readable. Consider these two:
>
> @bdd_framework.should_be_adopted_quickly #current
> @bdd_framework.should_be :adopted_quickly #proposed
>

I prefer the latter too

> In my view, these read equally well from a language perspective AND
> they make it easier for a developer to mentally separate the
> expectation (should_be) from the expected value (adopted_quickly?).
>
> This WOULD require changes to existing specs. I think for those of you
> who don't wrap expectation args in parens that a trivial script would
> handle this for you. If you do use parens, the script might be more
> complex. Perhaps if we *do* choose this direction, one of you would
> like to contribute such a script.
>
> I fully recognize that this would cause some pain, but it is my
> feeling that not addressing this leaves us in a crippled position in
> which we commit to being sidetracked by this issue constantly
> returning instead of focusing on enhancing the API.
>
> I also think that this is a better option than any of the following
> that also crossed my mind:
> * revert to dots
> * figure out a sexy way to intercept all attempts to rewrite method
> missing and re-inject RSpec's method missing in its place (perhaps
> this does sound sexy, but I doth believe that there is a venereal
> disease hiding in its midst)
> * leave things as they are and continue to add ugly hacks like
> NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get
> so call it that)
> * hang myself from the nearest bridge
>

Fortunately Illinois is quite flat. All of these are lame options.

> Of course, if you have any solutions to propose, I'm all eyes.
>
> Thoughts?
>

I think this all sounds good. It would be great to lose our
method_missing. It's not future-proof.

Aslak

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

From dchelimsky at gmail.com  Mon Nov 20 11:13:08 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 20 Nov 2006 10:13:08 -0600
Subject: [rspec-users] artificial sugar causes cancer
In-Reply-To: <8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com>
References: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com>
	<8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com>
Message-ID: <57c63afe0611200813q3e34c06eu57db39bb863484f9@mail.gmail.com>

On 11/20/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 11/19/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > All,
> >
> > If you look at http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149
> >  you'll see that Chad (the submitter) found the source of the bug.
> > Unfortunately, the source of *this* bug is the *solution* to a
> > *previous bug* in which Rails was replacing RSpec's method missing
> > with its own.
> >
> > When we settled on underscores, my one reservation was that we'd keep
> > running into this particular problem - RSpec's method_missing
> > conflicting with others.
> >
> > I have a proposition that preserves the underscore syntax, makes some
> > examples even more clear, and eliminates this problem once and for
> > all.
> >
> > 1. Eliminate reliance on method missing to handle expectations by
> > adding all of the documented should_x_y_z methods directly to Object.
> > These would all delegate off to Spec::Expectations::Should, ::Not,
> > ::Have, etc, so the design wouldn't change much and Object itself,
> > though bloated w/ methods, would not be bloated w/ implementation.
> >
> > This would also give us a single expectations module that we add to
> > Object, providing several benefits including:
> > # more clarity in the API
> > # a place to put meaningful rdoc
> > # a potential formal plugin point
> >
>
> Good
>
> > 2. Change should_be to ONLY handle arbitrary predicates (not serve as
> > an alias for should_equal):
> >
>
> What would I say instead of flag.should_be true
> flag.should == true

Actually, should_be is currently an alias for should_equal. We could
let it continue to be so for everything but a symbol, in which case it
would find a matching predicate method on the target. This would lead
to:

subject.should_be true
subject.should_be false
subject.should_be nil
subject.should_be :using_a_symbol #subject.using_a_symbol?
etc

>
> ?
>
> > subject.should_be :empty => passes if subject.empty?
> > subject.should_be :instance_of, SomeClass => passes if
> > subject.instance_of? SomeClass
> > etc...
> >
> > In my opinion (feel free to disagree), this actually makes these
> > examples more readable. Consider these two:
> >
> > @bdd_framework.should_be_adopted_quickly #current
> > @bdd_framework.should_be :adopted_quickly #proposed
> >
>
> I prefer the latter too
>
> > In my view, these read equally well from a language perspective AND
> > they make it easier for a developer to mentally separate the
> > expectation (should_be) from the expected value (adopted_quickly?).
> >
> > This WOULD require changes to existing specs. I think for those of you
> > who don't wrap expectation args in parens that a trivial script would
> > handle this for you. If you do use parens, the script might be more
> > complex. Perhaps if we *do* choose this direction, one of you would
> > like to contribute such a script.
> >
> > I fully recognize that this would cause some pain, but it is my
> > feeling that not addressing this leaves us in a crippled position in
> > which we commit to being sidetracked by this issue constantly
> > returning instead of focusing on enhancing the API.
> >
> > I also think that this is a better option than any of the following
> > that also crossed my mind:
> > * revert to dots
> > * figure out a sexy way to intercept all attempts to rewrite method
> > missing and re-inject RSpec's method missing in its place (perhaps
> > this does sound sexy, but I doth believe that there is a venereal
> > disease hiding in its midst)
> > * leave things as they are and continue to add ugly hacks like
> > NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get
> > so call it that)
> > * hang myself from the nearest bridge
> >
>
> Fortunately Illinois is quite flat. All of these are lame options.
>
> > Of course, if you have any solutions to propose, I'm all eyes.
> >
> > Thoughts?
> >
>
> I think this all sounds good. It would be great to lose our
> method_missing. It's not future-proof.

It's not even present proof!

Thanks,
David

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

From olle at olleolleolle.dk  Mon Nov 20 11:06:21 2006
From: olle at olleolleolle.dk (Olle Jonsson)
Date: Mon, 20 Nov 2006 17:06:21 +0100
Subject: [rspec-users] artificial sugar causes cancer
In-Reply-To: <8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com>
References: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com>
	<8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com>
Message-ID: <2CA122E4-B6CA-4CDD-ACDD-CCB735534030@olleolleolle.dk>

On Nov 20, 2006, at 4:00 PM, aslak hellesoy wrote:

>> @bdd_framework.should_be_adopted_quickly #current
>> @bdd_framework.should_be :adopted_quickly #proposed
>>
>
> I prefer the latter too

Dude +1, the latter is so preferred.

cheers,
    Olle

From nicksieger at gmail.com  Mon Nov 20 12:36:05 2006
From: nicksieger at gmail.com (Nick Sieger)
Date: Mon, 20 Nov 2006 11:36:05 -0600
Subject: [rspec-users] artificial sugar causes cancer
In-Reply-To: <2CA122E4-B6CA-4CDD-ACDD-CCB735534030@olleolleolle.dk>
References: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com>
	<8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com>
	<2CA122E4-B6CA-4CDD-ACDD-CCB735534030@olleolleolle.dk>
Message-ID: <f0b861390611200936j5379f884o7eb1fc2920baf481@mail.gmail.com>

On 11/20/06, Olle Jonsson <olle at olleolleolle.dk> wrote:
>
> On Nov 20, 2006, at 4:00 PM, aslak hellesoy wrote:
>
> >> @bdd_framework.should_be_adopted_quickly #current
> >> @bdd_framework.should_be :adopted_quickly #proposed
> >>
> >
> > I prefer the latter too
>
> Dude +1, the latter is so preferred.


I'm mostly indifferent/favoring the proposed changes, but note that for the
above example, might it be confusing to drop the punctuation?

@bdd_framework.should_be :adopted_quickly vs @bdd_framework.should_be
:adopted_quickly?

I know it's the readability of the expectation here -- you're making a
statement, so you don't want it to end in a query, but the symbol-based
approach reminds me of using Object#send(:symbol), so there's a tiny bit of
magic in appending the query for you.  Perhaps the should_be helper could be
a special case that could use '.' or some other syntax for predicate
methods?

I also happen to like the underscore approach in the case of things like "
array.should_be_empty" to test for "array.empty? == true".  But I'd concede
that syntax if we could settle on something else.  Maybe I just need to
retrain my own eyes to be more accepting of "array.should_be :empty".  Is it
just me?

/Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/420ddf3b/attachment-0001.html 

From jchris at mfdz.com  Mon Nov 20 14:12:16 2006
From: jchris at mfdz.com (Chris Anderson)
Date: Mon, 20 Nov 2006 11:12:16 -0800
Subject: [rspec-users] artificial sugar causes cancer
In-Reply-To: <f0b861390611200936j5379f884o7eb1fc2920baf481@mail.gmail.com>
References: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com>
	<8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com>
	<2CA122E4-B6CA-4CDD-ACDD-CCB735534030@olleolleolle.dk>
	<f0b861390611200936j5379f884o7eb1fc2920baf481@mail.gmail.com>
Message-ID: <e282921e0611201112w3a2d20c6je9904c4d3ac5b179@mail.gmail.com>

> >> @bdd_framework.should_be_adopted_quickly #current
> > >> @bdd_framework.should_be :adopted_quickly #proposed
> > >>
> > >
> > > I prefer the latter too
> >
> > Dude +1, the latter is so preferred.
>
>
symbol arguments ++ for sure!


I'm mostly indifferent/favoring the proposed changes, but note that for the
> above example, might it be confusing to drop the punctuation?
>
> @bdd_framework.should_be :adopted_quickly vs @bdd_framework.should_be
> :adopted_quickly?
>
>

Nick's point is interesting - automatically adding the '?' seems a little
magical. But the more I think about it, the more it seems like the right
thing to do. If I want to expect a value from a non-question-mark method, I
can always write:

my_object.method_without_question_mark.should_be true

Which is a little clearer, at least to me.

Three cheers for no more method missing!

-- 
Chris Anderson
http://jchris.mfdz.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/bb2870a6/attachment.html 

From lists-rspec at shopwatch.org  Mon Nov 20 14:41:11 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Mon, 20 Nov 2006 14:41:11 -0500
Subject: [rspec-users] artificial sugar causes cancer
In-Reply-To: <f0b861390611200936j5379f884o7eb1fc2920baf481@mail.gmail.com>
References: <57c63afe0611190529n53ac51d4y10d16447058211cc@mail.gmail.com>	<8d961d900611200700l6bc56feewd36883b64fb10caf@mail.gmail.com>	<2CA122E4-B6CA-4CDD-ACDD-CCB735534030@olleolleolle.dk>
	<f0b861390611200936j5379f884o7eb1fc2920baf481@mail.gmail.com>
Message-ID: <456204D7.8000900@rubyforge.org>

Nick Sieger wrote:

> I also happen to like the underscore approach in the case of things like 
> "array.should_be_empty" to test for "array.empty? == true".  But I'd 
> concede that syntax if we could settle on something else.  Maybe I just 
> need to retrain my own eyes to be more accepting of " array.should_be 
> :empty".  Is it just me?

No, I like .should_be_empty and its ilk too... but I understand that 
method_missing is a huge can of worms, so I'll sadly give it up if it 
makes the code more stable and gives the guys more time to work on stuff 
like integration testing!

Jay


From srbaker at pobox.com  Mon Nov 20 21:17:31 2006
From: srbaker at pobox.com (Steven Baker)
Date: Mon, 20 Nov 2006 18:17:31 -0800
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
Message-ID: <B8F3A108-4639-4428-ACFA-491FC3B748AA@pobox.com>

Not sure if you saw my RejectConf lightning talk, but I have a (poor)  
video of it.  :P

-Steven

On 20-Nov-06, at 6:07 PM, Brian Takita wrote:

> Hello,
>
> I'm scheduled to give a rspec brown bag this Wednesday (11/22) for  
> my company (Pivotal Computer Systems, http://www.pivotalsf.com). I  
> did see Dave Astel's talk as well as several of my coworkers.
> The developers at my workplace are experienced Agile developers.
>
> What would be some good things to focus on for this brown bag?
> Are there slides to presentations that would be useful?
> Any resistance/skepticism, and how to best address these concerns?
>
> I'm kindof nervous because there is some skepticism toward rspec  
> and BDD.
>
> Mainly:
> Test::Unit already does that, so why do we need rspec?
> It's not production ready. (Stack traces are too cluttered for  
> RspecOnRails; although this opinion was based on version 0.6)
> New people will be confused seeing rspec code (although this is  
> solved by more education, usage, encapsulation, etc.)
> BDD is TDD using "should" instead of "assert"
> There are also a number of people who do see benefits to using  
> rspec and are excited by it, so I do have "allies". :)
>
> I'm particularly interested in showing:
> How BDD is really good TDD without sounding religious
> How rspec encourages developers to create better "tests" than  
> Test::Unit
> Thank you,
> Brian Takita
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

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

From brian.takita at gmail.com  Mon Nov 20 20:43:21 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Nov 2006 17:43:21 -0800
Subject: [rspec-users] [rspec-devel] underscores, sugar,
	and more and more bugs
In-Reply-To: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com>
References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com>
Message-ID: <1d7ddd110611201743i1aba6d18h56440b6a8ba7bee6@mail.gmail.com>

On 11/19/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> I sent this earlier under with the subject "artificial sugar causes
> cancer" and I think some spam filters ate it. Here it is again:
> ======================================
>
> All,
>
> If you look at
> http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149
> you'll see that Chad (the submitter) found the source of the bug.
> Unfortunately, the source of *this* bug is the *solution* to a
> *previous bug* in which Rails was replacing RSpec's method missing
> with its own.
>
> When we settled on underscores, my one reservation was that we'd keep
> running into this particular problem - RSpec's method_missing
> conflicting with others.
>
> I have a proposition that preserves the underscore syntax, makes some
> examples even more clear, and eliminates this problem once and for
> all.
>
> 1. Eliminate reliance on method missing to handle expectations by
> adding all of the documented should_x_y_z methods directly to Object.
> These would all delegate off to Spec::Expectations::Should, ::Not,
> ::Have, etc, so the design wouldn't change much and Object itself,
> though bloated w/ methods, would not be bloated w/ implementation.
>
> This would also give us a single expectations module that we add to
> Object, providing several benefits including:
> # more clarity in the API
> # a place to put meaningful rdoc
> # a potential formal plugin point
>
> 2. Change should_be to ONLY handle arbitrary predicates (not serve as
> an alias for should_equal):
>
> subject.should_be :empty => passes if subject.empty?
> subject.should_be :instance_of, SomeClass => passes if
> subject.instance_of? SomeClass
> etc...
>
> In my opinion (feel free to disagree), this actually makes these
> examples more readable. Consider these two:
>
> @bdd_framework.should_be_adopted_quickly #current
> @bdd_framework.should_be :adopted_quickly #proposed


I was looking through Dave Astel's Mastermind tutorial. In it he had the
method win?
  should_be :win
seems clunky. I suppose that should_be supports past tense:
  should_be :won
and should supports present tense:
  should :win

Regarding the adopted_quickly example its:
  should_be :adopted_quickly
and
  should :adopt_quickly

I imagine that most of these boolean (?) methods are in present tense.

In my view, these read equally well from a language perspective AND
> they make it easier for a developer to mentally separate the
> expectation (should_be) from the expected value (adopted_quickly?).
>
> This WOULD require changes to existing specs. I think for those of you
> who don't wrap expectation args in parens that a trivial script would
> handle this for you. If you do use parens, the script might be more
> complex. Perhaps if we *do* choose this direction, one of you would
> like to contribute such a script.
>
> I fully recognize that this would cause some pain, but it is my
> feeling that not addressing this leaves us in a crippled position in
> which we commit to being sidetracked by this issue constantly
> returning instead of focusing on enhancing the API.
>
> I also think that this is a better option than any of the following
> that also crossed my mind:
> * revert to dots
> * figure out a sexy way to intercept all attempts to rewrite method
> missing and re-inject RSpec's method missing in its place (perhaps
> this does sound sexy, but I doth believe that there is a venereal
> disease hiding in its midst)
> * leave things as they are and continue to add ugly hacks like
> NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get
> so call it that)
> * hang myself from the nearest bridge
>
> Of course, if you have any solutions to propose, I'm all eyes.
>
> Thoughts?
>
> Thanks,
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/0ca85cea/attachment-0001.html 

From brian.takita at gmail.com  Mon Nov 20 21:23:49 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Nov 2006 18:23:49 -0800
Subject: [rspec-users] [rspec-devel] underscores, sugar,
	and more and more bugs
In-Reply-To: <1d7ddd110611201743i1aba6d18h56440b6a8ba7bee6@mail.gmail.com>
References: <57c63afe0611191334v360cb39cm8d272a067e13d363@mail.gmail.com>
	<1d7ddd110611201743i1aba6d18h56440b6a8ba7bee6@mail.gmail.com>
Message-ID: <1d7ddd110611201823n422a4903ibab932a40b7bf14e@mail.gmail.com>

On 11/20/06, Brian Takita <brian.takita at gmail.com> wrote:
>
> On 11/19/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> > I sent this earlier under with the subject "artificial sugar causes
> > cancer" and I think some spam filters ate it. Here it is again:
> > ======================================
> >
> > All,
> >
> > If you look at
> > http://rubyforge.org/tracker/index.php?func=detail&aid=6760&group_id=797&atid=3149
> > you'll see that Chad (the submitter) found the source of the bug.
> > Unfortunately, the source of *this* bug is the *solution* to a
> > *previous bug* in which Rails was replacing RSpec's method missing
> > with its own.
> >
> > When we settled on underscores, my one reservation was that we'd keep
> > running into this particular problem - RSpec's method_missing
> > conflicting with others.
> >
> > I have a proposition that preserves the underscore syntax, makes some
> > examples even more clear, and eliminates this problem once and for
> > all.
> >
> > 1. Eliminate reliance on method missing to handle expectations by
> > adding all of the documented should_x_y_z methods directly to Object.
> > These would all delegate off to Spec::Expectations::Should, ::Not,
> > ::Have, etc, so the design wouldn't change much and Object itself,
> > though bloated w/ methods, would not be bloated w/ implementation.
> >
> > This would also give us a single expectations module that we add to
> > Object, providing several benefits including:
> > # more clarity in the API
> > # a place to put meaningful rdoc
> > # a potential formal plugin point
> >
> > 2. Change should_be to ONLY handle arbitrary predicates (not serve as
> > an alias for should_equal):
> >
> > subject.should_be :empty => passes if subject.empty?
> > subject.should_be :instance_of, SomeClass => passes if
> > subject.instance_of? SomeClass
> > etc...
> >
> > In my opinion (feel free to disagree), this actually makes these
> > examples more readable. Consider these two:
> >
> > @bdd_framework.should_be_adopted_quickly #current
> > @bdd_framework.should_be :adopted_quickly #proposed
>
>
> I was looking through Dave Astel's Mastermind tutorial. In it he had the
> method win?
>   should_be :win
> seems clunky. I suppose that should_be supports past tense:
>   should_be :won
> and should supports present tense:
>   should :win
>
> Regarding the adopted_quickly example its:
>   should_be :adopted_quickly
> and
>   should :adopt_quickly
>

It also looks like should_be works with adjectives and past tense verbs with
adverbs.
  should be black?
  should be adopted quickly?

should seems to support using present tense verbs posed as a question.
  should adopt?

I apologize if this is old stuff that was already discussed.

I imagine that most of these boolean (?) methods are in present tense.
>
> In my view, these read equally well from a language perspective AND
> > they make it easier for a developer to mentally separate the
> > expectation (should_be) from the expected value (adopted_quickly?).
> >
> > This WOULD require changes to existing specs. I think for those of you
> > who don't wrap expectation args in parens that a trivial script would
> > handle this for you. If you do use parens, the script might be more
> > complex. Perhaps if we *do* choose this direction, one of you would
> > like to contribute such a script.
> >
> > I fully recognize that this would cause some pain, but it is my
> > feeling that not addressing this leaves us in a crippled position in
> > which we commit to being sidetracked by this issue constantly
> > returning instead of focusing on enhancing the API.
> >
> > I also think that this is a better option than any of the following
> > that also crossed my mind:
> > * revert to dots
> > * figure out a sexy way to intercept all attempts to rewrite method
> > missing and re-inject RSpec's method missing in its place (perhaps
> > this does sound sexy, but I doth believe that there is a venereal
> > disease hiding in its midst)
> > * leave things as they are and continue to add ugly hacks like
> > NilClass.handle_underscores_for_rspec! (that's MY ugly hack so I get
> > so call it that)
> > * hang myself from the nearest bridge
> >
> > Of course, if you have any solutions to propose, I'm all eyes.
> >
> > Thoughts?
> >
> > Thanks,
> > David
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/70ec1fa9/attachment.html 

From brian.takita at gmail.com  Mon Nov 20 22:35:58 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Nov 2006 19:35:58 -0800
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <B8F3A108-4639-4428-ACFA-491FC3B748AA@pobox.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
	<B8F3A108-4639-4428-ACFA-491FC3B748AA@pobox.com>
Message-ID: <1d7ddd110611201935i2840fbc6t61779c8233a18e0c@mail.gmail.com>

On 11/20/06, Steven Baker <srbaker at pobox.com> wrote:
>
> Not sure if you saw my RejectConf lightning talk, but I have a (poor)
> video of it.  :P
>

Yes I saw it. Do you have the video posted somewhere?

-Steven
> On 20-Nov-06, at 6:07 PM, Brian Takita wrote:
>
> Hello,
>
> I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my
> company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see
> Dave Astel's talk as well as several of my coworkers.
> The developers at my workplace are experienced Agile developers.
>
> What would be some good things to focus on for this brown bag?
> Are there slides to presentations that would be useful?
> Any resistance/skepticism, and how to best address these concerns?
>
> I'm kindof nervous because there is some skepticism toward rspec and BDD.
>
> Mainly:
>
>    - Test::Unit already does that, so why do we need rspec?
>    - It's not production ready. (Stack traces are too cluttered for
>    RspecOnRails; although this opinion was based on version 0.6)
>    - New people will be confused seeing rspec code (although this is
>    solved by more education, usage, encapsulation, etc.)
>    - BDD is TDD using "should" instead of "assert"
>
> There are also a number of people who do see benefits to using rspec and
> are excited by it, so I do have "allies". :)
>
> I'm particularly interested in showing:
>
>    - How BDD is really good TDD without sounding religious
>    - How rspec encourages developers to create better "tests" than
>    Test::Unit
>
> Thank you,
> Brian Takita
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/c2978e26/attachment.html 

From brian.takita at gmail.com  Mon Nov 20 21:07:34 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Nov 2006 18:07:34 -0800
Subject: [rspec-users] Rspec Brown Bag
Message-ID: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>

Hello,

I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my
company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see Dave
Astel's talk as well as several of my coworkers.
The developers at my workplace are experienced Agile developers.

What would be some good things to focus on for this brown bag?
Are there slides to presentations that would be useful?
Any resistance/skepticism, and how to best address these concerns?

I'm kindof nervous because there is some skepticism toward rspec and BDD.

Mainly:

   - Test::Unit already does that, so why do we need rspec?
   - It's not production ready. (Stack traces are too cluttered for
   RspecOnRails; although this opinion was based on version 0.6)
   - New people will be confused seeing rspec code (although this is
   solved by more education, usage, encapsulation, etc.)
   - BDD is TDD using "should" instead of "assert"

There are also a number of people who do see benefits to using rspec and are
excited by it, so I do have "allies". :)

I'm particularly interested in showing:

   - How BDD is really good TDD without sounding religious
   - How rspec encourages developers to create better "tests" than
   Test::Unit

Thank you,
Brian Takita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/f45ad744/attachment-0001.html 

From dchelimsky at gmail.com  Tue Nov 21 00:29:23 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 20 Nov 2006 23:29:23 -0600
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
Message-ID: <57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com>

On 11/20/06, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my
> company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see Dave
> Astel's talk as well as several of my coworkers.
> The developers at my workplace are experienced Agile developers.
>
> What would be some good things to focus on for this brown bag?
> Are there slides to presentations that would be useful?
> Any resistance/skepticism, and how to best address these concerns?
>
> I'm kindof nervous because there is some skepticism toward rspec and BDD.
>
> Mainly:
>
> Test::Unit already does that, so why do we need rspec?

The whole context/specify thing makes you see "testing" in a different
way. Sure, you can create multiple test cases to represent different
contexts, but by naming them in text, they become easier to read and
therefore easier to grok.

> It's not production ready. (Stack traces are too cluttered for RspecOnRails;
> although this opinion was based on version 0.6)

To some degree this seems true to me to me. While, with a few
exceptions, the rspec core API is quite stable now, the rails plugin
is quite volatile. For that reason, I think there is some risk to
adopting the rails plugin right now. It really depends on your team
and what the team values are. There is a lot to be gained from early
adoption. You just have to have that mindset.

> New people will be confused seeing rspec code (although this is solved by
> more education, usage, encapsulation, etc.)
> BDD is TDD using "should" instead of "assert"

If all that you know of BDD is rspec, that's an easy misunderstanding
to have. I'd give Dan North's blog a read to help understand the
greater context. In the end it's about language and collaboration
between technical people and non-technical people.

Also, even as a granular, developer practice (absent the wider team
piece), rspec offers clarity in the way you organize your specs (by
context). It offers clarity in the expression of expectations
(actual.should == expected vs assert_equal(:am_i_expected_or_actual,
:am_i_actual_or_expected).

> There are also a number of people who do see benefits to using rspec and are
> excited by it, so I do have "allies". :)
>
> I'm particularly interested in showing:
>
> How BDD is really good TDD without sounding religious
> How rspec encourages developers to create better "tests" than

Focus on your own experience. Do you believe that BDD changes the
conversation? Do you believe that you write better tests (if you MUST
call them that) because rspec encourages you to do so? If so, then try
to tap that. How are they better? Are you writing better code? Are
your designs simpler? Are they easier to change later? Etc, etc. If
the answer to these things is no, then you probably shouldn't be
evangelizing it. That would be dishonest. Just tell people about it
and what your experience is either way (the things you like, the
things you don't). 2 cents.

> Test::UnitThank you,
> Brian Takita
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From cwdinfo at gmail.com  Tue Nov 21 00:57:41 2006
From: cwdinfo at gmail.com (s.ross)
Date: Mon, 20 Nov 2006 21:57:41 -0800
Subject: [rspec-users] Documentation Nit
Message-ID: <F0107489-9A44-4B21-AF69-E3BA77D961CB@gmail.com>

I'm trying to wrap my head around rspec_on_rails and ran into the  
following documentation nit:

-------- what it says --------

You can specify :template, :text, or :action.
controller.should_render :template=>"path/to/template/for/action"
controller.should_render :text=>"expected text"
controller.should_render :action=>"expected_action"

-------- what it means --------

You can specify :template, :text, or :action, depending on how the  
rendering was supposed to happen in your code. So, for example, if  
you planned to render something as text, you would use:

controller.should_render :text => "it's a bird, it's a plane, nope,  
it's a bird alright."

If your controller is expected to render by action (and only by  
action), then then use :action. Here is some controller code:

def index
   list
   render :action => 'list'
end

and the spec for that:

specify "should render using the list *action*" do
   controller.should_render :action => 'list'
end

Note that while the above example works properly, the following  
fails, even though you knew the exact correct template name:

specify "should render using the list template" do
   controller.should_render :template => 'users/list'
end

Useful info? I'm a newbie, so just trying to help out.


From bkeepers at gmail.com  Tue Nov 21 01:13:58 2006
From: bkeepers at gmail.com (Brandon Keepers)
Date: Tue, 21 Nov 2006 01:13:58 -0500
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
Message-ID: <6E4B61B7-C59B-4CC5-817D-AF5619AB83F4@gmail.com>

One of the things that has sold me on rspec--besides the fact that it  
encourages better tests--is the ability to print out the specs from  
your app.  For example, the following are the start of some specs for  
an ecommerce app I am working on.  I can take my tests (specs derived  
from user stories) and generate documentation that I can hand  
directly to the customer, and it makes perfect sense to them.  There  
is no question as to what the app does and whether or not the specs  
are up to date.  That alone is worth it's weight in gold.

A user
- can purchase items
- should have many orders

A user purchasing items
- should create an order
- should add to the user's orders
- should create line items
- should set line item amount to the item's price
- should set line item amount to 0 if item does not have a price

An order
- should have line_items
- should have an invoice
- should be invalid without an amount

An invoice
- should have many orders
- should be invalid without an amount
- should have many payments
- should belong to a user

Paying an invoice
- should create a payment
- should set payment amount equal to invoice amount
- should set payment confirmation number

Calling invoice.pay with an invalid credit card
- should raise AuthorizationError

A payment
- should belong to an invoice
- should be invalid without an amount

Brandon

On Nov 20, 2006, at 9:07 PM, Brian Takita wrote:

> Hello,
>
> I'm scheduled to give a rspec brown bag this Wednesday (11/22) for  
> my company (Pivotal Computer Systems, http://www.pivotalsf.com). I  
> did see Dave Astel's talk as well as several of my coworkers.
> The developers at my workplace are experienced Agile developers.
>
> What would be some good things to focus on for this brown bag?
> Are there slides to presentations that would be useful?
> Any resistance/skepticism, and how to best address these concerns?
>
> I'm kindof nervous because there is some skepticism toward rspec  
> and BDD.
>
> Mainly:
> Test::Unit already does that, so why do we need rspec?
> It's not production ready. (Stack traces are too cluttered for  
> RspecOnRails; although this opinion was based on version 0.6)
> New people will be confused seeing rspec code (although this is  
> solved by more education, usage, encapsulation, etc.)
> BDD is TDD using "should" instead of "assert"
> There are also a number of people who do see benefits to using  
> rspec and are excited by it, so I do have "allies". :)
>
> I'm particularly interested in showing:
> How BDD is really good TDD without sounding religious
> How rspec encourages developers to create better "tests" than  
> Test::Unit
> Thank you,
> Brian Takita
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Tue Nov 21 02:15:59 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 21 Nov 2006 08:15:59 +0100
Subject: [rspec-users] Documentation Nit
In-Reply-To: <F0107489-9A44-4B21-AF69-E3BA77D961CB@gmail.com>
References: <F0107489-9A44-4B21-AF69-E3BA77D961CB@gmail.com>
Message-ID: <8d961d900611202315ke9eca68n8507a7b185ab11f@mail.gmail.com>

On 11/21/06, s.ross <cwdinfo at gmail.com> wrote:
> I'm trying to wrap my head around rspec_on_rails and ran into the
> following documentation nit:
>
> -------- what it says --------
>
> You can specify :template, :text, or :action.
> controller.should_render :template=>"path/to/template/for/action"
> controller.should_render :text=>"expected text"
> controller.should_render :action=>"expected_action"
>
> -------- what it means --------
>

Thanks, I've added this to the docs, which will be published with the
next release.

> You can specify :template, :text, or :action, depending on how the
> rendering was supposed to happen in your code. So, for example, if
> you planned to render something as text, you would use:
>
> controller.should_render :text => "it's a bird, it's a plane, nope,
> it's a bird alright."
>
> If your controller is expected to render by action (and only by
> action), then then use :action. Here is some controller code:
>
> def index
>    list
>    render :action => 'list'
> end
>
> and the spec for that:
>
> specify "should render using the list *action*" do
>    controller.should_render :action => 'list'
> end
>
> Note that while the above example works properly, the following
> fails, even though you knew the exact correct template name:
>
> specify "should render using the list template" do
>    controller.should_render :template => 'users/list'
> end
>
> Useful info? I'm a newbie, so just trying to help out.
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From marcus at marcusr.org.uk  Tue Nov 21 05:38:45 2006
From: marcus at marcusr.org.uk (Marcus Roberts)
Date: Tue, 21 Nov 2006 10:38:45 +0000
Subject: [rspec-users] assigns[] in trunk
Message-ID: <0329B74D-FA00-4BFB-BAE2-52EB06295379@marcusr.org.uk>

Hello,

I used the rspec_resource_generator to generate a set of specs, which  
produces quite a few specs that contain something like:

assigns(:customer).should == @customer

running this gives the error:

wrong number of arguments (1 for 0)
./spec/controllers/customers_controller_spec.rb:23:in `assigns'


In the rspec rails plugin trunk (revision 1126), in /lib/spec/rails/ 
context/controller.rb, assigns is defined as:

   def assigns
         @ivar_proxy ||= Spec::Rails::IvarProxy.new @controller
   end

whereas if i get the tagged version for 0_7_2  it was defined thus:

def assigns(key=nil)
           return assigns[key] unless key.nil?
          @ivar_proxy ||= Test::Rails::IvarProxy.new(controller)
end


So, if I change the code in my spec to

assigns[:customer].should == @customer

it works.

Is this the right thing to do at the moment for the trunk version of  
rspec and the plugin?

Thanks

Marcus



From dchelimsky at gmail.com  Tue Nov 21 08:00:27 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Nov 2006 07:00:27 -0600
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <1d7ddd110611202238y77c6af08j71b27cf9150b2ba@mail.gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
	<57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com>
	<1d7ddd110611202238y77c6af08j71b27cf9150b2ba@mail.gmail.com>
Message-ID: <57c63afe0611210500g110561cbk7f4da9a687b2014b@mail.gmail.com>

On 11/21/06, Brian Takita <brian.takita at gmail.com> wrote:
> Also, my coworker, Benny Sadeh advised me to treat the Brown Bag as a
> discussion and exploration of what can be learned from BDD and rspec.

Yes, yes, yes, yes! That is fantastic advice.

Please report back to let us know how it all went. Good and/or bad.

Good luck!
David

From dchelimsky at gmail.com  Tue Nov 21 08:06:14 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Nov 2006 07:06:14 -0600
Subject: [rspec-users] assigns[] in trunk
In-Reply-To: <0329B74D-FA00-4BFB-BAE2-52EB06295379@marcusr.org.uk>
References: <0329B74D-FA00-4BFB-BAE2-52EB06295379@marcusr.org.uk>
Message-ID: <57c63afe0611210506u26234bf9vf2d6be30091313de@mail.gmail.com>

Yes. That's in the documentation that will be part of the next
release. The plugin has always worked treating assigns as a hash. I
made it stop working using parens because one part of the system was
allowing parens and the another one wasn't. I wanted to unify them.

On 11/21/06, Marcus Roberts <marcus at marcusr.org.uk> wrote:
> Hello,
>
> I used the rspec_resource_generator to generate a set of specs, which
> produces quite a few specs that contain something like:
>
> assigns(:customer).should == @customer
>
> running this gives the error:
>
> wrong number of arguments (1 for 0)
> ./spec/controllers/customers_controller_spec.rb:23:in `assigns'
>
>
> In the rspec rails plugin trunk (revision 1126), in /lib/spec/rails/
> context/controller.rb, assigns is defined as:
>
>    def assigns
>          @ivar_proxy ||= Spec::Rails::IvarProxy.new @controller
>    end
>
> whereas if i get the tagged version for 0_7_2  it was defined thus:
>
> def assigns(key=nil)
>            return assigns[key] unless key.nil?
>           @ivar_proxy ||= Test::Rails::IvarProxy.new(controller)
> end
>
>
> So, if I change the code in my spec to
>
> assigns[:customer].should == @customer
>
> it works.
>
> Is this the right thing to do at the moment for the trunk version of
> rspec and the plugin?
>
> Thanks
>
> Marcus
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Tue Nov 21 08:48:17 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Nov 2006 07:48:17 -0600
Subject: [rspec-users] [rspec-devel] Specification Reuse to avoid
	Combinatorial Explosions
In-Reply-To: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com>
References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com>
Message-ID: <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com>

On 11/21/06, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> While reading Dan North's BDD tutorial, I tried to implement his ATM example
> as spec stubs.
> When I first implemented it creating a context for each of his scenarios, I
> noticed that there is duplication and a combinatorial explosion of the
> specs.
>
> I attached the full files to this email. For brevity, I will use scenario 1
> in the body of this email. For the purpose of this exercise, one should
> imagine that each specification is at least 5 lines.
>
> Here is how I implemented scenario 1:
>
> context %{A Withdrawal where an Account is in credit
>         AND the card is valid
>         AND the dispenser contains cash
>          AND the customer requests cash} do
>
>   specify "should debit the account" do
>   end
>   specify "should dispense cash" do
>   end
>   specify "should return the card" do
>   end
> end
>
> That got me experimenting on reusing specifications by using a module to
> create the specs. This is in
> customer_withdraws_cash_spec.rb:
>
> module CustomerWithdrawsCashSpec
>    def should_debit_the_account
>     specify "should debit the account" do
>     end
>   end
>   ...
> end
> ...
> context %{A Withdrawal where an Account is in credit
>          AND the card is valid
>         AND the dispenser contains cash
>         AND the customer requests cash} do
>
>    extend CustomerWithdrawsCashSpec
>   should_debit_the_account
>   should_dispense_cash
>    should_return_the_card
> end
>
> This is currently possible with rspec 0.7.2.
> Whats interesting about putting all of the specifications into a module is
> that you can reduce the context to a few lines.
> This makes each context (scenario readable) making it more feasible to have
> multiple contexts in a single file such as this group of scenarios
> represented as contexts.
>
> I also played with a more DSL-like syntax for this, which does not work for
> rspec 0.7.2. This is in
> customer_withdraws_cash_alternative_spec.rb::
>
> CustomerWithdrawsCashSpec = context_module do
>    specify "should debit the account" do
>   end
>    ...
> end
>
>  context %{A Withdrawal where an Account is in credit
>         AND the card is valid
>         AND the dispenser contains cash
>          AND the customer requests cash} do
>
>   extend CustomerWithdrawsCashSpec
>   specify "should debit the account"
>    specify "should dispense cash"
>   specify "should return the card"
>  end
>
> As well as:
>
> context %{A Withdrawal where an Account is in credit
>          AND the card is valid
>          AND the dispenser contains cash
>          AND the customer requests cash} do
>
>    specify "should debit the account", CustomerWithdrawsCashSpec
>    specify "should dispense cash", CustomerWithdrawsCashSpec
>    specify "should return the card", CustomerWithdrawsCashSpec
>  end
>
> Or just keep the underscore syntax:
>
> context %{A Withdrawal where an Account is in credit
>          AND the card is valid
>         AND the dispenser contains cash
>         AND the customer requests cash} do
>
>    extend CustomerWithdrawsCashSpec
>   should_debit_the_account
>   should_dispense_cash
>    should_return_the_card
> end

Interesting ideas. If we pursue this, I'd like to find an approach
that aligns w/ RSpecs current lack of constructs like classes and
modules. So rather than

CustomerWithdrawsCashSpec = context_module do ...

context "..." do
  extend CustomerWithdrawsCashSpec

I'd like something like

context_module :customer_withdraws_cash do

context "...", :customer_withdraws_cash do

That's not exactly right, but you get the idea.

Also - I think it would be really helpful for this discussion if you
*would* post the full specs so we can see what this stuff really looks
like in context.

Thanks Brian.

David

From nicksieger at gmail.com  Tue Nov 21 09:01:03 2006
From: nicksieger at gmail.com (Nick Sieger)
Date: Tue, 21 Nov 2006 08:01:03 -0600
Subject: [rspec-users] Spec Naming (was: Rspec Brown Bag)
Message-ID: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>

Thanks for posting your specdoc, Brandon -- they're a great example.

On 11/21/06, Brandon Keepers <bkeepers at gmail.com> wrote:

>
> A user purchasing items
> - should create an order
> - should add to the user's orders
> - should create line items
> - should set line item amount to the item's price
> - should set line item amount to 0 if item does not have a price


However, I've found myself now naming the specs themselves without the
"should" language, thinking that the spec body is where the should stuff
goes.  I like how the specdoc reads more confidently without it -- the spec
doc says, "this is the way things are" rather than "this is kinda sorta
maybe how the system works (if there are no bugs)".

context "A user purchasing items" do
  specify "creates an order" do
    @user.complete_purchase.should_be_instance_of Order
  end
  # ...
end

It's just a matter of taste in the end, I suppose, but is there a
recommended practice for naming specs?

Cheers,
/Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/5b9031f4/attachment.html 

From dchelimsky at gmail.com  Tue Nov 21 10:12:09 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Nov 2006 09:12:09 -0600
Subject: [rspec-users] Spec Naming (was: Rspec Brown Bag)
In-Reply-To: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>
References: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>
Message-ID: <57c63afe0611210712x474b05dcif0315a79b21570c6@mail.gmail.com>

On 11/21/06, Nick Sieger <nicksieger at gmail.com> wrote:
> Thanks for posting your specdoc, Brandon -- they're a great example.
>
> On 11/21/06, Brandon Keepers <bkeepers at gmail.com > wrote:
> >
> > A user purchasing items
> > - should create an order
> > - should add to the user's orders
> > - should create line items
> > - should set line item amount to the item's price
> > - should set line item amount to 0 if item does not have a price
>
> However, I've found myself now naming the specs themselves without the
> "should" language, thinking that the spec body is where the should stuff
> goes.  I like how the specdoc reads more confidently without it -- the spec
> doc says, "this is the way things are" rather than "this is kinda sorta
> maybe how the system works (if there are no bugs)".
>
> context "A user purchasing items" do
>   specify "creates an order" do
>     @user.complete_purchase.should_be_instance_of Order
>   end
>   # ...
> end
>
> It's just a matter of taste in the end, I suppose, but is there a
> recommended practice for naming specs?

When you look at the specs what you propose makes sense, however when
you read the output I think using "should" in the names helps to
convey the "spec-ness" of the specs. To me.

From nicksieger at gmail.com  Tue Nov 21 11:51:20 2006
From: nicksieger at gmail.com (Nick Sieger)
Date: Tue, 21 Nov 2006 10:51:20 -0600
Subject: [rspec-users] Spec Naming (was: Rspec Brown Bag)
In-Reply-To: <57c63afe0611210712x474b05dcif0315a79b21570c6@mail.gmail.com>
References: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>
	<57c63afe0611210712x474b05dcif0315a79b21570c6@mail.gmail.com>
Message-ID: <f0b861390611210851u3fb8b6acpb58228ca314c40aa@mail.gmail.com>

On 11/21/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> When you look at the specs what you propose makes sense, however when
> you read the output I think using "should" in the names helps to
> convey the "spec-ness" of the specs. To me.


This got me thinking about RFC-2119 recommended language for requirement
levels [1].  This would obviously be a big change in direction for RSpec,
but what if:

object.must == value # => required; produces error
object.should == value # => recommended; produces warning
object.may == value # => informational message that an optional feature is
not provided

Of course, the utility of this is questionable for RSpec.  It might be
interesting for a tool (not RSpec, but something like it) that's essentially
a portable specification language that can be applied to more than one
implementation.  But now we're not really talking about BDD, so forgive me
for straying OT.

Cheers,
/Nick

[1]: http://tools.ietf.org/html/rfc2119
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/7c601bf4/attachment.html 

From brian.takita at gmail.com  Tue Nov 21 01:38:19 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Nov 2006 22:38:19 -0800
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
	<57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com>
Message-ID: <1d7ddd110611202238y77c6af08j71b27cf9150b2ba@mail.gmail.com>

On 11/20/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 11/20/06, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my
> > company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see
> Dave
> > Astel's talk as well as several of my coworkers.
> > The developers at my workplace are experienced Agile developers.
> >
> > What would be some good things to focus on for this brown bag?
> > Are there slides to presentations that would be useful?
> > Any resistance/skepticism, and how to best address these concerns?
> >
> > I'm kindof nervous because there is some skepticism toward rspec and
> BDD.
> >
> > Mainly:
> >
> > Test::Unit already does that, so why do we need rspec?
>
> The whole context/specify thing makes you see "testing" in a different
> way. Sure, you can create multiple test cases to represent different
> contexts, but by naming them in text, they become easier to read and
> therefore easier to grok.


I like that. It goes into the intent of the code. It seems even more
important when pairs are switched frequently.

> It's not production ready. (Stack traces are too cluttered for
> RspecOnRails;
> > although this opinion was based on version 0.6)
>
> To some degree this seems true to me to me. While, with a few
> exceptions, the rspec core API is quite stable now, the rails plugin
> is quite volatile. For that reason, I think there is some risk to
> adopting the rails plugin right now. It really depends on your team
> and what the team values are. There is a lot to be gained from early
> adoption. You just have to have that mindset.


That makes sense. It seems like the best opportunity to use rspec on rails
would be in starting a new project.

> New people will be confused seeing rspec code (although this is solved by
> > more education, usage, encapsulation, etc.)
> > BDD is TDD using "should" instead of "assert"
>
> If all that you know of BDD is rspec, that's an easy misunderstanding
> to have. I'd give Dan North's blog a read to help understand the
> greater context. In the end it's about language and collaboration
> between technical people and non-technical people.


Yes, I just started reading his blog. I like his perspective on
communication with the client and his simple specification process in
his Introducing
BDD <http://dannorth.net/introducing-bdd> article.

Also, even as a granular, developer practice (absent the wider team
> piece), rspec offers clarity in the way you organize your specs (by
> context). It offers clarity in the expression of expectations
> (actual.should == expected vs assert_equal(:am_i_expected_or_actual,
> :am_i_actual_or_expected).
>
> > There are also a number of people who do see benefits to using rspec and
> are
> > excited by it, so I do have "allies". :)
> >
> > I'm particularly interested in showing:
> >
> > How BDD is really good TDD without sounding religious
> > How rspec encourages developers to create better "tests" than
>
> Focus on your own experience. Do you believe that BDD changes the
> conversation? Do you believe that you write better tests (if you MUST
> call them that)


I like specs and behaviour myself. :)

because rspec encourages you to do so? If so, then try
> to tap that. How are they better? Are you writing better code? Are
> your designs simpler? Are they easier to change later? Etc, etc. If
> the answer to these things is no, then you probably shouldn't be
> evangelizing it. That would be dishonest. Just tell people about it
> and what your experience is either way (the things you like, the
> things you don't). 2 cents.


These are all good that set the appropriate tone for the brown bag. Theres
alot to think about here. Thank you.

Also, my coworker, Benny Sadeh advised me to treat the Brown Bag as a
discussion and exploration of what can be learned from BDD and rspec. The
group will probably be fairly sizable (mid to high teens) but that should be
managable.

> Test::UnitThank you,
> > Brian Takita
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/2608cc2a/attachment.html 

From brian.takita at gmail.com  Tue Nov 21 01:39:17 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Mon, 20 Nov 2006 22:39:17 -0800
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <6E4B61B7-C59B-4CC5-817D-AF5619AB83F4@gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
	<6E4B61B7-C59B-4CC5-817D-AF5619AB83F4@gmail.com>
Message-ID: <1d7ddd110611202239g176a905eidb855b314e3bf98c@mail.gmail.com>

On 11/20/06, Brandon Keepers <bkeepers at gmail.com> wrote:
>
> One of the things that has sold me on rspec--besides the fact that it
> encourages better tests--is the ability to print out the specs from
> your app.  For example, the following are the start of some specs for
> an ecommerce app I am working on.  I can take my tests (specs derived
> from user stories) and generate documentation that I can hand
> directly to the customer, and it makes perfect sense to them.  There
> is no question as to what the app does and whether or not the specs
> are up to date.  That alone is worth it's weight in gold.


Agreed. This is a sweet feature.

A user
> - can purchase items
> - should have many orders
>
> A user purchasing items
> - should create an order
> - should add to the user's orders
> - should create line items
> - should set line item amount to the item's price
> - should set line item amount to 0 if item does not have a price
>
> An order
> - should have line_items
> - should have an invoice
> - should be invalid without an amount
>
> An invoice
> - should have many orders
> - should be invalid without an amount
> - should have many payments
> - should belong to a user
>
> Paying an invoice
> - should create a payment
> - should set payment amount equal to invoice amount
> - should set payment confirmation number
>
> Calling invoice.pay with an invalid credit card
> - should raise AuthorizationError
>
> A payment
> - should belong to an invoice
> - should be invalid without an amount
>
> Brandon
>
> On Nov 20, 2006, at 9:07 PM, Brian Takita wrote:
>
> > Hello,
> >
> > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for
> > my company (Pivotal Computer Systems, http://www.pivotalsf.com). I
> > did see Dave Astel's talk as well as several of my coworkers.
> > The developers at my workplace are experienced Agile developers.
> >
> > What would be some good things to focus on for this brown bag?
> > Are there slides to presentations that would be useful?
> > Any resistance/skepticism, and how to best address these concerns?
> >
> > I'm kindof nervous because there is some skepticism toward rspec
> > and BDD.
> >
> > Mainly:
> > Test::Unit already does that, so why do we need rspec?
> > It's not production ready. (Stack traces are too cluttered for
> > RspecOnRails; although this opinion was based on version 0.6)
> > New people will be confused seeing rspec code (although this is
> > solved by more education, usage, encapsulation, etc.)
> > BDD is TDD using "should" instead of "assert"
> > There are also a number of people who do see benefits to using
> > rspec and are excited by it, so I do have "allies". :)
> >
> > I'm particularly interested in showing:
> > How BDD is really good TDD without sounding religious
> > How rspec encourages developers to create better "tests" than
> > Test::Unit
> > Thank you,
> > Brian Takita
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061120/52ec1174/attachment.html 

From brian.takita at gmail.com  Tue Nov 21 04:52:18 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Nov 2006 01:52:18 -0800
Subject: [rspec-users] Specification Reuse to avoid Combinatorial Explosions
Message-ID: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com>

Hello,

While reading Dan North's BDD tutorial <http://dannorth.net/introducing-bdd>,
I tried to implement his ATM example as spec stubs.
When I first implemented it creating a context for each of his scenarios, I
noticed that there is duplication and a combinatorial explosion of the
specs.

I attached the full files to this email. For brevity, I will use scenario 1
in the body of this email. For the purpose of this exercise, one should
imagine that each specification is at least 5 lines.

Here is how I implemented scenario 1:

context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser contains cash
        AND the customer requests cash} do

  specify "should debit the account" do
  end
  specify "should dispense cash" do
  end
  specify "should return the card" do
  end
end

That got me experimenting on reusing specifications by using a module to
create the specs. This is in customer_withdraws_cash_spec.rb:

module CustomerWithdrawsCashSpec
  def should_debit_the_account
    specify "should debit the account" do
    end
  end
  ...
end
...
context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser contains cash
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  should_debit_the_account
  should_dispense_cash
  should_return_the_card
end

This is currently possible with rspec 0.7.2.
Whats interesting about putting all of the specifications into a module is
that you can reduce the context to a few lines.
This makes each context (scenario readable) making it more feasible to have
multiple contexts in a single file such as this group of scenarios
represented as contexts.

I also played with a more DSL-like syntax for this, which does not work for
rspec 0.7.2. This is in customer_withdraws_cash_alternative_spec.rb::

CustomerWithdrawsCashSpec = context_module do
  specify "should debit the account" do
  end
  ...
end

context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser contains cash
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  specify "should debit the account"
  specify "should dispense cash"
  specify "should return the card"
end

As well as:

context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser contains cash
        AND the customer requests cash} do

  specify "should debit the account", CustomerWithdrawsCashSpec
  specify "should dispense cash", CustomerWithdrawsCashSpec
  specify "should return the card", CustomerWithdrawsCashSpec
end

Or just keep the underscore syntax:

context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser contains cash
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  should_debit_the_account
  should_dispense_cash
  should_return_the_card
end

Thanks,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/64922509/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customer_withdraws_cash_spec.rb
Type: application/x-ruby
Size: 2383 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-users/attachments/20061121/64922509/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: customer_withdraws_cash_alternative_spec.rb
Type: application/x-ruby
Size: 2300 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-users/attachments/20061121/64922509/attachment-0003.bin 

From contact at lukeredpath.co.uk  Tue Nov 21 12:06:58 2006
From: contact at lukeredpath.co.uk (Luke Redpath)
Date: Tue, 21 Nov 2006 17:06:58 +0000
Subject: [rspec-users] Spec Naming (was: Rspec Brown Bag)
In-Reply-To: <f0b861390611210851u3fb8b6acpb58228ca314c40aa@mail.gmail.com>
References: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>
	<57c63afe0611210712x474b05dcif0315a79b21570c6@mail.gmail.com>
	<f0b861390611210851u3fb8b6acpb58228ca314c40aa@mail.gmail.com>
Message-ID: <0C37DEE5-8606-4F35-B98A-92E7674C88F4@lukeredpath.co.uk>

I'm not sure if that would really work with RSpec - the way I see it,  
when you say a behaviour is *optional*, what you really  mean is that  
that behaviour only happens under certain circumstances (i.e. a  
particular context). Of course this is already handled by setting  
specifications under certain contexts. Within a particular context a  
behaviour either happens or it doesn't, I don't think there should be  
any middle ground. Ultimately we are only concerned with what WILL  
happen under certain contexts, not things that may or may not happen  
(which is an observation at a level higher than we are working on).

Cheers
Luke

> object.must == value # => required; produces error
> object.should == value # => recommended; produces warning
> object.may == value # => informational message that an optional  
> feature is not provided
>
> Of course, the utility of this is questionable for RSpec.  It might  
> be interesting for a tool (not RSpec, but something like it) that's  
> essentially a portable specification language that can be applied  
> to more than one implementation.  But now we're not really talking  
> about BDD, so forgive me for straying OT.
>
> Cheers,
> /Nick
>
> [1]: http://tools.ietf.org/html/rfc2119
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/55376f21/attachment-0001.html 

From cwdinfo at gmail.com  Tue Nov 21 14:35:21 2006
From: cwdinfo at gmail.com (s.ross)
Date: Tue, 21 Nov 2006 11:35:21 -0800
Subject: [rspec-users] Spec Naming (was: Rspec Brown Bag)
In-Reply-To: <0C37DEE5-8606-4F35-B98A-92E7674C88F4@lukeredpath.co.uk>
References: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>
	<57c63afe0611210712x474b05dcif0315a79b21570c6@mail.gmail.com>
	<f0b861390611210851u3fb8b6acpb58228ca314c40aa@mail.gmail.com>
	<0C37DEE5-8606-4F35-B98A-92E7674C88F4@lukeredpath.co.uk>
Message-ID: <9A934119-BA91-447D-9992-B4468BEA6B3E@gmail.com>

I agree with Luke. If you say something "may" happen, you haven't  
asserted any constraints on your program behavior. Unless I  
misunderstand how this was intended. Consider this artificial example:

context "the weather" do
   specify "it should be a gray day (or is that a grey day)" do
     the_sky.should_be :cloudy
     the_ground.may_be :wet
     the_ground.may_be :snowy
   end
end

What do the last two test tell us? Will the specs be demonstrably  
implemented or not as a result of them? As I said, I'm a newbie at  
this, but it makes more sense to me to state this:

context "the weather" do
   specify "it should be a gray day (or is that a grey day)" do
     the_sky.should_be :cloudy
   end

   specify "it should be raining" do
     the_ground.should_be :wet
   end

   specify "it should be snowing" do
     the_ground.may_be :snowy
   end
end

Is that too verbose?

Steve

On Nov 21, 2006, at 9:06 AM, Luke Redpath wrote:

> I'm not sure if that would really work with RSpec - the way I see  
> it, when you say a behaviour is *optional*, what you really  mean  
> is that that behaviour only happens under certain circumstances  
> (i.e. a particular context). Of course this is already handled by  
> setting specifications under certain contexts. Within a particular  
> context a behaviour either happens or it doesn't, I don't think  
> there should be any middle ground. Ultimately we are only concerned  
> with what WILL happen under certain contexts, not things that may  
> or may not happen (which is an observation at a level higher than  
> we are working on).
>
> Cheers
> Luke
>
>> object.must == value # => required; produces error
>> object.should == value # => recommended; produces warning
>> object.may == value # => informational message that an optional  
>> feature is not provided
>>
>> Of course, the utility of this is questionable for RSpec.  It  
>> might be interesting for a tool (not RSpec, but something like it)  
>> that's essentially a portable specification language that can be  
>> applied to more than one implementation.  But now we're not really  
>> talking about BDD, so forgive me for straying OT.
>>
>> Cheers,
>> /Nick
>>
>> [1]: http://tools.ietf.org/html/rfc2119
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

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

From bkeepers at gmail.com  Tue Nov 21 15:51:56 2006
From: bkeepers at gmail.com (Brandon Keepers)
Date: Tue, 21 Nov 2006 15:51:56 -0500
Subject: [rspec-users] [rspec-devel] Specification Reuse to avoid
	Combinatorial Explosions
In-Reply-To: <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com>
References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com>
	<57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com>
Message-ID: <2A0981DC-A32F-4BCB-8141-22B44AB5869F@gmail.com>

One of the things I've often wished for is nested contexts.  This  
could help eliminate some duplication.

context "A Widthdrawal" do
   context "where an Account is in credit" do
     context "and the card is valid"
         context "and the dispenser contains cash" do

           specify "should debit the account" do
           end
           specify "should dispense cash" do
           end
           specify "should return the card" do
           end

         end

         context "and the dispenser does not contain cash" do

           specify "should inform the user" do
           end

         end
     end
   end
end

Brandon

On Nov 21, 2006, at 8:48 AM, David Chelimsky wrote:

> On 11/21/06, Brian Takita <brian.takita at gmail.com> wrote:
>> Hello,
>>
>> While reading Dan North's BDD tutorial, I tried to implement his  
>> ATM example
>> as spec stubs.
>> When I first implemented it creating a context for each of his  
>> scenarios, I
>> noticed that there is duplication and a combinatorial explosion of  
>> the
>> specs.
>>
>> I attached the full files to this email. For brevity, I will use  
>> scenario 1
>> in the body of this email. For the purpose of this exercise, one  
>> should
>> imagine that each specification is at least 5 lines.
>>
>> Here is how I implemented scenario 1:
>>
>> context %{A Withdrawal where an Account is in credit
>>         AND the card is valid
>>         AND the dispenser contains cash
>>          AND the customer requests cash} do
>>
>>   specify "should debit the account" do
>>   end
>>   specify "should dispense cash" do
>>   end
>>   specify "should return the card" do
>>   end
>> end
>>
>> That got me experimenting on reusing specifications by using a  
>> module to
>> create the specs. This is in
>> customer_withdraws_cash_spec.rb:
>>
>> module CustomerWithdrawsCashSpec
>>    def should_debit_the_account
>>     specify "should debit the account" do
>>     end
>>   end
>>   ...
>> end
>> ...
>> context %{A Withdrawal where an Account is in credit
>>          AND the card is valid
>>         AND the dispenser contains cash
>>         AND the customer requests cash} do
>>
>>    extend CustomerWithdrawsCashSpec
>>   should_debit_the_account
>>   should_dispense_cash
>>    should_return_the_card
>> end
>>
>> This is currently possible with rspec 0.7.2.
>> Whats interesting about putting all of the specifications into a  
>> module is
>> that you can reduce the context to a few lines.
>> This makes each context (scenario readable) making it more  
>> feasible to have
>> multiple contexts in a single file such as this group of scenarios
>> represented as contexts.
>>
>> I also played with a more DSL-like syntax for this, which does not  
>> work for
>> rspec 0.7.2. This is in
>> customer_withdraws_cash_alternative_spec.rb::
>>
>> CustomerWithdrawsCashSpec = context_module do
>>    specify "should debit the account" do
>>   end
>>    ...
>> end
>>
>>  context %{A Withdrawal where an Account is in credit
>>         AND the card is valid
>>         AND the dispenser contains cash
>>          AND the customer requests cash} do
>>
>>   extend CustomerWithdrawsCashSpec
>>   specify "should debit the account"
>>    specify "should dispense cash"
>>   specify "should return the card"
>>  end
>>
>> As well as:
>>
>> context %{A Withdrawal where an Account is in credit
>>          AND the card is valid
>>          AND the dispenser contains cash
>>          AND the customer requests cash} do
>>
>>    specify "should debit the account", CustomerWithdrawsCashSpec
>>    specify "should dispense cash", CustomerWithdrawsCashSpec
>>    specify "should return the card", CustomerWithdrawsCashSpec
>>  end
>>
>> Or just keep the underscore syntax:
>>
>> context %{A Withdrawal where an Account is in credit
>>          AND the card is valid
>>         AND the dispenser contains cash
>>         AND the customer requests cash} do
>>
>>    extend CustomerWithdrawsCashSpec
>>   should_debit_the_account
>>   should_dispense_cash
>>    should_return_the_card
>> end
>
> Interesting ideas. If we pursue this, I'd like to find an approach
> that aligns w/ RSpecs current lack of constructs like classes and
> modules. So rather than
>
> CustomerWithdrawsCashSpec = context_module do ...
>
> context "..." do
>   extend CustomerWithdrawsCashSpec
>
> I'd like something like
>
> context_module :customer_withdraws_cash do
>
> context "...", :customer_withdraws_cash do
>
> That's not exactly right, but you get the idea.
>
> Also - I think it would be really helpful for this discussion if you
> *would* post the full specs so we can see what this stuff really looks
> like in context.
>
> Thanks Brian.
>
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From bkeepers at gmail.com  Tue Nov 21 11:30:20 2006
From: bkeepers at gmail.com (Brandon Keepers)
Date: Tue, 21 Nov 2006 11:30:20 -0500
Subject: [rspec-users] Spec Naming (was: Rspec Brown Bag)
In-Reply-To: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>
References: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>
Message-ID: <D828EB89-946A-44EC-B19F-4F5D7A00DD9A@gmail.com>


On Nov 21, 2006, at 9:01 AM, Nick Sieger wrote:

> It's just a matter of taste in the end, I suppose, but is there a  
> recommended practice for naming specs?

I use "should" simply because it's easier.  That's the mindset I'm in  
when I'm writing them.  I also think that it reenforces the idea that  
it is a specification, and not simply a test.

> Cheers,
> /Nick

Brandon


From dchelimsky at gmail.com  Tue Nov 21 16:08:22 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Nov 2006 15:08:22 -0600
Subject: [rspec-users] [rspec-devel] Specification Reuse to avoid
	Combinatorial Explosions
In-Reply-To: <2A0981DC-A32F-4BCB-8141-22B44AB5869F@gmail.com>
References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com>
	<57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com>
	<2A0981DC-A32F-4BCB-8141-22B44AB5869F@gmail.com>
Message-ID: <57c63afe0611211308w7f8866a1ydebfe3019e928000@mail.gmail.com>

On 11/21/06, Brandon Keepers <bkeepers at gmail.com> wrote:
> One of the things I've often wished for is nested contexts.  This
> could help eliminate some duplication.

We've been through this a couple of times. Give this one a read please:

http://rubyforge.org/pipermail/rspec-devel/2006-June/000175.html

From dchelimsky at gmail.com  Tue Nov 21 16:12:23 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 21 Nov 2006 15:12:23 -0600
Subject: [rspec-users] [rspec-devel] Specification Reuse to avoid
	Combinatorial Explosions
In-Reply-To: <57c63afe0611211308w7f8866a1ydebfe3019e928000@mail.gmail.com>
References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com>
	<57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com>
	<2A0981DC-A32F-4BCB-8141-22B44AB5869F@gmail.com>
	<57c63afe0611211308w7f8866a1ydebfe3019e928000@mail.gmail.com>
Message-ID: <57c63afe0611211312k1bc4c8fcy29556306fd3cafcd@mail.gmail.com>

On 11/21/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 11/21/06, Brandon Keepers <bkeepers at gmail.com> wrote:
> > One of the things I've often wished for is nested contexts.  This
> > could help eliminate some duplication.
>
> We've been through this a couple of times. Give this one a read please:
>
> http://rubyforge.org/pipermail/rspec-devel/2006-June/000175.html

Specifically this reply from me:
http://rubyforge.org/pipermail/rspec-devel/2006-June/000201.html

From nicksieger at gmail.com  Tue Nov 21 17:32:23 2006
From: nicksieger at gmail.com (Nick Sieger)
Date: Tue, 21 Nov 2006 16:32:23 -0600
Subject: [rspec-users] Spec Naming (was: Rspec Brown Bag)
In-Reply-To: <0C37DEE5-8606-4F35-B98A-92E7674C88F4@lukeredpath.co.uk>
References: <f0b861390611210601q4201383k1d1fc7c33bb29f23@mail.gmail.com>
	<57c63afe0611210712x474b05dcif0315a79b21570c6@mail.gmail.com>
	<f0b861390611210851u3fb8b6acpb58228ca314c40aa@mail.gmail.com>
	<0C37DEE5-8606-4F35-B98A-92E7674C88F4@lukeredpath.co.uk>
Message-ID: <f0b861390611211432m1215d8acv54f3a55f7c5d7bd4@mail.gmail.com>

On 11/21/06, Luke Redpath <contact at lukeredpath.co.uk> wrote:
>
> I'm not sure if that would really work with RSpec - the way I see it, when
> you say a behaviour is *optional*, what you really  mean is that that
> behaviour only happens under certain circumstances (i.e. a particular
> context). Of course this is already handled by setting specifications under
> certain contexts. Within a particular context a behaviour either happens or
> it doesn't, I don't think there should be any middle ground. Ultimately we
> are only concerned with what WILL happen under certain contexts, not things
> that may or may not happen (which is an observation at a level higher than
> we are working on).
>

Agree, which is why I think this type of feature doesn't make sense for BDD,
where you're using the specs to drive the implementation.  You are writing
the specs and the code, so you know exactly how the code "should" behave.

/Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/1721b43a/attachment.html 

From aslak.hellesoy at gmail.com  Tue Nov 21 18:46:25 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 22 Nov 2006 00:46:25 +0100
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
Message-ID: <8d961d900611211546o2060fc5cgee9d8990755b1a8f@mail.gmail.com>

On 11/21/06, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my
> company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see Dave
> Astel's talk as well as several of my coworkers.
> The developers at my workplace are experienced Agile developers.
>
> What would be some good things to focus on for this brown bag?
> Are there slides to presentations that would be useful?
> Any resistance/skepticism, and how to best address these concerns?
>

I have had success with an explanation of the TDD journey as described here:
http://www.behaviour-driven.org/TDDAdoptionProfile

I usually present it with takahashi-style slides
(http://tinyurl.com/o6psh) with the following words (one on each
slide):
* tests
* confidence
* before
* documentation
* discovery
* behaviour
* mocking

> I'm kindof nervous because there is some skepticism toward rspec and BDD.
>
> Mainly:
>
> Test::Unit already does that, so why do we need rspec?
> It's not production ready. (Stack traces are too cluttered for RspecOnRails;
> although this opinion was based on version 0.6)
> New people will be confused seeing rspec code (although this is solved by
> more education, usage, encapsulation, etc.)
> BDD is TDD using "should" instead of "assert"
> There are also a number of people who do see benefits to using rspec and are
> excited by it, so I do have "allies". :)
>
> I'm particularly interested in showing:
>
> How BDD is really good TDD without sounding religious
> How rspec encourages developers to create better "tests" than
> Test::UnitThank you,
> Brian Takita
>
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From dylanegan at gmail.com  Tue Nov 21 19:42:47 2006
From: dylanegan at gmail.com (Dylan Egan)
Date: Wed, 22 Nov 2006 11:42:47 +1100
Subject: [rspec-users] Controller Isolation
Message-ID: <cbbc1640611211642l6d566e50yd54c7172f7e6f8e3@mail.gmail.com>

Hi,

I have a project that I had running under rspec 0.6.x and recently upgraded
to 0.7.2.

I am trying to isolate my controllers from the database as I go through and
change all the specs to run under 0.7.2.

I am having a problem where I need to make the create! method return the
mocked object as well as raise RecordInvalid exception. Is this at all
possible?

I use the rescue statement in my controller methods and not @
object.new_record? or @object.valid? to check whether to redirect or render.

-- controller --

  def create
    @star = Star.create!(params[:star])
    redirect_to star_path(@star)
  rescue ActiveRecord::RecordInvalid
    render :action => 'new'
  end

-- spec --
  @star = mock('star')
  Star.should_receive(:create!).with({ 'name' => nil }).and_return(@star)

I'm new to all the mocking/stubbing business so my head spins are turning
into headaches. :)

Dylan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061122/9c0bfc6f/attachment.html 

From brian.takita at gmail.com  Tue Nov 21 20:35:06 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 21 Nov 2006 17:35:06 -0800
Subject: [rspec-users] [rspec-devel] Specification Reuse to avoid
	Combinatorial Explosions
In-Reply-To: <57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com>
References: <1d7ddd110611210152m2c70323dt2b812fe4aa9f3bdc@mail.gmail.com>
	<57c63afe0611210548s74ae9ca3y59a453dedb1e5d4e@mail.gmail.com>
Message-ID: <1d7ddd110611211735m3620744ic67eafab5b20ab26@mail.gmail.com>

On 11/21/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 11/21/06, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > While reading Dan North's BDD tutorial, I tried to implement his ATM
> example
> > as spec stubs.
> > When I first implemented it creating a context for each of his
> scenarios, I
> > noticed that there is duplication and a combinatorial explosion of the
> > specs.
> >
> > I attached the full files to this email. For brevity, I will use
> scenario 1
> > in the body of this email. For the purpose of this exercise, one should
> > imagine that each specification is at least 5 lines.
> >
> > Here is how I implemented scenario 1:
> >
> > context %{A Withdrawal where an Account is in credit
> >         AND the card is valid
> >         AND the dispenser contains cash
> >          AND the customer requests cash} do
> >
> >   specify "should debit the account" do
> >   end
> >   specify "should dispense cash" do
> >   end
> >   specify "should return the card" do
> >   end
> > end
> >
> > That got me experimenting on reusing specifications by using a module to
>
> > create the specs. This is in
> > customer_withdraws_cash_spec.rb:
> >
> > module CustomerWithdrawsCashSpec
> >    def should_debit_the_account
> >     specify "should debit the account" do
> >     end
> >   end
> >   ...
> > end
> > ...
> > context %{A Withdrawal where an Account is in credit
> >          AND the card is valid
> >         AND the dispenser contains cash
> >         AND the customer requests cash} do
> >
> >    extend CustomerWithdrawsCashSpec
> >   should_debit_the_account
> >   should_dispense_cash
> >    should_return_the_card
> > end
> >
> > This is currently possible with rspec 0.7.2 .
> > Whats interesting about putting all of the specifications into a module
> is
> > that you can reduce the context to a few lines.
> > This makes each context (scenario readable) making it more feasible to
> have
> > multiple contexts in a single file such as this group of scenarios
> > represented as contexts.
> >
> > I also played with a more DSL-like syntax for this, which does not work
> for
> > rspec 0.7.2. This is in
> > customer_withdraws_cash_alternative_spec.rb::
> >
> > CustomerWithdrawsCashSpec = context_module do
> >    specify "should debit the account" do
> >   end
> >    ...
> > end
> >
> >  context %{A Withdrawal where an Account is in credit
> >         AND the card is valid
> >         AND the dispenser contains cash
> >          AND the customer requests cash} do
> >
> >   extend CustomerWithdrawsCashSpec
> >   specify "should debit the account"
> >    specify "should dispense cash"
> >   specify "should return the card"
> >  end
> >
> > As well as:
> >
> > context %{A Withdrawal where an Account is in credit
> >          AND the card is valid
> >          AND the dispenser contains cash
> >          AND the customer requests cash} do
> >
> >    specify "should debit the account", CustomerWithdrawsCashSpec
> >    specify "should dispense cash", CustomerWithdrawsCashSpec
> >    specify "should return the card", CustomerWithdrawsCashSpec
> >  end
> >
> > Or just keep the underscore syntax:
> >
> > context %{A Withdrawal where an Account is in credit
> >          AND the card is valid
> >         AND the dispenser contains cash
> >         AND the customer requests cash} do
> >
> >    extend CustomerWithdrawsCashSpec
> >   should_debit_the_account
> >   should_dispense_cash
> >    should_return_the_card
> > end
>
> Interesting ideas. If we pursue this, I'd like to find an approach
> that aligns w/ RSpecs current lack of constructs like classes and
> modules. So rather than
>
> CustomerWithdrawsCashSpec = context_module do ...
>
> context "..." do
>   extend CustomerWithdrawsCashSpec
>
> I'd like something like
>
> context_module :customer_withdraws_cash do
>
> context "...", :customer_withdraws_cash do
>
> That's not exactly right, but you get the idea.
>
> Also - I think it would be really helpful for this discussion if you
> *would* post the full specs so we can see what this stuff really looks
> like in context.


I sent the files as attachments. I guess they got rejected.

Here is the file that works now:

require "rubygems"
require "spec"

ARGV << "--format"
ARGV << "specdoc"

=begin
Title: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don't have to wait in line at the bank.
=end

module CustomerWithdrawsCashSpec
  def should_debit_the_account
    specify "should debit the account" do
    end
  end

  def should_display_a_rejection_message
    specify "should display a rejection message" do
    end
  end

  def should_display_an_error_message
    specify "should display an error message" do
    end
  end

  def should_dispense_cash
    specify "should dispense cash" do
    end
  end

  def should_not_dispense_cash
    specify "should not dispense cash" do
    end
  end

  def should_return_the_card
    specify "should return the card" do
    end
  end

  def should_not_return_the_card
    specify "should not return the card" do
    end
  end
end

context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser contains cash
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  should_debit_the_account
  should_dispense_cash
  should_return_the_card
end

context %{A Withdrawal where an Account is in credit
        AND the card is NOT valid
        AND NOT stolen
        AND the dispenser contains cash
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  should_display_a_rejection_message
  should_not_dispense_cash
  should_return_the_card
end

context %{A Withdrawal where an Account is in credit
        AND the card is NOT valid
        AND stolen
        AND the dispenser contains cash
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  should_display_a_rejection_message
  should_not_dispense_cash
  should_not_return_the_card
end

context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser DOES NOT contain cash
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  should_display_an_error_message
  should_not_dispense_cash
  should_return_the_card
end

context %{A Withdrawal where an Account is overdrawn
        AND the card is valid
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  should_display_a_rejection_message
  should_not_dispense_cash
  should_return_the_card
end

And here is the alternative source:

require "rubygems"
require "spec"

ARGV << "--format"
ARGV << "specdoc"

=begin
Title: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I don't have to wait in line at the bank.
=end

CustomerWithdrawsCashSpec = context_module do
  specify "should debit the account" do
  end

  specify "should display a rejection message" do
  end

  specify "should display an error message" do
  end

  specify "should dispense cash" do
  end

  specify "should not dispense cash" do
  end

  specify "should return the card" do
  end

  specify "should not return the card" do
  end
end

context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser contains cash
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  specify "should debit the account"
  specify "should dispense cash"
  specify "should return the card"
end

context %{A Withdrawal where an Account is in credit
        AND the card is NOT valid
        AND NOT stolen
        AND the dispenser contains cash
        AND the customer requests cash} do

  specify "should display a rejection message", CustomerWithdrawsCashSpec
  specify "should not dispense cash", CustomerWithdrawsCashSpec
  specify "should return the card", CustomerWithdrawsCashSpec
end

context %{A Withdrawal where an Account is in credit
        AND the card is NOT valid
        AND stolen
        AND the dispenser contains cash
        AND the customer requests cash} do

  extend customer_withdraws_cash
  specify "should display a rejection message"
  specify "should not dispense cash"
  specify "should not return the card"
end

context %{A Withdrawal where an Account is in credit
        AND the card is valid
        AND the dispenser DOES NOT contain cash
        AND the customer requests cash} do

  specify "should display an error message", customer_withdraws_cash
  specify "should not dispense cash", customer_withdraws_cash
  specify "should return the card", customer_withdraws_cash
end

context %{A Withdrawal where an Account is overdrawn
        AND the card is valid
        AND the customer requests cash} do

  extend CustomerWithdrawsCashSpec
  should_display_a_rejection_message
  should_not_dispense_cash
  should_return_the_card
end



Thanks Brian.
>
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061121/199e7d57/attachment.html 

From dchelimsky at gmail.com  Wed Nov 22 05:53:22 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 22 Nov 2006 04:53:22 -0600
Subject: [rspec-users] Controller Isolation
In-Reply-To: <cbbc1640611211642l6d566e50yd54c7172f7e6f8e3@mail.gmail.com>
References: <cbbc1640611211642l6d566e50yd54c7172f7e6f8e3@mail.gmail.com>
Message-ID: <57c63afe0611220253m362d07afh7d652d9c0367792d@mail.gmail.com>

On 11/21/06, Dylan Egan <dylanegan at gmail.com> wrote:
> Hi,
>
> I have a project that I had running under rspec 0.6.x and recently upgraded
> to 0.7.2.
>
> I am trying to isolate my controllers from the database as I go through and
> change all the specs to run under 0.7.2.
>
> I am having a problem where I need to make the create! method return the
> mocked object as well as raise RecordInvalid exception. Is this at all
> possible?

AFAIK, Ruby won't let you return an object and raise an error at the
same time. You get one or the other.

> I use the rescue statement in my controller methods and not @
> object.new_record? or @object.valid? to check whether to redirect or render.
>
> -- controller --
>
>   def create
>     @star = Star.create!(params[:star])
>     redirect_to star_path(@star)
>   rescue ActiveRecord::RecordInvalid
>     render :action => 'new'
>   end
>
> -- spec --
>   @star = mock('star')
>   Star.should_receive(:create!).with({ 'name' => nil }).and_return(@star)

Hmmm. As I said above, I can't imagine that Ruby will let you do that.
What I would do in this case is this:

-- spec --
  @star = mock('star')
  Star.should_receive(:create!).with({ 'name' => nil
}).and_raise(ActiveRecord::RecordInvalid)
  Star.should_receive(:create).with({ 'name' => nil }).and_return(@star)

-- controller --

  def create
    @star = Star.create!(params[:star])
    redirect_to star_path(@star)
  rescue ActiveRecord::RecordInvalid
    @star = Star.create(params[:star])
    render :action => 'new'
  end

OR

  def create
    @star = Star.create!(params[:star])
    redirect_to star_path(@star)
  rescue ActiveRecord::RecordInvalid
    render :action => 'new'
  end

  def new
    @star = Star.new
  end

> I'm new to all the mocking/stubbing business so my head spins are turning
> into headaches. :)

Hope that helps.

David

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

From brian.takita at gmail.com  Wed Nov 22 05:19:28 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 22 Nov 2006 02:19:28 -0800
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <8d961d900611211546o2060fc5cgee9d8990755b1a8f@mail.gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
	<8d961d900611211546o2060fc5cgee9d8990755b1a8f@mail.gmail.com>
Message-ID: <1d7ddd110611220219mfa0d989ga7ce484b219d7119@mail.gmail.com>

On 11/21/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
> On 11/21/06, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > I'm scheduled to give a rspec brown bag this Wednesday (11/22) for my
> > company (Pivotal Computer Systems, http://www.pivotalsf.com). I did see
> Dave
> > Astel's talk as well as several of my coworkers.
> > The developers at my workplace are experienced Agile developers.
> >
> > What would be some good things to focus on for this brown bag?
> > Are there slides to presentations that would be useful?
> > Any resistance/skepticism, and how to best address these concerns?
> >
>
> I have had success with an explanation of the TDD journey as described
> here:
> http://www.behaviour-driven.org/TDDAdoptionProfile
>
> I usually present it with takahashi-style slides
> (http://tinyurl.com/o6psh) with the following words (one on each
> slide):
> * tests
> * confidence
> * before
> * documentation
> * discovery
> * behaviour
> * mocking


This looks good. I think I'll start with this and then move to the demo.
Dan North's ATM example is a juicy example for using rspec to drive domain
concepts. The specdocs will come in handy here.
Then I'll do a short rspec on rails demo showing the model, control, view,
and helper specs.

Which should leave plenty of time for discussion and further examples. I'll
also invite discussion during the "presentation".

Everyone, thanks for your help.

Brian

> I'm kindof nervous because there is some skepticism toward rspec and BDD.
> >
> > Mainly:
> >
> > Test::Unit already does that, so why do we need rspec?
> > It's not production ready. (Stack traces are too cluttered for
> RspecOnRails;
> > although this opinion was based on version 0.6)
> > New people will be confused seeing rspec code (although this is solved
> by
> > more education, usage, encapsulation, etc.)
> > BDD is TDD using "should" instead of "assert"
> > There are also a number of people who do see benefits to using rspec and
> are
> > excited by it, so I do have "allies". :)
> >
> > I'm particularly interested in showing:
> >
> > How BDD is really good TDD without sounding religious
> > How rspec encourages developers to create better "tests" than
> > Test::UnitThank you,
> > Brian Takita
> >
> > _______________________________________________
> > rspec-devel mailing list
> > rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061122/0bdc0d0b/attachment.html 

From jchris at mfdz.com  Wed Nov 22 14:56:05 2006
From: jchris at mfdz.com (Chris Anderson)
Date: Wed, 22 Nov 2006 11:56:05 -0800
Subject: [rspec-users] Controller Isolation
In-Reply-To: <57c63afe0611220253m362d07afh7d652d9c0367792d@mail.gmail.com>
References: <cbbc1640611211642l6d566e50yd54c7172f7e6f8e3@mail.gmail.com>
	<57c63afe0611220253m362d07afh7d652d9c0367792d@mail.gmail.com>
Message-ID: <e282921e0611221156m3c19349dle5112611b91be1b2@mail.gmail.com>

As far as your controller action goes, you might try switching from
the exception handling way of rendering different actions to using
something like:

def create
    @star = Star.new(params[:star])
    if @star.save
      redirect_to star_path(@star)
    else
      render :action => 'new'
end

This keeps your @star object available even when it is invalid, which
gives you the ability to use "error_messages_for 'star'" in your
new.rhtml. It should also make specing easier. I basically cribbed it
from scaffold_resource, so it's also the core-team blessed way.

I used to use the exception handling method, but because @star.save
returns false on failure, there's no reason to have other checks. It
also gives you the ability to do more stuff to @star after it's been
initialized but before it has to be valid. Now I'm fully a convert to
the @star.save conditional structure.

Hope this helps.

Chris


On 11/22/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 11/21/06, Dylan Egan <dylanegan at gmail.com> wrote:
> > Hi,
> >
> > I have a project that I had running under rspec 0.6.x and recently upgraded
> > to 0.7.2.
> >
> > I am trying to isolate my controllers from the database as I go through and
> > change all the specs to run under 0.7.2.
> >
> > I am having a problem where I need to make the create! method return the
> > mocked object as well as raise RecordInvalid exception. Is this at all
> > possible?
>
> AFAIK, Ruby won't let you return an object and raise an error at the
> same time. You get one or the other.
>
> > I use the rescue statement in my controller methods and not @
> > object.new_record? or @object.valid? to check whether to redirect or render.
> >
> > -- controller --
> >
> >   def create
> >     @star = Star.create!(params[:star])
> >     redirect_to star_path(@star)
> >   rescue ActiveRecord::RecordInvalid
> >     render :action => 'new'
> >   end
> >
> > -- spec --
> >   @star = mock('star')
> >   Star.should_receive(:create!).with({ 'name' => nil }).and_return(@star)
>
> Hmmm. As I said above, I can't imagine that Ruby will let you do that.
> What I would do in this case is this:
>
> -- spec --
>   @star = mock('star')
>   Star.should_receive(:create!).with({ 'name' => nil
> }).and_raise(ActiveRecord::RecordInvalid)
>   Star.should_receive(:create).with({ 'name' => nil }).and_return(@star)
>
> -- controller --
>
>   def create
>     @star = Star.create!(params[:star])
>     redirect_to star_path(@star)
>   rescue ActiveRecord::RecordInvalid
>     @star = Star.create(params[:star])
>     render :action => 'new'
>   end
>
> OR
>
>   def create
>     @star = Star.create!(params[:star])
>     redirect_to star_path(@star)
>   rescue ActiveRecord::RecordInvalid
>     render :action => 'new'
>   end
>
>   def new
>     @star = Star.new
>   end
>
> > I'm new to all the mocking/stubbing business so my head spins are turning
> > into headaches. :)
>
> Hope that helps.
>
> David
>
> > Dylan.
> >
> > _______________________________________________
> > 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
>


-- 
Chris Anderson
http://jchris.mfdz.com

From keith at dancingtext.com  Wed Nov 22 17:04:58 2006
From: keith at dancingtext.com (Keith McDonnell)
Date: Wed, 22 Nov 2006 22:04:58 +0000
Subject: [rspec-users] rspec_on_rails (MissingSourceFile)
Message-ID: <4564C98A.7010503@dancingtext.com>

Hi there,

I've installed rspec, rails plugin & generators thusly:

$ sudo gem install rspec
$ sudo gem install rspec_generator
$ sudo gem install zentest -v 3.4.1
$ ./script/plugin install 
svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec 


$ ./script/generate rspec
$ ./script/generate rspec_model ModelName

With Rails version:

$ rails --version
Rails 1.1.6

However, when I try to run the specs ...

$ rake spec:models

/usr/local/bin/ruby 
-I"/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib" 
"/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec" 
"spec/models/daily_scrum_spec.rb" "spec/models/progress_report_spec.rb"
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`gem_original_require': no such file to load -- 
./spec/models/../../vendor/generators/rspec/lib/rspec_on_rails 
(MissingSourceFile)
        from 
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`require'
        from 
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in 
`require'
        from ./spec/models/../spec_helper.rb:3
        from ./spec/models/daily_scrum_spec.rb:1
        from 
/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in 
`run'
        from 
/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in 
`run'
        from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4
rake aborted!
Command failed with status (1): [/usr/local/bin/ruby 
-I"/usr/local/lib/ruby...]


This file seems to be missing:

${RAILS_DEV_DIR}/spec/models/../../vendor/generators/rspec/lib/rspec_on_rails 
(MissingSourceFile)

Here's my vendor/generators dir :

vendor/generators
|-- rspec_controller
|   |-- USAGE
|   |-- rspec_controller_generator.rb
|   `-- templates
|       `-- controller_spec.rb
`-- rspec_model
    |-- USAGE
    |-- rspec_model_generator.rb
    `-- templates
        `-- model_spec.rb

No rspec/lib/rspec_on_rails in there???

There is a vendor/plugins/rspec/lib/rspec_on_rails.rb file however.

I'm stumped. Any ideas ?

Keith




From dylanegan at gmail.com  Wed Nov 22 17:48:41 2006
From: dylanegan at gmail.com (Dylan Egan)
Date: Thu, 23 Nov 2006 09:48:41 +1100
Subject: [rspec-users] Controller Isolation
In-Reply-To: <e282921e0611221156m3c19349dle5112611b91be1b2@mail.gmail.com>
References: <cbbc1640611211642l6d566e50yd54c7172f7e6f8e3@mail.gmail.com>
	<57c63afe0611220253m362d07afh7d652d9c0367792d@mail.gmail.com>
	<e282921e0611221156m3c19349dle5112611b91be1b2@mail.gmail.com>
Message-ID: <cbbc1640611221448y67faeabbu2f9c43f9577b1f84@mail.gmail.com>

Heya,

Yeah I might just have to revert back to the way I used to do it. I liked
the rescue way because it was a much tidier presentation.

Also I have the new/create methods, just like anyone using REST and the
.and_raise bit didn't work.

Or I could just use the DB on these cases. Choices choices.

Thanks anyways.

Dylan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061123/187606ab/attachment.html 

From aslak.hellesoy at gmail.com  Wed Nov 22 18:06:03 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 23 Nov 2006 00:06:03 +0100
Subject: [rspec-users] rspec_on_rails (MissingSourceFile)
In-Reply-To: <4564C98A.7010503@dancingtext.com>
References: <4564C98A.7010503@dancingtext.com>
Message-ID: <8d961d900611221506r6d78b86ga9290c2e8bdc6ab7@mail.gmail.com>

On 11/22/06, Keith McDonnell <keith at dancingtext.com> wrote:
> Hi there,
>
> I've installed rspec, rails plugin & generators thusly:
>
> $ sudo gem install rspec
> $ sudo gem install rspec_generator
> $ sudo gem install zentest -v 3.4.1
> $ ./script/plugin install
> svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec
>

I believe this is fixed on trunk. Could you try this instead?:

(somewhere outside your rails app)
svn co svn://rubyforge.org/var/svn/rspec/trunk rspec
cd rspec
rake gem
sudo gem install pkg/rspec-0.7.3.gem

And then install the trunk/HEAD rspec plugin in your rails app:
./script/plugin install
svn://rubyforge.org/var/svn/rspec/trunkvendor/rspec_on_rails/vendor/plugins/rspec

If the problem still persists, please file a bug at the RubyForge tracker.

HTH,
Aslak

>
> $ ./script/generate rspec
> $ ./script/generate rspec_model ModelName
>
> With Rails version:
>
> $ rails --version
> Rails 1.1.6
>
> However, when I try to run the specs ...
>
> $ rake spec:models
>
> /usr/local/bin/ruby
> -I"/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib"
> "/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec"
> "spec/models/daily_scrum_spec.rb" "spec/models/progress_report_spec.rb"
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `gem_original_require': no such file to load --
> ./spec/models/../../vendor/generators/rspec/lib/rspec_on_rails
> (MissingSourceFile)
>         from
> /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
> `require'
>         from
> /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in
> `require'
>         from ./spec/models/../spec_helper.rb:3
>         from ./spec/models/daily_scrum_spec.rb:1
>         from
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in
> `run'
>         from
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in
> `run'
>         from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4
> rake aborted!
> Command failed with status (1): [/usr/local/bin/ruby
> -I"/usr/local/lib/ruby...]
>
>
> This file seems to be missing:
>
> ${RAILS_DEV_DIR}/spec/models/../../vendor/generators/rspec/lib/rspec_on_rails
> (MissingSourceFile)
>
> Here's my vendor/generators dir :
>
> vendor/generators
> |-- rspec_controller
> |   |-- USAGE
> |   |-- rspec_controller_generator.rb
> |   `-- templates
> |       `-- controller_spec.rb
> `-- rspec_model
>     |-- USAGE
>     |-- rspec_model_generator.rb
>     `-- templates
>         `-- model_spec.rb
>
> No rspec/lib/rspec_on_rails in there???
>
> There is a vendor/plugins/rspec/lib/rspec_on_rails.rb file however.
>
> I'm stumped. Any ideas ?
>
> Keith
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From keith.mcdonnell at redbrick.dcu.ie  Wed Nov 22 16:06:29 2006
From: keith.mcdonnell at redbrick.dcu.ie (Keith McDonnell)
Date: Wed, 22 Nov 2006 21:06:29 +0000
Subject: [rspec-users] rspec_on_rails MissingSourceFile
Message-ID: <4564BBD5.4070703@redbrick.dcu.ie>

Hi there,

I've installed rspec, rails plugin & generators thusly:

$ sudo gem install rspec
$ sudo gem install rspec_generator
$ sudo gem install zentest -v 3.4.1
$ ./script/plugin install 
svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec

$ ./script/generate rspec
$ ./script/generate rspec_model ModelName

With Rails version:

$ rails --version
Rails 1.1.6

However, when I try to run the specs ...

$ rake spec:models

/usr/local/bin/ruby 
-I"/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib" 
"/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec" 
"spec/models/daily_scrum_spec.rb" "spec/models/progress_report_spec.rb"
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in 
`gem_original_require': no such file to load -- 
./spec/models/../../vendor/generators/rspec/lib/rspec_on_rails 
(MissingSourceFile)
         from 
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require'
         from 
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in 
`require'
         from ./spec/models/../spec_helper.rb:3
         from ./spec/models/daily_scrum_spec.rb:1
         from 
/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:21:in 
`run'
         from 
/usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/lib/spec/runner/command_line.rb:15:in 
`run'
         from /usr/local/lib/ruby/gems/1.8/gems/rspec-0.7.2/bin/spec:4
rake aborted!
Command failed with status (1): [/usr/local/bin/ruby 
-I"/usr/local/lib/ruby...]


This file seems to be missing:

${RAILS_DEV_DIR}/spec/models/../../vendor/generators/rspec/lib/rspec_on_rails 
(MissingSourceFile)

Here's my vendor/generators dir :

vendor/generators
|-- rspec_controller
|   |-- USAGE
|   |-- rspec_controller_generator.rb
|   `-- templates
|       `-- controller_spec.rb
`-- rspec_model
     |-- USAGE
     |-- rspec_model_generator.rb
     `-- templates
         `-- model_spec.rb

No rspec/lib/rspec_on_rails in there???

There is a vendor/plugins/rspec/lib/rspec_on_rails.rb file however.

I'm stumped. Any ideas ?

Keith



From brian.takita at gmail.com  Wed Nov 22 17:10:58 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Wed, 22 Nov 2006 14:10:58 -0800
Subject: [rspec-users] [rspec-devel] Rspec Brown Bag
In-Reply-To: <57c63afe0611210500g110561cbk7f4da9a687b2014b@mail.gmail.com>
References: <1d7ddd110611201807h797a2efawe44448f307685227@mail.gmail.com>
	<57c63afe0611202129v74b14feancd9aefaa7bc33b38@mail.gmail.com>
	<1d7ddd110611202238y77c6af08j71b27cf9150b2ba@mail.gmail.com>
	<57c63afe0611210500g110561cbk7f4da9a687b2014b@mail.gmail.com>
Message-ID: <1d7ddd110611221410ta147eb9u89ffa2f086294640@mail.gmail.com>

On 11/21/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 11/21/06, Brian Takita <brian.takita at gmail.com> wrote:
> > Also, my coworker, Benny Sadeh advised me to treat the Brown Bag as a
> > discussion and exploration of what can be learned from BDD and rspec.
>
> Yes, yes, yes, yes! That is fantastic advice.
>
> Please report back to let us know how it all went. Good and/or bad.


Aiee. It got postponed to next Wednesday.

Good luck!
> David
> _______________________________________________
> rspec-devel mailing list
> rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061122/089fad00/attachment-0001.html 

From lourens at rentacarhire.com  Thu Nov 23 18:55:26 2006
From: lourens at rentacarhire.com (Lourens Naude)
Date: Thu, 23 Nov 2006 23:55:26 +0000
Subject: [rspec-users] Some tips for testing respond_to block and making
	controller tests work with simply_helpful
Message-ID: <EB8C9237-3314-4992-AA0B-905DC9E820D8@rentacarhire.com>

Hi,

Here's two blog posts for those that need to test respond_to blocks  
and/or are currently using simply_helpful extensively.

http://blog.methodmissing.com/2006/11/22/testing-different-content- 
types-with-rspec
http://blog.methodmissing.com/2006/11/23/using-simply_helpful-with- 
rspec-controller-tests

- Lourens

From dchelimsky at gmail.com  Fri Nov 24 01:12:15 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 24 Nov 2006 00:12:15 -0600
Subject: [rspec-users] Some tips for testing respond_to block and making
	controller tests work with simply_helpful
In-Reply-To: <EB8C9237-3314-4992-AA0B-905DC9E820D8@rentacarhire.com>
References: <EB8C9237-3314-4992-AA0B-905DC9E820D8@rentacarhire.com>
Message-ID: <57c63afe0611232212j2890a444s7b78951ae231d4fb@mail.gmail.com>

Hey Lourens,

Thanks for these blog posts!

Just an FYI - the rails plugin is a moving target right now
(especially its innards) so the monkey patching that you recommended
is all going to break in the 0.7.3 release. If you look at the trunk
you'll see that the dependency on ZenTest is gone and we're renaming
modules and classes to better align w/ the rest of RSpec.

If you're finding deficiencies in the tool we'd love to hear that
feedback in the form of feature requests and/or patches. If you're
interested, give http://rspec.rubyforge.org/contribute.html a read and
have at it.

Cheers,
David

On 11/23/06, Lourens Naude <lourens at rentacarhire.com> wrote:
> Hi,
>
> Here's two blog posts for those that need to test respond_to blocks
> and/or are currently using simply_helpful extensively.
>
> http://blog.methodmissing.com/2006/11/22/testing-different-content-
> types-with-rspec
> http://blog.methodmissing.com/2006/11/23/using-simply_helpful-with-
> rspec-controller-tests
>
> - Lourens
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From cwdinfo at gmail.com  Fri Nov 24 02:11:03 2006
From: cwdinfo at gmail.com (s.ross)
Date: Thu, 23 Nov 2006 23:11:03 -0800
Subject: [rspec-users] rSpec on Rails 1.2?
Message-ID: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>

I just updated my Rails install to the most current Edge and my  
controller specs fail:

1)
TypeError in 'The User Controller should be a user controller'
can't convert nil into String

Each spec fails the same way.

<context string> <spec string>
can't convert nil into String

Any ideas what's up with this?

Thanks,

s.ross

From marcus at marcusr.org.uk  Fri Nov 24 02:53:08 2006
From: marcus at marcusr.org.uk (Marcus Roberts)
Date: Fri, 24 Nov 2006 07:53:08 +0000
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
References: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
Message-ID: <475E9285-443C-4B95-836D-0F673059C049@marcusr.org.uk>

This blog seems to have quite a bit of information about running with  
edge Rails:

http://blog.methodmissing.com/2006/11/23/using-simply_helpful-with- 
rspec-controller-tests

which I've found useful.

I'm running rspec 0.7.3 and the trunk of the rails plugin and most of  
my controller specs pass, but I still get

undefined method `render?' for #<ActionController::TestResponse: 
0x28886c4>

errors for specs such as

specify "should render show.rhtml" do
     response.should_render :show
   end


Marcus

On 24 Nov 2006, at 07:11, s.ross wrote:

> I just updated my Rails install to the most current Edge and my
> controller specs fail:
>
> 1)
> TypeError in 'The User Controller should be a user controller'
> can't convert nil into String
>
> Each spec fails the same way.
>
> <context string> <spec string>
> can't convert nil into String
>
> Any ideas what's up with this?
>
> Thanks,
>
> s.ross
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From info at mathias-biilmann.net  Fri Nov 24 06:12:43 2006
From: info at mathias-biilmann.net (Mathias Biilmann Christensen)
Date: Fri, 24 Nov 2006 12:12:43 +0100
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
References: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
Message-ID: <396DDEAA-ED7A-4A54-94FA-D6589BD056A2@mathias-biilmann.net>

I have nearly the same problem, though for me it seems to be fixture  
related.

Every context that includes fixtures breaks with the 'can't convert  
nil into String'  TypeError.

I tried building the trunk version of RSpec and installing the head  
version of the rails plugin, but no luck.

Really shouldn't have decided to use RSpec for my attempt at a rapid  
programming contest submission!

Regards,
Mathias


On Nov 24, 2006, at 8:11 AM, s.ross wrote:

> I just updated my Rails install to the most current Edge and my
> controller specs fail:
>
> 1)
> TypeError in 'The User Controller should be a user controller'
> can't convert nil into String
>
> Each spec fails the same way.
>
> <context string> <spec string>
> can't convert nil into String
>
> Any ideas what's up with this?
>
> Thanks,
>
> s.ross
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From keith at dancingtext.com  Fri Nov 24 12:00:17 2006
From: keith at dancingtext.com (Keith McDonnell)
Date: Fri, 24 Nov 2006 17:00:17 +0000
Subject: [rspec-users] rSpec REL_0_7_2 rspec_on_rails
 (MissingSourceFile) >> Fixed in trunk
In-Reply-To: <mailman.1.1164246671.21388.rspec-users@rubyforge.org>
References: <mailman.1.1164246671.21388.rspec-users@rubyforge.org>
Message-ID: <45672521.7010105@dancingtext.com>

Hi Aslak, Thanks for the help. That bug is fixed in trunk.

Here's my path to recovery ...

$ svn co svn://rubyforge.org/var/svn/rspec/trunk ~/tmp/rspec
$ cd ~/tmp/rspec
$ rake gem
$ sudo gem install pkg/rspec-0.7.3.gem

$ ./script/plugin install --force  svn://rubyforge.org/var/svn/rspec/trunk/vendor/rspec_on_rails/vendor/plugins/rspec
$ ./script/generate rspec (required to regenerate specs)

$ rake spec:models  

<Specs running nicely>

Thanks, Keith On 11/22/06, Keith McDonnell <keith at dancingtext.com> wrote:

> > Hi there,
> >
> > I've installed rspec, rails plugin & generators thusly:
> >
> > $ sudo gem install rspec
> > $ sudo gem install rspec_generator
> > $ sudo gem install zentest -v 3.4.1
> > $ ./script/plugin install
> > svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_2/vendor/rspec_on_rails/vendor/plugins/rspec
> >
>   

I believe this is fixed on trunk. Could you try this instead?:

(somewhere outside your rails app)
svn co svn://rubyforge.org/var/svn/rspec/trunk rspec
cd rspec
rake gem
sudo gem install pkg/rspec-0.7.3.gem

And then install the trunk/HEAD rspec plugin in your rails app:
./script/plugin install
svn://rubyforge.org/var/svn/rspec/trunkvendor/rspec_on_rails/vendor/plugins/rspec

If the problem still persists, please file a bug at the RubyForge tracker.

HTH,
Aslak


> >
> > 

From cwdinfo at gmail.com  Fri Nov 24 12:51:09 2006
From: cwdinfo at gmail.com (s.ross)
Date: Fri, 24 Nov 2006 09:51:09 -0800
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <396DDEAA-ED7A-4A54-94FA-D6589BD056A2@mathias-biilmann.net>
References: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
	<396DDEAA-ED7A-4A54-94FA-D6589BD056A2@mathias-biilmann.net>
Message-ID: <357B3BC2-BF78-41EE-8A54-4BFDC52974AB@gmail.com>

The change that broke rspec_on_rails was in 5604. Here's the svn diff:

--- activerecord/lib/active_record/fixtures.rb  (revision 5603)
+++ activerecord/lib/active_record/fixtures.rb  (revision 5604)
@@ -436,7 +436,7 @@
module Test #:nodoc:
    module Unit #:nodoc:
      class TestCase #:nodoc:
-      cattr_accessor :fixture_path
+      class_inheritable_accessor :fixture_path
        class_inheritable_accessor :fixture_table_names
        class_inheritable_accessor :fixture_class_names
        class_inheritable_accessor :use_transactional_fixtures

Poking around in Rails, the nil that can't be converted to a string  
is (d'oh) fixture_path.


On Nov 24, 2006, at 3:12 AM, Mathias Biilmann Christensen wrote:

> I have nearly the same problem, though for me it seems to be fixture
> related.
>
> Every context that includes fixtures breaks with the 'can't convert
> nil into String'  TypeError.
>
> I tried building the trunk version of RSpec and installing the head
> version of the rails plugin, but no luck.
>
> Really shouldn't have decided to use RSpec for my attempt at a rapid
> programming contest submission!
>
> Regards,
> Mathias
>
>
> On Nov 24, 2006, at 8:11 AM, s.ross wrote:
>
>> I just updated my Rails install to the most current Edge and my
>> controller specs fail:
>>
>> 1)
>> TypeError in 'The User Controller should be a user controller'
>> can't convert nil into String
>>
>> Each spec fails the same way.
>>
>> <context string> <spec string>
>> can't convert nil into String
>>
>> Any ideas what's up with this?
>>
>> Thanks,
>>
>> s.ross
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From lourens at rentacarhire.com  Fri Nov 24 14:29:57 2006
From: lourens at rentacarhire.com (Lourens Naude)
Date: Fri, 24 Nov 2006 19:29:57 +0000
Subject: [rspec-users] Some tips for testing respond_to block and making
	controller tests work with simply_helpful
In-Reply-To: <57c63afe0611232212j2890a444s7b78951ae231d4fb@mail.gmail.com>
References: <EB8C9237-3314-4992-AA0B-905DC9E820D8@rentacarhire.com>
	<57c63afe0611232212j2890a444s7b78951ae231d4fb@mail.gmail.com>
Message-ID: <9997D95C-826D-46C2-A638-4E8360923983@rentacarhire.com>

David,

Yes, just hacked it up quick and posted as I needed it *yesterday*.
I'll have a look at trunk later today or tomorrow.

There's some issues with the render rspec assertions when using  
content types:

  # controller action
   def show
     respond_to do |format|
       format.html # show.rhtml
       format.xml  { render :xml => @coupon.to_xml }
     end
   end

# specs

   setup do
     rentacar_host('account')
     authorized
     get :show, {:locale => 'en', :id => 1 }, :html
   end

   specify "should render show.rhtml" do
      controller.should_have_rendered :action => 'show'   
#specification fails
   end

   specify "should render show.rhtml" do
     controller.should_have_rendered( :action =>  
"show", :content_type => Mime::HTML )  #this one passes, needs the  
explicit content type when testing actions with respond_to blocks
   end

  #It would also be nice to have  
controller_instance.should_redirect_to 'something' pickup RJS  
redirects eg. page.redirect_to target_url()  as well

   #HTML content type
   specify "should redirect back to plans" do
     controller.should_redirect_to 'http://www.rentacars.com/en/app/ 
plans'
     get :new, { :plan_id => 20, :locale => 'en'}, :html
     response.should_be_redirect
   end

  #JS content type
    setup do
     rentacar_host('account')
     authorized
     @order_before = Account.find(2).coupons.collect(&:id)
     xhr :put, :sort, { :coupons => { 0 => '1',
                                      1 => '2',
                                      2 => '4' }, :locale => 'en'}
   end

#ugly ugly hack
   specify "should redirect to coupons" do
      response.body.should_include 'http://account.rentacars.com/en/ 
admin/coupons'
      response.body.should_include 'window.location.href'
    end

This would ideally we covered by the should_redirect_to assertion and  
not the RJS specific ones.
This redirect is client side, however, and can't be picked up  
matching response code 302 ... and thus wouldn't work in isolated  
controller tests (without view integration).
I'll look into this as well.

- Lourens

On 2006/11/24, at 06:12, David Chelimsky wrote:

> Hey Lourens,
>
> Thanks for these blog posts!
>
> Just an FYI - the rails plugin is a moving target right now
> (especially its innards) so the monkey patching that you recommended
> is all going to break in the 0.7.3 release. If you look at the trunk
> you'll see that the dependency on ZenTest is gone and we're renaming
> modules and classes to better align w/ the rest of RSpec.
>
> If you're finding deficiencies in the tool we'd love to hear that
> feedback in the form of feature requests and/or patches. If you're
> interested, give http://rspec.rubyforge.org/contribute.html a read and
> have at it.
>
> Cheers,
> David
>
> On 11/23/06, Lourens Naude <lourens at rentacarhire.com> wrote:
>> Hi,
>>
>> Here's two blog posts for those that need to test respond_to blocks
>> and/or are currently using simply_helpful extensively.
>>
>> http://blog.methodmissing.com/2006/11/22/testing-different-content-
>> types-with-rspec
>> http://blog.methodmissing.com/2006/11/23/using-simply_helpful-with-
>> rspec-controller-tests
>>
>> - Lourens
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From lourens at rentacarhire.com  Fri Nov 24 14:14:43 2006
From: lourens at rentacarhire.com (Lourens Naude)
Date: Fri, 24 Nov 2006 19:14:43 +0000
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <475E9285-443C-4B95-836D-0F673059C049@marcusr.org.uk>
References: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
	<475E9285-443C-4B95-836D-0F673059C049@marcusr.org.uk>
Message-ID: <15AE7535-EDEE-45FB-A85E-ACAA9914E091@rentacarhire.com>

Hi,

I believe the response object doesn't respond to render? ... you need  
to use the controller instance as the receiver.

- Lourens

On 2006/11/24, at 07:53, Marcus Roberts wrote:

> This blog seems to have quite a bit of information about running with
> edge Rails:
>
> http://blog.methodmissing.com/2006/11/23/using-simply_helpful-with-
> rspec-controller-tests
>
> which I've found useful.
>
> I'm running rspec 0.7.3 and the trunk of the rails plugin and most of
> my controller specs pass, but I still get
>
> undefined method `render?' for #<ActionController::TestResponse:
> 0x28886c4>
>
> errors for specs such as
>
> specify "should render show.rhtml" do
>      response.should_render :show
>    end
>
>
> Marcus
>
> On 24 Nov 2006, at 07:11, s.ross wrote:
>
>> I just updated my Rails install to the most current Edge and my
>> controller specs fail:
>>
>> 1)
>> TypeError in 'The User Controller should be a user controller'
>> can't convert nil into String
>>
>> Each spec fails the same way.
>>
>> <context string> <spec string>
>> can't convert nil into String
>>
>> Any ideas what's up with this?
>>
>> Thanks,
>>
>> s.ross
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From cwdinfo at gmail.com  Fri Nov 24 17:23:34 2006
From: cwdinfo at gmail.com (s.ross)
Date: Fri, 24 Nov 2006 14:23:34 -0800
Subject: [rspec-users] Bugs Fixed in Trunk
Message-ID: <C33B020A-69C0-45BF-9C38-CECFBB1C168C@gmail.com>

I'm backed off Edge Rails and all the way back to 0.7.2 of rSpec to  
make my tests pass. The changes to rSpec are coming together fast and  
furious and they seem too good to pass up. Is there an approved way  
to upgrade the components in the absence of prebuilt stuff? Every  
time I've tried, I've been punished harshly by the Version Conflict  
Gods.

Just asking for a quick "how to build it out on osx" and "how to undo  
all of this if i hosed my system" blurb.

Thanks

s.ross

From chad at spicycode.com  Fri Nov 24 19:25:22 2006
From: chad at spicycode.com (Chad Humphries)
Date: Fri, 24 Nov 2006 19:25:22 -0500
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
References: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
Message-ID: <0A9291A8-2056-48B2-8BCF-82EAB4F7BFAC@spicycode.com>

Same here, I'm rolling back to rspec 0.7.2 to give it a go and see  
what happens.

-Chad

On Nov 24, 2006, at 2:11 AM, s.ross wrote:

> I just updated my Rails install to the most current Edge and my
> controller specs fail:
>
> 1)
> TypeError in 'The User Controller should be a user controller'
> can't convert nil into String
>
> Each spec fails the same way.
>
> <context string> <spec string>
> can't convert nil into String
>
> Any ideas what's up with this?
>
> Thanks,
>
> s.ross
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From chad at spicycode.com  Fri Nov 24 20:12:43 2006
From: chad at spicycode.com (Chad Humphries)
Date: Fri, 24 Nov 2006 20:12:43 -0500
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
References: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
Message-ID: <F6472A0B-F5EA-4C16-834B-2A6D2E25404D@spicycode.com>

I found the cause, it looks like this revision of edge rails  
introduced the error we are seeing in rspec.   http:// 
dev.rubyonrails.org/changeset/5604

-Chad

On Nov 24, 2006, at 2:11 AM, s.ross wrote:

> I just updated my Rails install to the most current Edge and my
> controller specs fail:
>
> 1)
> TypeError in 'The User Controller should be a user controller'
> can't convert nil into String
>
> Each spec fails the same way.
>
> <context string> <spec string>
> can't convert nil into String
>
> Any ideas what's up with this?
>
> Thanks,
>
> s.ross
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From chad at spicycode.com  Fri Nov 24 20:23:12 2006
From: chad at spicycode.com (Chad Humphries)
Date: Fri, 24 Nov 2006 20:23:12 -0500
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <396DDEAA-ED7A-4A54-94FA-D6589BD056A2@mathias-biilmann.net>
References: <CD755398-3FB3-4A14-9D7A-837AE1BC236C@gmail.com>
	<396DDEAA-ED7A-4A54-94FA-D6589BD056A2@mathias-biilmann.net>
Message-ID: <E953DAD7-F8FD-48F4-A3A4-FEE9BC1270C7@spicycode.com>

Followup:

Adding the following to your tests that encounter the problem seems  
to fix them

   self.fixture_path = RAILS_ROOT + '/spec/fixtures'

Discovered on the related rails ticket:
http://dev.rubyonrails.org/ticket/6672

-Chad

On Nov 24, 2006, at 6:12 AM, Mathias Biilmann Christensen wrote:

> I have nearly the same problem, though for me it seems to be fixture
> related.
>
> Every context that includes fixtures breaks with the 'can't convert
> nil into String'  TypeError.
>
> I tried building the trunk version of RSpec and installing the head
> version of the rails plugin, but no luck.
>
> Really shouldn't have decided to use RSpec for my attempt at a rapid
> programming contest submission!
>
> Regards,
> Mathias
>
>
> On Nov 24, 2006, at 8:11 AM, s.ross wrote:
>
>> I just updated my Rails install to the most current Edge and my
>> controller specs fail:
>>
>> 1)
>> TypeError in 'The User Controller should be a user controller'
>> can't convert nil into String
>>
>> Each spec fails the same way.
>>
>> <context string> <spec string>
>> can't convert nil into String
>>
>> Any ideas what's up with this?
>>
>> Thanks,
>>
>> s.ross
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From dchelimsky at gmail.com  Fri Nov 24 20:25:17 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 24 Nov 2006 19:25:17 -0600
Subject: [rspec-users] [ANN] RSpec 0.7.3
Message-ID: <57c63afe0611241725s175f1252pa9f9daa9fcac885@mail.gmail.com>

Hi all,

I just released RSpec 0.7.3. It's got a few bug fixes and the rails
plugin *should* run against both Rails 1.1.6 and 1.2.0-RC1.

If you run into problems, please report bugs and feature requests in
the tracker at rubyforge:

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

Cheers,
David

From petrilli at gmail.com  Fri Nov 24 21:40:37 2006
From: petrilli at gmail.com (Christopher Petrilli)
Date: Fri, 24 Nov 2006 21:40:37 -0500
Subject: [rspec-users] Comparison between RSpec and test/unit
Message-ID: <59d991c40611241840v62d9787cwf086e6c12ad7ebbe@mail.gmail.com>

I'm curious, Christian Neukirchen has released test/unit[1] that seems
to mirror much of RSpec, but built on Test::Unit, so in some ways less
brittle from a Rails-integration perspective, and also allowing you to
mix the two together as appropriate.

So, has anyone made an informed comparison? I'm new enough that I
don't really know the finer points yet. The syntax is slightly
different, but that seems like a minor issue

Chris

[1]  http://rubyurl.com/6uT

-- 
| Christopher Petrilli
| petrilli at gmail.com

From court3nay at gmail.com  Fri Nov 24 23:02:01 2006
From: court3nay at gmail.com (Courtenay)
Date: Fri, 24 Nov 2006 20:02:01 -0800
Subject: [rspec-users] rSpec on Rails 1.2?
Message-ID: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>

Add this line to spec_helper.rb so your testcase subclasses inherit
the parent's fixture path and it restores the 'old' way of rails'
fixtures.

module Spec
  module Rails
    class EvalContext < Test::Unit::TestCase
      self.use_transactional_fixtures = true
      self.use_instantiated_fixtures  = false
      self.fixture_path = RAILS_ROOT + '/spec/fixtures'
+    cattr_accessor :fixture_path
      ...
    end
  end
end

>I found the cause, it looks like this revision of edge rails
>introduced the error we are seeing in rspec.   http://
>dev.rubyonrails.org/changeset/5604
>
>-Chad
>
>On Nov 24, 2006, at 2:11 AM, s.ross wrote:
>
>> I just updated my Rails install to the most current Edge and my
>> controller specs fail:
>>
>> 1)
>> TypeError in 'The User Controller should be a user controller'
>> can't convert nil into String
>>
>> Each spec fails the same way.
>>
>> <context string> <spec string>
>> can't convert nil into String
>>
>> Any ideas what's up with this?
>>
>> Thanks,
>>
>> s.ross

From cwdinfo at gmail.com  Fri Nov 24 23:12:37 2006
From: cwdinfo at gmail.com (s.ross)
Date: Fri, 24 Nov 2006 20:12:37 -0800
Subject: [rspec-users] [ANN] RSpec 0.7.3
In-Reply-To: <57c63afe0611241725s175f1252pa9f9daa9fcac885@mail.gmail.com>
References: <57c63afe0611241725s175f1252pa9f9daa9fcac885@mail.gmail.com>
Message-ID: <4977127E-BD3D-437A-9D20-2E232F5FC9E3@gmail.com>

Running with a fresh install of rSpec 0.7.3 and fresh install of edge  
rails, I still have the problem with "can't convert nil into a  
string." The problem seems to be that when you get to load_fixtures (/ 
vendor/rails/activerecord/lib/active_record/fixtures.rb [580]),  
fixture_path is nil. I see where it is explicitly being set in  
spec_helper.rb (note to all, if you upgrade to 0.7.3, you will have  
to create a new spec_helper.rb and migrate any customizations), but  
that is apparently being overridden somewhere later in the chain.

Any thoughts how best to get this working?

Thanks,

s.ross


On Nov 24, 2006, at 5:25 PM, David Chelimsky wrote:

> Hi all,
>
> I just released RSpec 0.7.3. It's got a few bug fixes and the rails
> plugin *should* run against both Rails 1.1.6 and 1.2.0-RC1.
>
> If you run into problems, please report bugs and feature requests in
> the tracker at rubyforge:
>
> http://rubyforge.org/tracker/?group_id=797
>
> Cheers,
> David
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From chad at spicycode.com  Fri Nov 24 23:19:04 2006
From: chad at spicycode.com (Chad Humphries)
Date: Fri, 24 Nov 2006 23:19:04 -0500
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>
References: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>
Message-ID: <D8FA8447-3E0A-48F5-83BD-9B3AA6C30A29@spicycode.com>

Weird, my messages to the list must be taking forever to show up, or  
not showing up for me?    I sent a msg a few hours ago about it but I  
never saw it show up.

I like your solution better than the one I came up with, thanks!

-Chad

On Nov 24, 2006, at 11:02 PM, Courtenay wrote:

> Add this line to spec_helper.rb so your testcase subclasses inherit
> the parent's fixture path and it restores the 'old' way of rails'
> fixtures.
>
> module Spec
>   module Rails
>     class EvalContext < Test::Unit::TestCase
>       self.use_transactional_fixtures = true
>       self.use_instantiated_fixtures  = false
>       self.fixture_path = RAILS_ROOT + '/spec/fixtures'
> +    cattr_accessor :fixture_path
>       ...
>     end
>   end
> end
>
>> I found the cause, it looks like this revision of edge rails
>> introduced the error we are seeing in rspec.   http://
>> dev.rubyonrails.org/changeset/5604
>>
>> -Chad
>>
>> On Nov 24, 2006, at 2:11 AM, s.ross wrote:
>>
>>> I just updated my Rails install to the most current Edge and my
>>> controller specs fail:
>>>
>>> 1)
>>> TypeError in 'The User Controller should be a user controller'
>>> can't convert nil into String
>>>
>>> Each spec fails the same way.
>>>
>>> <context string> <spec string>
>>> can't convert nil into String
>>>
>>> Any ideas what's up with this?
>>>
>>> Thanks,
>>>
>>> s.ross
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From cwdinfo at gmail.com  Fri Nov 24 23:19:11 2006
From: cwdinfo at gmail.com (s.ross)
Date: Fri, 24 Nov 2006 20:19:11 -0800
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>
References: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>
Message-ID: <4ECF6FE2-8DE9-4974-BE04-94A21C4BB3D5@gmail.com>

No, that doesn't fix it. fixture_path is still nil in load_fixtures.  
Note also that use_transactional_fixtures is false when it shouldn't  
be. The settings aren't getting pushed down into AR.

s.ross

On Nov 24, 2006, at 8:02 PM, Courtenay wrote:

> Add this line to spec_helper.rb so your testcase subclasses inherit
> the parent's fixture path and it restores the 'old' way of rails'
> fixtures.
>
> module Spec
>   module Rails
>     class EvalContext < Test::Unit::TestCase
>       self.use_transactional_fixtures = true
>       self.use_instantiated_fixtures  = false
>       self.fixture_path = RAILS_ROOT + '/spec/fixtures'
> +    cattr_accessor :fixture_path
>       ...
>     end
>   end
> end
>
>> I found the cause, it looks like this revision of edge rails
>> introduced the error we are seeing in rspec.   http://
>> dev.rubyonrails.org/changeset/5604
>>
>> -Chad
>>
>> On Nov 24, 2006, at 2:11 AM, s.ross wrote:
>>
>>> I just updated my Rails install to the most current Edge and my
>>> controller specs fail:
>>>
>>> 1)
>>> TypeError in 'The User Controller should be a user controller'
>>> can't convert nil into String
>>>
>>> Each spec fails the same way.
>>>
>>> <context string> <spec string>
>>> can't convert nil into String
>>>
>>> Any ideas what's up with this?
>>>
>>> Thanks,
>>>
>>> s.ross
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From cwdinfo at gmail.com  Fri Nov 24 23:31:10 2006
From: cwdinfo at gmail.com (s.ross)
Date: Fri, 24 Nov 2006 20:31:10 -0800
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>
References: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>
Message-ID: <787A1A5E-42F8-4071-94DA-B9E8CB826799@gmail.com>

Here's code I hacked up in my spec_helper.rb that works. Order of the  
statement is important: The cattr_accessor's must precede the  
assignments. (big sigh of relief :)

module Spec
   module Rails
     class EvalContext < Test::Unit::TestCase
         cattr_accessor :fixture_path
         + cattr_accessor :use_transactional_fixtures
         + cattr_accessor :use_instantiated_fixtures
         self.use_transactional_fixtures = true
         self.use_instantiated_fixtures  = false
         self.fixture_path = RAILS_ROOT + '/spec/fixtures'
        ...
     end
   end
end

On Nov 24, 2006, at 8:02 PM, Courtenay wrote:

> Add this line to spec_helper.rb so your testcase subclasses inherit
> the parent's fixture path and it restores the 'old' way of rails'
> fixtures.
>
> module Spec
>   module Rails
>     class EvalContext < Test::Unit::TestCase
>       self.use_transactional_fixtures = true
>       self.use_instantiated_fixtures  = false
>       self.fixture_path = RAILS_ROOT + '/spec/fixtures'
> +    cattr_accessor :fixture_path
>       ...
>     end
>   end
> end
>
>> I found the cause, it looks like this revision of edge rails
>> introduced the error we are seeing in rspec.   http://
>> dev.rubyonrails.org/changeset/5604
>>
>> -Chad
>>
>> On Nov 24, 2006, at 2:11 AM, s.ross wrote:
>>
>>> I just updated my Rails install to the most current Edge and my
>>> controller specs fail:
>>>
>>> 1)
>>> TypeError in 'The User Controller should be a user controller'
>>> can't convert nil into String
>>>
>>> Each spec fails the same way.
>>>
>>> <context string> <spec string>
>>> can't convert nil into String
>>>
>>> Any ideas what's up with this?
>>>
>>> Thanks,
>>>
>>> s.ross
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From court3nay at gmail.com  Sat Nov 25 00:48:33 2006
From: court3nay at gmail.com (Courtenay)
Date: Fri, 24 Nov 2006 21:48:33 -0800
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <4ECF6FE2-8DE9-4974-BE04-94A21C4BB3D5@gmail.com>
References: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>
	<4ECF6FE2-8DE9-4974-BE04-94A21C4BB3D5@gmail.com>
Message-ID: <4b430c8f0611242148l48f32df5p77ea4f0fe9a6610f@mail.gmail.com>

No, seriously.  I mis-pasted, move the cattr_accessor up a line to
before the setter line

      cattr_accessor :fixture_path
      self.fixture_path = RAILS_ROOT + '/spec/fixtures'

I just tested again, it works a charm here.  If the cattr_accessor
line is below the fixture path it fails.

However, the fact that the test::unit stuff like transactions isn't
propagating is an indication of a deeper problem, wherein the
inherited accessors are failing.

On 11/24/06, s.ross <cwdinfo at gmail.com> wrote:
> No, that doesn't fix it. fixture_path is still nil in load_fixtures.
> Note also that use_transactional_fixtures is false when it shouldn't
> be. The settings aren't getting pushed down into AR.
>
> s.ross
>
> On Nov 24, 2006, at 8:02 PM, Courtenay wrote:
>
> > Add this line to spec_helper.rb so your testcase subclasses inherit
> > the parent's fixture path and it restores the 'old' way of rails'
> > fixtures.
> >
> > module Spec
> >   module Rails
> >     class EvalContext < Test::Unit::TestCase
> >       self.use_transactional_fixtures = true
> >       self.use_instantiated_fixtures  = false
> >       self.fixture_path = RAILS_ROOT + '/spec/fixtures'
> > +    cattr_accessor :fixture_path
> >       ...
> >     end
> >   end
> > end
> >
> >> I found the cause, it looks like this revision of edge rails
> >> introduced the error we are seeing in rspec.   http://
> >> dev.rubyonrails.org/changeset/5604
> >>
> >> -Chad
> >>
> >> On Nov 24, 2006, at 2:11 AM, s.ross wrote:
> >>
> >>> I just updated my Rails install to the most current Edge and my
> >>> controller specs fail:
> >>>
> >>> 1)
> >>> TypeError in 'The User Controller should be a user controller'
> >>> can't convert nil into String
> >>>
> >>> Each spec fails the same way.
> >>>
> >>> <context string> <spec string>
> >>> can't convert nil into String
> >>>
> >>> Any ideas what's up with this?
> >>>
> >>> Thanks,
> >>>
> >>> s.ross
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Sat Nov 25 01:03:56 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 25 Nov 2006 00:03:56 -0600
Subject: [rspec-users] [ANN] RSpec 0.7.3
In-Reply-To: <4977127E-BD3D-437A-9D20-2E232F5FC9E3@gmail.com>
References: <57c63afe0611241725s175f1252pa9f9daa9fcac885@mail.gmail.com>
	<4977127E-BD3D-437A-9D20-2E232F5FC9E3@gmail.com>
Message-ID: <57c63afe0611242203u591a7467l5a28a90d428f4600@mail.gmail.com>

I'm not sure what the problem is here. I'm able to run the specs in
the sample app (which includes a database and fixtures) against 1.1.6,
1.2.0 and edge (as of 5623).

I'm running on a mac w/ ruby 1.8.4. You?

On 11/24/06, s.ross <cwdinfo at gmail.com> wrote:
> Running with a fresh install of rSpec 0.7.3 and fresh install of edge
> rails, I still have the problem with "can't convert nil into a
> string." The problem seems to be that when you get to load_fixtures (/
> vendor/rails/activerecord/lib/active_record/fixtures.rb [580]),
> fixture_path is nil. I see where it is explicitly being set in
> spec_helper.rb (note to all, if you upgrade to 0.7.3, you will have
> to create a new spec_helper.rb and migrate any customizations), but
> that is apparently being overridden somewhere later in the chain.
>
> Any thoughts how best to get this working?
>
> Thanks,
>
> s.ross
>
>
> On Nov 24, 2006, at 5:25 PM, David Chelimsky wrote:
>
> > Hi all,
> >
> > I just released RSpec 0.7.3. It's got a few bug fixes and the rails
> > plugin *should* run against both Rails 1.1.6 and 1.2.0-RC1.
> >
> > If you run into problems, please report bugs and feature requests in
> > the tracker at rubyforge:
> >
> > http://rubyforge.org/tracker/?group_id=797
> >
> > Cheers,
> > David
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From jchris at mfdz.com  Sat Nov 25 08:58:54 2006
From: jchris at mfdz.com (Chris Anderson)
Date: Sat, 25 Nov 2006 05:58:54 -0800
Subject: [rspec-users] Comparison between RSpec and test/unit
In-Reply-To: <59d991c40611241840v62d9787cwf086e6c12ad7ebbe@mail.gmail.com>
References: <59d991c40611241840v62d9787cwf086e6c12ad7ebbe@mail.gmail.com>
Message-ID: <e282921e0611250558w62a6e226y55d4b3a6934893e@mail.gmail.com>

Here's the relevant URL (if rubyurl is down for you too)

http://chneukirchen.org/blog/archive/2006/10/announcing-test-spec-0-2-a-bdd-interface-for-test-unit.html

I'm not sure what to make of it, either, so perhaps I'll just second
the question.

On 11/24/06, Christopher Petrilli <petrilli at gmail.com> wrote:
> I'm curious, Christian Neukirchen has released test/unit[1] that seems
> to mirror much of RSpec, but built on Test::Unit, so in some ways less
> brittle from a Rails-integration perspective, and also allowing you to
> mix the two together as appropriate.
>
> So, has anyone made an informed comparison? I'm new enough that I
> don't really know the finer points yet. The syntax is slightly
> different, but that seems like a minor issue
>
> Chris
>
> [1]  http://rubyurl.com/6uT
>
> --
> | Christopher Petrilli
> | petrilli at gmail.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Chris Anderson
http://jchris.mfdz.com

From aslak.hellesoy at gmail.com  Sat Nov 25 09:43:26 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 25 Nov 2006 15:43:26 +0100
Subject: [rspec-users] Bugs Fixed in Trunk
In-Reply-To: <C33B020A-69C0-45BF-9C38-CECFBB1C168C@gmail.com>
References: <C33B020A-69C0-45BF-9C38-CECFBB1C168C@gmail.com>
Message-ID: <8d961d900611250643h4ddaa5aaobedc2c2f2f248930@mail.gmail.com>

On 11/24/06, s.ross <cwdinfo at gmail.com> wrote:
> I'm backed off Edge Rails and all the way back to 0.7.2 of rSpec to
> make my tests pass. The changes to rSpec are coming together fast and
> furious and they seem too good to pass up. Is there an approved way
> to upgrade the components in the absence of prebuilt stuff? Every

Components?

> time I've tried, I've been punished harshly by the Version Conflict
> Gods.
>
> Just asking for a quick "how to build it out on osx" and "how to undo
> all of this if i hosed my system" blurb.
>

If by "it" you mean the RSpec gem - see the README.
I don't understand what you mean by undo. Uninstall the gem? Undo the
Rails plugin installation?

Aslak

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

From aslak.hellesoy at gmail.com  Sat Nov 25 09:56:48 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 25 Nov 2006 15:56:48 +0100
Subject: [rspec-users] Comparison between RSpec and test/unit
In-Reply-To: <e282921e0611250558w62a6e226y55d4b3a6934893e@mail.gmail.com>
References: <59d991c40611241840v62d9787cwf086e6c12ad7ebbe@mail.gmail.com>
	<e282921e0611250558w62a6e226y55d4b3a6934893e@mail.gmail.com>
Message-ID: <8d961d900611250656m816b415oc5605c2d8638059c@mail.gmail.com>

On 11/25/06, Chris Anderson <jchris at mfdz.com> wrote:
> Here's the relevant URL (if rubyurl is down for you too)
>
> http://chneukirchen.org/blog/archive/2006/10/announcing-test-spec-0-2-a-bdd-interface-for-test-unit.html
>
> I'm not sure what to make of it, either, so perhaps I'll just second
> the question.
>

I have commented in Chris' blog.

Aslak

> On 11/24/06, Christopher Petrilli <petrilli at gmail.com> wrote:
> > I'm curious, Christian Neukirchen has released test/unit[1] that seems
> > to mirror much of RSpec, but built on Test::Unit, so in some ways less
> > brittle from a Rails-integration perspective, and also allowing you to
> > mix the two together as appropriate.
> >
> > So, has anyone made an informed comparison? I'm new enough that I
> > don't really know the finer points yet. The syntax is slightly
> > different, but that seems like a minor issue
> >
> > Chris
> >
> > [1]  http://rubyurl.com/6uT
> >
> > --
> > | Christopher Petrilli
> > | petrilli at gmail.com
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
>
>
> --
> Chris Anderson
> http://jchris.mfdz.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Sat Nov 25 10:32:42 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 25 Nov 2006 09:32:42 -0600
Subject: [rspec-users] rSpec on Rails 1.2?
In-Reply-To: <787A1A5E-42F8-4071-94DA-B9E8CB826799@gmail.com>
References: <4b430c8f0611242002p18e06351xd1acef2c39f39875@mail.gmail.com>
	<787A1A5E-42F8-4071-94DA-B9E8CB826799@gmail.com>
Message-ID: <57c63afe0611250732g337a0cre94e3b91b86f8f3d@mail.gmail.com>

Well, I don't know what kind of crack I was smoking, but quite
suddenly I started experiencing the same problem. I've added the
cattr_accessor statements and all is well. This is committed to the
trunk (rev 1147).

Cheers,
David

On 11/24/06, s.ross <cwdinfo at gmail.com> wrote:
> Here's code I hacked up in my spec_helper.rb that works. Order of the
> statement is important: The cattr_accessor's must precede the
> assignments. (big sigh of relief :)
>
> module Spec
>    module Rails
>      class EvalContext < Test::Unit::TestCase
>          cattr_accessor :fixture_path
>          + cattr_accessor :use_transactional_fixtures
>          + cattr_accessor :use_instantiated_fixtures
>          self.use_transactional_fixtures = true
>          self.use_instantiated_fixtures  = false
>          self.fixture_path = RAILS_ROOT + '/spec/fixtures'
>         ...
>      end
>    end
> end
>
> On Nov 24, 2006, at 8:02 PM, Courtenay wrote:
>
> > Add this line to spec_helper.rb so your testcase subclasses inherit
> > the parent's fixture path and it restores the 'old' way of rails'
> > fixtures.
> >
> > module Spec
> >   module Rails
> >     class EvalContext < Test::Unit::TestCase
> >       self.use_transactional_fixtures = true
> >       self.use_instantiated_fixtures  = false
> >       self.fixture_path = RAILS_ROOT + '/spec/fixtures'
> > +    cattr_accessor :fixture_path
> >       ...
> >     end
> >   end
> > end
> >
> >> I found the cause, it looks like this revision of edge rails
> >> introduced the error we are seeing in rspec.   http://
> >> dev.rubyonrails.org/changeset/5604
> >>
> >> -Chad
> >>
> >> On Nov 24, 2006, at 2:11 AM, s.ross wrote:
> >>
> >>> I just updated my Rails install to the most current Edge and my
> >>> controller specs fail:
> >>>
> >>> 1)
> >>> TypeError in 'The User Controller should be a user controller'
> >>> can't convert nil into String
> >>>
> >>> Each spec fails the same way.
> >>>
> >>> <context string> <spec string>
> >>> can't convert nil into String
> >>>
> >>> Any ideas what's up with this?
> >>>
> >>> Thanks,
> >>>
> >>> s.ross
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From cwdinfo at gmail.com  Sat Nov 25 11:49:19 2006
From: cwdinfo at gmail.com (s.ross)
Date: Sat, 25 Nov 2006 08:49:19 -0800
Subject: [rspec-users] Bugs Fixed in Trunk
In-Reply-To: <8d961d900611250643h4ddaa5aaobedc2c2f2f248930@mail.gmail.com>
References: <C33B020A-69C0-45BF-9C38-CECFBB1C168C@gmail.com>
	<8d961d900611250643h4ddaa5aaobedc2c2f2f248930@mail.gmail.com>
Message-ID: <55999D5C-1ED1-4CEE-AB6F-4E0672B3757A@gmail.com>

Because rSpec doesn't come with either Ruby or Rails, I have to take  
several steps to install a fresh copy:

sudo gem install rspec
plugin/install http://path/to/rspec_on_rails/for/this/version

Then

script/generate rspec (making sure to back up my spec_helper.rb).

This is great when you release a gem, but how about before that when  
you resolve something as "fixed in trunk"? That was the question.

s.ross

On Nov 25, 2006, at 6:43 AM, aslak hellesoy wrote:

> On 11/24/06, s.ross <cwdinfo at gmail.com> wrote:
>> I'm backed off Edge Rails and all the way back to 0.7.2 of rSpec to
>> make my tests pass. The changes to rSpec are coming together fast and
>> furious and they seem too good to pass up. Is there an approved way
>> to upgrade the components in the absence of prebuilt stuff? Every
>
> Components?
>
>> time I've tried, I've been punished harshly by the Version Conflict
>> Gods.
>>
>> Just asking for a quick "how to build it out on osx" and "how to undo
>> all of this if i hosed my system" blurb.
>>
>
> If by "it" you mean the RSpec gem - see the README.
> I don't understand what you mean by undo. Uninstall the gem? Undo the
> Rails plugin installation?
>
> Aslak
>
>> Thanks
>>
>> s.ross
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From keith at dancingtext.com  Mon Nov 27 11:53:19 2006
From: keith at dancingtext.com (Keith McDonnell)
Date: Mon, 27 Nov 2006 16:53:19 +0000
Subject: [rspec-users] rSpec website tutorial correction
In-Reply-To: <mailman.7.1164433720.32645.rspec-users@rubyforge.org>
References: <mailman.7.1164433720.32645.rspec-users@rubyforge.org>
Message-ID: <456B17FF.3020104@dancingtext.com>

Hi there,

On page 
http://rspec.rubyforge.org/documentation/rails/writing/views.html the 
view spec example  is incorrect.

Instead of:

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

It should read:

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

Regards,

Keith


From dchelimsky at gmail.com  Mon Nov 27 12:21:00 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 27 Nov 2006 11:21:00 -0600
Subject: [rspec-users] rSpec website tutorial correction
In-Reply-To: <456B17FF.3020104@dancingtext.com>
References: <mailman.7.1164433720.32645.rspec-users@rubyforge.org>
	<456B17FF.3020104@dancingtext.com>
Message-ID: <57c63afe0611270921j77e6fef0qd5834546ef9a2603@mail.gmail.com>

Actually that is correct.  The idea is that the view specs directory
structure should match the view directory structure.

app/views/thing/show.rhtml
spec/views/thing/show_view_spec.rb

Cheers,
David

On 11/27/06, Keith McDonnell <keith at dancingtext.com> wrote:
> Hi there,
>
> On page
> http://rspec.rubyforge.org/documentation/rails/writing/views.html the
> view spec example  is incorrect.
>
> Instead of:
>
> require File.dirname(__FILE__) + '/../../spec_helper'
>
> It should read:
>
> require File.dirname(__FILE__) + '/../spec_helper'
>
> Regards,
>
> Keith
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From micah at 8thlight.com  Tue Nov 28 17:48:50 2006
From: micah at 8thlight.com (Micah Martin)
Date: Tue, 28 Nov 2006 16:48:50 -0600
Subject: [rspec-users] view specs with partials
Message-ID: <5CA33372-9938-4EDE-8615-871B9BB0A607@8thlight.com>

When I first learned about the View specs I was very excited.  I  
still am.  However, I haven't found them useful yet for one reason.   
They throw the following exception when ever a view renders another  
view, which is very common.

ActionView::TemplateError in 'Event View message'
No rhtml, rxml, rjs or delegate template found for spec/rails/ 
view_spec/_info

I'd really like to be able to write view spec but this is holding me  
up.  Has anyone else bumped into this wall?  Is there something I'm  
missing?

Micah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-users/attachments/20061128/9905f168/attachment.html 

From pergesu at gmail.com  Tue Nov 28 18:40:12 2006
From: pergesu at gmail.com (Pat Maddox)
Date: Tue, 28 Nov 2006 16:40:12 -0700
Subject: [rspec-users] view specs with partials
In-Reply-To: <5CA33372-9938-4EDE-8615-871B9BB0A607@8thlight.com>
References: <5CA33372-9938-4EDE-8615-871B9BB0A607@8thlight.com>
Message-ID: <810a540e0611281540x5646455eu34082578f1b21d4d@mail.gmail.com>

On 11/28/06, Micah Martin <micah at 8thlight.com> wrote:
> When I first learned about the View specs I was very excited.  I still am.
> However, I haven't found them useful yet for one reason.  They throw the
> following exception when ever a view renders another view, which is very
> common.
>
> ActionView::TemplateError in 'Event View message'
> No rhtml, rxml, rjs or delegate template found for
> spec/rails/view_spec/_info
>
> I'd really like to be able to write view spec but this is holding me up.
> Has anyone else bumped into this wall?  Is there something I'm missing?
>
> Micah
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
>

Hey Micah,

Check out http://rubyforge.org/tracker/index.php?func=detail&aid=6903&group_id=797&atid=3149
which is a bug report I filed for the same issue.

Basically in the mean time, just do
render :partial => "controller_name/partial_name"

So like if the partial is named "person" and it's under the "people"
views dir, it'd be
render :partial => "people/person"

That'll work until we get it fixed in the plugin.

Pat

From micah at 8thlight.com  Tue Nov 28 23:36:40 2006
From: micah at 8thlight.com (Micah Martin)
Date: Tue, 28 Nov 2006 22:36:40 -0600
Subject: [rspec-users] view specs with partials
In-Reply-To: <810a540e0611281540x5646455eu34082578f1b21d4d@mail.gmail.com>
References: <5CA33372-9938-4EDE-8615-871B9BB0A607@8thlight.com>
	<810a540e0611281540x5646455eu34082578f1b21d4d@mail.gmail.com>
Message-ID: <A5B485EE-A6CA-4199-B656-9FBA0A2D7463@8thlight.com>

That did the trick.  Thanks Pat.

Micah Martin

On Nov 28, 2006, at 5:40 PM, Pat Maddox wrote:
>
> Basically in the mean time, just do
> render :partial => "controller_name/partial_name"
>
> So like if the partial is named "person" and it's under the "people"
> views dir, it'd be
> render :partial => "people/person"
>
> That'll work until we get it fixed in the plugin.

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

From dchelimsky at gmail.com  Wed Nov 29 01:35:02 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 29 Nov 2006 01:35:02 -0500
Subject: [rspec-users] view specs with partials
In-Reply-To: <A5B485EE-A6CA-4199-B656-9FBA0A2D7463@8thlight.com>
References: <5CA33372-9938-4EDE-8615-871B9BB0A607@8thlight.com>
	<810a540e0611281540x5646455eu34082578f1b21d4d@mail.gmail.com>
	<A5B485EE-A6CA-4199-B656-9FBA0A2D7463@8thlight.com>
Message-ID: <57c63afe0611282235g62378b84l4168a35c46fc7413@mail.gmail.com>

On 11/28/06, Micah Martin <micah at 8thlight.com> wrote:
> That did the trick.  Thanks Pat.
>
>
> Micah Martin
>
> On Nov 28, 2006, at 5:40 PM, Pat Maddox wrote:
>
> Basically in the mean time, just do
> render :partial => "controller_name/partial_name"
>
> So like if the partial is named "person" and it's under the "people"
> views dir, it'd be
> render :partial => "people/person"
>
> That'll work until we get it fixed in the plugin.

We got it fixed in the plugin. In trunk (rev 1174).

Cheers,
David

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

From info at mathias-biilmann.net  Wed Nov 29 10:56:26 2006
From: info at mathias-biilmann.net (Mathias Biilmann Christensen)
Date: Wed, 29 Nov 2006 16:56:26 +0100
Subject: [rspec-users] view specs with partials
In-Reply-To: <57c63afe0611282235g62378b84l4168a35c46fc7413@mail.gmail.com>
References: <5CA33372-9938-4EDE-8615-871B9BB0A607@8thlight.com>
	<810a540e0611281540x5646455eu34082578f1b21d4d@mail.gmail.com>
	<A5B485EE-A6CA-4199-B656-9FBA0A2D7463@8thlight.com>
	<57c63afe0611282235g62378b84l4168a35c46fc7413@mail.gmail.com>
Message-ID: <DA765706-D7C2-453F-B489-2D525C3EFDA6@mathias-biilmann.net>

Great to finally having view specs work with edge rails!

To bad I can't actually use them, since I use helper methods in my  
views. Has anybody gotten calls to helper methods to work in view  
tests under Rails 1.2 RC1?

Currently I get "undefined method `crumbs' for #<#<Class:0x340b70c>: 
0x340ab40>" when the view is calling the crumbs helper (<%= crumbs 
(@var) %>)

Hope there's a solution out there!

Regards,
Mathias


On Nov 29, 2006, at 7:35 AM, David Chelimsky wrote:

> On 11/28/06, Micah Martin <micah at 8thlight.com> wrote:
>> That did the trick.  Thanks Pat.
>>
>>
>> Micah Martin
>>
>> On Nov 28, 2006, at 5:40 PM, Pat Maddox wrote:
>>
>> Basically in the mean time, just do
>> render :partial => "controller_name/partial_name"
>>
>> So like if the partial is named "person" and it's under the "people"
>> views dir, it'd be
>> render :partial => "people/person"
>>
>> That'll work until we get it fixed in the plugin.
>
> We got it fixed in the plugin. In trunk (rev 1174).
>
> Cheers,
> David
>
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From dchelimsky at gmail.com  Wed Nov 29 19:05:57 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 29 Nov 2006 19:05:57 -0500
Subject: [rspec-users] view specs with partials
In-Reply-To: <DA765706-D7C2-453F-B489-2D525C3EFDA6@mathias-biilmann.net>
References: <5CA33372-9938-4EDE-8615-871B9BB0A607@8thlight.com>
	<810a540e0611281540x5646455eu34082578f1b21d4d@mail.gmail.com>
	<A5B485EE-A6CA-4199-B656-9FBA0A2D7463@8thlight.com>
	<57c63afe0611282235g62378b84l4168a35c46fc7413@mail.gmail.com>
	<DA765706-D7C2-453F-B489-2D525C3EFDA6@mathias-biilmann.net>
Message-ID: <57c63afe0611291605k34e90b5areb9332be15d16987@mail.gmail.com>

On 11/29/06, Mathias Biilmann Christensen <info at mathias-biilmann.net> wrote:
> Great to finally having view specs work with edge rails!
>
> To bad I can't actually use them, since I use helper methods in my
> views. Has anybody gotten calls to helper methods to work in view
> tests under Rails 1.2 RC1?
>
> Currently I get "undefined method `crumbs' for #<#<Class:0x340b70c>:
> 0x340ab40>" when the view is calling the crumbs helper (<%= crumbs
> (@var) %>)
>
> Hope there's a solution out there!

There IS!!!!! Incomplete though they are, the specs are the best
source of documentation for questions like this. Take a look at
vendor/plugins/rspec/spec/view_spec_spec. It has the answer to your
question. I'll give you the highlights, but check out the spec if
you're unsure of anything:

context "/some/template" do
  setup do
    render '/some/template', :helper => :some_other #_helper will get appended
  end
  ...
end

OR, if you need more than one:

context "/some/template" do
  setup do
    render '/some/template', :helpers => [:one, :another, :yet_another]
  end
  ...
end

Cheers,
David

>
> Regards,
> Mathias
>
>
> On Nov 29, 2006, at 7:35 AM, David Chelimsky wrote:
>
> > On 11/28/06, Micah Martin <micah at 8thlight.com> wrote:
> >> That did the trick.  Thanks Pat.
> >>
> >>
> >> Micah Martin
> >>
> >> On Nov 28, 2006, at 5:40 PM, Pat Maddox wrote:
> >>
> >> Basically in the mean time, just do
> >> render :partial => "controller_name/partial_name"
> >>
> >> So like if the partial is named "person" and it's under the "people"
> >> views dir, it'd be
> >> render :partial => "people/person"
> >>
> >> That'll work until we get it fixed in the plugin.
> >
> > We got it fixed in the plugin. In trunk (rev 1174).
> >
> > Cheers,
> > David
> >
> >>
> >> _______________________________________________
> >> rspec-users mailing list
> >> rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >>
> >>
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From lastobelus at mac.com  Thu Nov 30 03:01:06 2006
From: lastobelus at mac.com (Michael Johnston)
Date: Thu, 30 Nov 2006 00:01:06 -0800
Subject: [rspec-users] model stubs with view/controller specs:
	error_messages_for??
Message-ID: <3B4D0B4F-DBD6-441D-A7A0-133842DB5E38@mac.com>

How would I set up a model stub so that  <%= error_messages_for  
'some_model' %>  doesn't complain?

I started going down this road:     @some_model.stub! 
(:errors).and_return(ActiveRecord::Errors.new)

but it seems like a long, hopefully uneccessary road.

Cheers,
Michael

From lastobelus at mac.com  Thu Nov 30 03:48:04 2006
From: lastobelus at mac.com (Michael Johnston)
Date: Thu, 30 Nov 2006 00:48:04 -0800
Subject: [rspec-users] response is null when using should_render_rjs
Message-ID: <32743271-6B61-4B0D-B96C-A295BAE88A18@mac.com>

I'm trying to use rspec to test a controller that has ajax.

I have the following action:

   def change_ad_type_form
     render :update do |page|
       page.replace_html 'ad_sub_form', :partial => 'text'
     end
   end

and the following spec:

   specify "should return Text subform on AJAX request to  
change_ad_type_form" do
     controller.should_render_rjs :page,  
'ad_sub_form', :replace_html, 'stuff'
     get 'change_ad_type_form'
   end

which result is the following:

1)
NoMethodError in 'When creating a new ad, the ad_controller should  
return Text subform on AJAX request to change_ad_type_form'
nil does not respond to `rjs' or `has_rjs?'
/Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/ 
rails/render_matcher.rb:61:in `should_render_rjs'
/Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/ 
rails/context/controller.rb:63:in `should_render_rjs'
./spec/controllers/ad_controller_spec.rb:75

(because response is null when it gets to render_matcher)

What am I doing wrong?


Cheers,
Michael

From dchelimsky at gmail.com  Thu Nov 30 07:19:21 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 30 Nov 2006 07:19:21 -0500
Subject: [rspec-users] response is null when using should_render_rjs
In-Reply-To: <32743271-6B61-4B0D-B96C-A295BAE88A18@mac.com>
References: <32743271-6B61-4B0D-B96C-A295BAE88A18@mac.com>
Message-ID: <57c63afe0611300419qc07c1ebs6363bdb888f444a6@mail.gmail.com>

On 11/30/06, Michael Johnston <lastobelus at mac.com> wrote:
> I'm trying to use rspec to test a controller that has ajax.
>
> I have the following action:
>
>    def change_ad_type_form
>      render :update do |page|
>        page.replace_html 'ad_sub_form', :partial => 'text'
>      end
>    end
>
> and the following spec:
>
>    specify "should return Text subform on AJAX request to
> change_ad_type_form" do
>      controller.should_render_rjs :page,
> 'ad_sub_form', :replace_html, 'stuff'
>      get 'change_ad_type_form'
>    end

Using :page in the should_render_rjs call is specifically for elements
accessed via page[:element_name]. You need to either remove :page from
your spec or change the implementation to read:

page[:ad_sub_form].replace_html :partial => 'text'

Cheers,
David
>
> which result is the following:
>
> 1)
> NoMethodError in 'When creating a new ad, the ad_controller should
> return Text subform on AJAX request to change_ad_type_form'
> nil does not respond to `rjs' or `has_rjs?'
> /Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/
> rails/render_matcher.rb:61:in `should_render_rjs'
> /Users/lasto/clients/ibc/project_n/vendor/plugins/rspec/lib/spec/
> rails/context/controller.rb:63:in `should_render_rjs'
> ./spec/controllers/ad_controller_spec.rb:75
>
> (because response is null when it gets to render_matcher)
>
> What am I doing wrong?
>
>
> Cheers,
> Michael
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From dchelimsky at gmail.com  Thu Nov 30 07:20:29 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 30 Nov 2006 07:20:29 -0500
Subject: [rspec-users] model stubs with view/controller specs:
	error_messages_for??
In-Reply-To: <3B4D0B4F-DBD6-441D-A7A0-133842DB5E38@mac.com>
References: <3B4D0B4F-DBD6-441D-A7A0-133842DB5E38@mac.com>
Message-ID: <57c63afe0611300420m4dbbc22bnc98762afe28bb4da@mail.gmail.com>

On 11/30/06, Michael Johnston <lastobelus at mac.com> wrote:
> How would I set up a model stub so that  <%= error_messages_for
> 'some_model' %>  doesn't complain?
>
> I started going down this road:     @some_model.stub!
> (:errors).and_return(ActiveRecord::Errors.new)
>
> but it seems like a long, hopefully uneccessary road.

Try returning a mock instead:

@mock_errors = mock("errors")
@some_model.stub!(:errors).and_return(@mock_errors)

That'll shorten the road quite a bit.

Cheers,
David

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

From lastobelus at mac.com  Thu Nov 30 07:57:10 2006
From: lastobelus at mac.com (Michael Johnston)
Date: Thu, 30 Nov 2006 04:57:10 -0800
Subject: [rspec-users] model stubs with view/controller specs:
	error_messages_for??
In-Reply-To: <57c63afe0611300420m4dbbc22bnc98762afe28bb4da@mail.gmail.com>
References: <3B4D0B4F-DBD6-441D-A7A0-133842DB5E38@mac.com>
	<57c63afe0611300420m4dbbc22bnc98762afe28bb4da@mail.gmail.com>
Message-ID: <3BED92C7-21B1-4CEE-B377-0F3B96884ADA@mac.com>

Mmm, that is how I started, but then it complains there is no "count"  
method

On 30-Nov-06, at 4:20 AM, David Chelimsky wrote:

> On 11/30/06, Michael Johnston <lastobelus at mac.com> wrote:
>> How would I set up a model stub so that  <%= error_messages_for
>> 'some_model' %>  doesn't complain?
>>
>> I started going down this road:     @some_model.stub!
>> (:errors).and_return(ActiveRecord::Errors.new)
>>
>> but it seems like a long, hopefully uneccessary road.
>
> Try returning a mock instead:
>
> @mock_errors = mock("errors")
> @some_model.stub!(:errors).and_return(@mock_errors)
>
> That'll shorten the road quite a bit.
>
> Cheers,
> David
>


From lastobelus at mac.com  Thu Nov 30 08:07:19 2006
From: lastobelus at mac.com (Michael Johnston)
Date: Thu, 30 Nov 2006 05:07:19 -0800
Subject: [rspec-users] response is null when using should_render_rjs
In-Reply-To: <57c63afe0611300419qc07c1ebs6363bdb888f444a6@mail.gmail.com>
References: <32743271-6B61-4B0D-B96C-A295BAE88A18@mac.com>
	<57c63afe0611300419qc07c1ebs6363bdb888f444a6@mail.gmail.com>
Message-ID: <53514934-6040-46A4-B7EB-8BA389AA0AAF@mac.com>

I had tried it without :page and got the same error, and I also  
switched to the syntax you suggested but still get the same error. So  
something else is going on there. When I have time I'll sandbox it  
and try to track it down.

For now unfortunately I have to switch from my newly burgeoning BDD  
mode to my tried-and-true SSCT* mode.

Thanks,
Michael

*show something [to the] client tomorrow


On 30-Nov-06, at 4:19 AM, David Chelimsky wrote:

> On 11/30/06, Michael Johnston <lastobelus at mac.com> wrote:
>> I'm trying to use rspec to test a controller that has ajax.
>>
>> I have the following action:
>>
>>    def change_ad_type_form
>>      render :update do |page|
>>        page.replace_html 'ad_sub_form', :partial => 'text'
>>      end
>>    end
>>
>> and the following spec:
>>
>>    specify "should return Text subform on AJAX request to
>> change_ad_type_form" do
>>      controller.should_render_rjs :page,
>> 'ad_sub_form', :replace_html, 'stuff'
>>      get 'change_ad_type_form'
>>    end
>
> Using :page in the should_render_rjs call is specifically for elements
> accessed via page[:element_name]. You need to either remove :page from
> your spec or change the implementation to read:
>
> page[:ad_sub_form].replace_html :partial => 'text'
>
> Cheers,
> David


From dchelimsky at gmail.com  Thu Nov 30 08:21:26 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 30 Nov 2006 08:21:26 -0500
Subject: [rspec-users] model stubs with view/controller specs:
	error_messages_for??
In-Reply-To: <3BED92C7-21B1-4CEE-B377-0F3B96884ADA@mac.com>
References: <3B4D0B4F-DBD6-441D-A7A0-133842DB5E38@mac.com>
	<57c63afe0611300420m4dbbc22bnc98762afe28bb4da@mail.gmail.com>
	<3BED92C7-21B1-4CEE-B377-0F3B96884ADA@mac.com>
Message-ID: <57c63afe0611300521q233476a5k950da8a77013cb9d@mail.gmail.com>

On 11/30/06, Michael Johnston <lastobelus at mac.com> wrote:
> Mmm, that is how I started, but then it complains there is no "count"
> method

Two options at this point:

@mock_errors.stub!(:count).and_return(0)

or

@some_model.stub!(:errors).and_return([])

I think either will work.

Cheers,
David

>
> On 30-Nov-06, at 4:20 AM, David Chelimsky wrote:
>
> > On 11/30/06, Michael Johnston <lastobelus at mac.com> wrote:
> >> How would I set up a model stub so that  <%= error_messages_for
> >> 'some_model' %>  doesn't complain?
> >>
> >> I started going down this road:     @some_model.stub!
> >> (:errors).and_return(ActiveRecord::Errors.new)
> >>
> >> but it seems like a long, hopefully uneccessary road.
> >
> > Try returning a mock instead:
> >
> > @mock_errors = mock("errors")
> > @some_model.stub!(:errors).and_return(@mock_errors)
> >
> > That'll shorten the road quite a bit.
> >
> > Cheers,
> > David
> >
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From info at mathias-biilmann.net  Thu Nov 30 04:37:31 2006
From: info at mathias-biilmann.net (Mathias Biilmann Christensen)
Date: Thu, 30 Nov 2006 10:37:31 +0100
Subject: [rspec-users] view specs with partials
In-Reply-To: <57c63afe0611291605k34e90b5areb9332be15d16987@mail.gmail.com>
References: <5CA33372-9938-4EDE-8615-871B9BB0A607@8thlight.com>
	<810a540e0611281540x5646455eu34082578f1b21d4d@mail.gmail.com>
	<A5B485EE-A6CA-4199-B656-9FBA0A2D7463@8thlight.com>
	<57c63afe0611282235g62378b84l4168a35c46fc7413@mail.gmail.com>
	<DA765706-D7C2-453F-B489-2D525C3EFDA6@mathias-biilmann.net>
	<57c63afe0611291605k34e90b5areb9332be15d16987@mail.gmail.com>
Message-ID: <BACE9359-C215-4B1E-8592-952E1FE4A605@mathias-biilmann.net>

Thanks a lot - that helped a great deal.

I still seem to have problems with helper methods that are not  
defined in a helper module.  In my Application controller I have a  
current_user method and then uses "  helper_method :current_user" to  
be make it usable for my views.  Any way to stub that method in a  
view test? (I suspect a way to do this would also solve Michael  
Johnston's error_messages_for problem)

Regards,
Mathias


On Nov 30, 2006, at 1:05 AM, David Chelimsky wrote:

> On 11/29/06, Mathias Biilmann Christensen <info at mathias- 
> biilmann.net> wrote:
>> Great to finally having view specs work with edge rails!
>>
>> To bad I can't actually use them, since I use helper methods in my
>> views. Has anybody gotten calls to helper methods to work in view
>> tests under Rails 1.2 RC1?
>>
>> Currently I get "undefined method `crumbs' for #<#<Class:0x340b70c>:
>> 0x340ab40>" when the view is calling the crumbs helper (<%= crumbs
>> (@var) %>)
>>
>> Hope there's a solution out there!
>
> There IS!!!!! Incomplete though they are, the specs are the best
> source of documentation for questions like this. Take a look at
> vendor/plugins/rspec/spec/view_spec_spec. It has the answer to your
> question. I'll give you the highlights, but check out the spec if
> you're unsure of anything:
>
> context "/some/template" do
>   setup do
>     render '/some/template', :helper => :some_other #_helper will  
> get appended
>   end
>   ...
> end
>
> OR, if you need more than one:
>
> context "/some/template" do
>   setup do
>     render '/some/template', :helpers =>  
> [:one, :another, :yet_another]
>   end
>   ...
> end
>
> Cheers,
> David
>
>>
>> Regards,
>> Mathias
>>
>>
>> On Nov 29, 2006, at 7:35 AM, David Chelimsky wrote:
>>
>>> On 11/28/06, Micah Martin <micah at 8thlight.com> wrote:
>>>> That did the trick.  Thanks Pat.
>>>>
>>>>
>>>> Micah Martin
>>>>
>>>> On Nov 28, 2006, at 5:40 PM, Pat Maddox wrote:
>>>>
>>>> Basically in the mean time, just do
>>>> render :partial => "controller_name/partial_name"
>>>>
>>>> So like if the partial is named "person" and it's under the  
>>>> "people"
>>>> views dir, it'd be
>>>> render :partial => "people/person"
>>>>
>>>> That'll work until we get it fixed in the plugin.
>>>
>>> We got it fixed in the plugin. In trunk (rev 1174).
>>>
>>> Cheers,
>>> David
>>>
>>>>
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>
>>>>
>>> _______________________________________________
>>> rspec-users mailing list
>>> rspec-users at rubyforge.org
>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users


From info at mathias-biilmann.net  Thu Nov 30 05:04:23 2006
From: info at mathias-biilmann.net (Mathias Biilmann Christensen)
Date: Thu, 30 Nov 2006 11:04:23 +0100
Subject: [rspec-users] response is null when using should_render_rjs
In-Reply-To: <32743271-6B61-4B0D-B96C-A295BAE88A18@mac.com>
References: <32743271-6B61-4B0D-B96C-A295BAE88A18@mac.com>
Message-ID: <D702263C-77A8-4CE5-9DF7-798026403B43@mathias-biilmann.net>

And a response to my own question :) :

I put this in the end of my view spec:

module ViewSpecsHelper
     def current_user
       nil
     end
end

and then used render => 'controller/template', :helper => :view_specs

That worked - should be easy to use something similar to that to mock  
error_messages_for as well

Regards,
Mathias



On Nov 30, 2006, at 10:37 AM, Mathias Biilmann Christensen wrote:
> Thanks a lot - that helped a great deal.
>
> I still seem to have problems with helper methods that are not  
> defined in a helper module.  In my Application controller I have a  
> current_user method and then uses "  helper_method :current_user"  
> to be make it usable for my views.  Any way to stub that method in  
> a view test? (I suspect a way to do this would also solve Michael  
> Johnston's error_messages_for problem)
>
> Regards,
> Mathias
>
>
> On Nov 30, 2006, at 1:05 AM, David Chelimsky wrote:
>
>> On 11/29/06, Mathias Biilmann Christensen <info at mathias- 
>> biilmann.net> wrote:
>>> Great to finally having view specs work with edge rails!
>>>
>>> To bad I can't actually use them, since I use helper methods in my
>>> views. Has anybody gotten calls to helper methods to work in view
>>> tests under Rails 1.2 RC1?
>>>
>>> Currently I get "undefined method `crumbs' for #<#<Class:0x340b70c>:
>>> 0x340ab40>" when the view is calling the crumbs helper (<%= crumbs
>>> (@var) %>)
>>>
>>> Hope there's a solution out there!
>>
>> There IS!!!!! Incomplete though they are, the specs are the best
>> source of documentation for questions like this. Take a look at
>> vendor/plugins/rspec/spec/view_spec_spec. It has the answer to your
>> question. I'll give you the highlights, but check out the spec if
>> you're unsure of anything:
>>
>> context "/some/template" do
>>   setup do
>>     render '/some/template', :helper => :some_other #_helper will  
>> get appended
>>   end
>>   ...
>> end
>>
>> OR, if you need more than one:
>>
>> context "/some/template" do
>>   setup do
>>     render '/some/template', :helpers =>  
>> [:one, :another, :yet_another]
>>   end
>>   ...
>> end
>>
>> Cheers,
>> David
>>
>>>
>>> Regards,
>>> Mathias
>>>
>>>
>>> On Nov 29, 2006, at 7:35 AM, David Chelimsky wrote:
>>>
>>>> On 11/28/06, Micah Martin <micah at 8thlight.com> wrote:
>>>>> That did the trick.  Thanks Pat.
>>>>>
>>>>>
>>>>> Micah Martin
>>>>>
>>>>> On Nov 28, 2006, at 5:40 PM, Pat Maddox wrote:
>>>>>
>>>>> Basically in the mean time, just do
>>>>> render :partial => "controller_name/partial_name"
>>>>>
>>>>> So like if the partial is named "person" and it's under the  
>>>>> "people"
>>>>> views dir, it'd be
>>>>> render :partial => "people/person"
>>>>>
>>>>> That'll work until we get it fixed in the plugin.
>>>>
>>>> We got it fixed in the plugin. In trunk (rev 1174).
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rspec-users mailing list
>>>>> rspec-users at rubyforge.org
>>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>>>
>>>>>
>>>> _______________________________________________
>>>> rspec-users mailing list
>>>> rspec-users at rubyforge.org
>>>> http://rubyforge.org/mailman/listinfo/rspec-users
>>>
>>> _______________________________________________
>>> 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
>