From luke at agileevolved.com  Tue Aug  1 05:07:43 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 1 Aug 2006 10:07:43 +0100
Subject: [Rspec-devel] [OT]  release 0.5.16 today?
In-Reply-To: <8d961d900607311734y267605aey8472e635d7aaec1c@mail.gmail.com>
References: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com>
	<2c5e719e0607310425g384ae19ew145361a9ba5a79ec@mail.gmail.com>
	<8d961d900607311734y267605aey8472e635d7aaec1c@mail.gmail.com>
Message-ID: <0E88FD09-FC83-4481-9EB1-DC8749BF1E4B@agileevolved.com>

> It *sould* be installed via the rails plugin system, but I actually
> recommend not to because the rails plugin system doesn't handle
> versions that well.

FYI, I'm now on the committers team for the RaPT Rails plugin manager  
system and we have a few ideas about managing plugins through a  
central repository, including handling of different versions. Stay  
tuned...

Cheers
Luke

From jamesmead44 at gmail.com  Tue Aug  1 07:22:05 2006
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 1 Aug 2006 12:22:05 +0100
Subject: [Rspec-devel] rails_plugin_fix merged to trunk
In-Reply-To: <57c63afe0607310213kb86391ch272b1e871b6f4e08@mail.gmail.com>
References: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com>
	<57c63afe0607310213kb86391ch272b1e871b6f4e08@mail.gmail.com>
Message-ID: <1db558f00608010422q50efb583o391fa0cb8f30f922@mail.gmail.com>

On 7/31/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> I want isolated tests for controllers. That's actually why I'm working
> on the mock framework - to support an acts_as_mock plugin that lets
> you stub out class level methods like new and find. That way
> controller specs can avoid the database entirely and specs for model
> stuff (like validation) can live in the model where it is implemented.

Hi David. I really like what you guys are doing with RSpec. I was
wondering if you'd seen Stubba (http://mocha.rubyforge.org). It allows
you to stub class methods like :new and :find and avoid hitting the
database. Here's a trivial example...

def test_should_find_expected_product
  expected_product = Product.new
  Product.stubs(:find).returns(product)
  assert_equal expected_product, Product.find(123)
end

- The Product class reverts to its original behaviour after each test.
- You can specify different return values in different tests.
- The test is explicit, because the return value is defined in the test.

We're using it on Rails projects at Reevoo.

James.
http://blog.floehopper.org

From luke at agileevolved.com  Tue Aug  1 07:37:03 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 1 Aug 2006 12:37:03 +0100
Subject: [Rspec-devel] rails_plugin_fix merged to trunk
In-Reply-To: <1db558f00608010422q50efb583o391fa0cb8f30f922@mail.gmail.com>
References: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com>
	<57c63afe0607310213kb86391ch272b1e871b6f4e08@mail.gmail.com>
	<1db558f00608010422q50efb583o391fa0cb8f30f922@mail.gmail.com>
Message-ID: <8262B1FD-9C59-4A0D-B4D5-7E1D4F094DED@agileevolved.com>

Hi James

Thanks for posting this - I can't believe I hadn't come across this  
before. For mocks, I'm pretty happy with the mocking built into   
rSpec (or FlexMock when I'm using Test::Unit) but I really like the  
look of Stubba - far more elegant than monkey patching existing  
classes with stub methods.

Cheers
Luke

On 1 Aug 2006, at 12:22, James Mead wrote:

> On 7/31/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>> I want isolated tests for controllers. That's actually why I'm  
>> working
>> on the mock framework - to support an acts_as_mock plugin that lets
>> you stub out class level methods like new and find. That way
>> controller specs can avoid the database entirely and specs for model
>> stuff (like validation) can live in the model where it is  
>> implemented.
>
> Hi David. I really like what you guys are doing with RSpec. I was
> wondering if you'd seen Stubba (http://mocha.rubyforge.org). It allows
> you to stub class methods like :new and :find and avoid hitting the
> database. Here's a trivial example...
>
> def test_should_find_expected_product
>   expected_product = Product.new
>   Product.stubs(:find).returns(product)
>   assert_equal expected_product, Product.find(123)
> end
>
> - The Product class reverts to its original behaviour after each test.
> - You can specify different return values in different tests.
> - The test is explicit, because the return value is defined in the  
> test.
>
> We're using it on Rails projects at Reevoo.
>
> James.
> http://blog.floehopper.org
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Tue Aug  1 08:01:37 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 1 Aug 2006 07:01:37 -0500
Subject: [Rspec-devel] [OT] release 0.5.16 today?
In-Reply-To: <0E88FD09-FC83-4481-9EB1-DC8749BF1E4B@agileevolved.com>
References: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com>
	<2c5e719e0607310425g384ae19ew145361a9ba5a79ec@mail.gmail.com>
	<8d961d900607311734y267605aey8472e635d7aaec1c@mail.gmail.com>
	<0E88FD09-FC83-4481-9EB1-DC8749BF1E4B@agileevolved.com>
Message-ID: <8d961d900608010501s1ad6f6c7s7f551d914e2fdf21@mail.gmail.com>

On 8/1/06, Luke Redpath <luke at agileevolved.com> wrote:
> > It *sould* be installed via the rails plugin system, but I actually
> > recommend not to because the rails plugin system doesn't handle
> > versions that well.
>
> FYI, I'm now on the committers team for the RaPT Rails plugin manager
> system and we have a few ideas about managing plugins through a
> central repository, including handling of different versions. Stay
> tuned...
>

That sounds promising Luke. Thanks!

Aslak

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

From aslak.hellesoy at gmail.com  Tue Aug  1 08:13:16 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 1 Aug 2006 07:13:16 -0500
Subject: [Rspec-devel] rails_plugin_fix merged to trunk
In-Reply-To: <1db558f00608010422q50efb583o391fa0cb8f30f922@mail.gmail.com>
References: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com>
	<57c63afe0607310213kb86391ch272b1e871b6f4e08@mail.gmail.com>
	<1db558f00608010422q50efb583o391fa0cb8f30f922@mail.gmail.com>
Message-ID: <8d961d900608010513o7cd511edxe199758ac6d78677@mail.gmail.com>

On 8/1/06, James Mead <jamesmead44 at gmail.com> wrote:
> On 7/31/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > I want isolated tests for controllers. That's actually why I'm working
> > on the mock framework - to support an acts_as_mock plugin that lets
> > you stub out class level methods like new and find. That way
> > controller specs can avoid the database entirely and specs for model
> > stuff (like validation) can live in the model where it is implemented.
>
> Hi David. I really like what you guys are doing with RSpec. I was
> wondering if you'd seen Stubba (http://mocha.rubyforge.org). It allows
> you to stub class methods like :new and :find and avoid hitting the
> database. Here's a trivial example...
>
> def test_should_find_expected_product
>   expected_product = Product.new
>   Product.stubs(:find).returns(product)
>   assert_equal expected_product, Product.find(123)
> end
>
> - The Product class reverts to its original behaviour after each test.
> - You can specify different return values in different tests.
> - The test is explicit, because the return value is defined in the test.
>
> We're using it on Rails projects at Reevoo.
>

Hi James,

Didn't we work together a couple of years ago? Or am I getting senile :-)

Anyway - Mocha/Stubba looks very interesting. I like the way it can
get rid of trips to the database. A couple of questions:

1) When you do Product.stubs(:find) - I would assume that this has a
sideeffect by forever changing the find class method? If that's so,
how do you avoid interdependencies between tests/specs? If I'm
mistaken - how does it *not* have a sideeffect?

2) Product.stubs(:find) use define_method or method_missing?

Aslak

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

From jamesmead44 at gmail.com  Tue Aug  1 09:41:55 2006
From: jamesmead44 at gmail.com (James Mead)
Date: Tue, 1 Aug 2006 14:41:55 +0100
Subject: [Rspec-devel] rails_plugin_fix merged to trunk
In-Reply-To: <8d961d900608010513o7cd511edxe199758ac6d78677@mail.gmail.com>
References: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com>
	<57c63afe0607310213kb86391ch272b1e871b6f4e08@mail.gmail.com>
	<1db558f00608010422q50efb583o391fa0cb8f30f922@mail.gmail.com>
	<8d961d900608010513o7cd511edxe199758ac6d78677@mail.gmail.com>
Message-ID: <1db558f00608010641o4602aab6s9ce5210140dc7df4@mail.gmail.com>

Hi Aslak,

On 8/1/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> Didn't we work together a couple of years ago? Or am I getting senile :-)

No, you're not going senile - we did work together at ThoughtWorks.

> Anyway - Mocha/Stubba looks very interesting. I like the way it can
> get rid of trips to the database. A couple of questions:
>
> 1) When you do Product.stubs(:find) - I would assume that this has a
> sideeffect by forever changing the find class method? If that's so,
> how do you avoid interdependencies between tests/specs? If I'm
> mistaken - how does it *not* have a sideeffect?

It does change the class method, but not forever - it puts the
original method to one side and re-instates it on teardown of the
test.

> 2) Product.stubs(:find) use define_method or method_missing?

The :stubs method is added to Object, but only in the test
environment. Obviously there is scope for a name clash, but we haven't
hit that problem yet and we're using it quite extensively on a couple
of Rails projects at Reevoo (http://www.reevoo.com). The :stubs method
delegates to an instance of a Mocha Mock which is stored against the
Product class.

Does that make any sense? You can stub not only at the class method
level, but also against an instance or even all instances of a class.
There are some more examples at
http://blog.floehopper.org/articles/2006/07/16/stubba-example

James.
http://blog.floehopper.org

From srbaker at pobox.com  Wed Aug  2 16:26:18 2006
From: srbaker at pobox.com (Steven R.Baker)
Date: Wed, 2 Aug 2006 16:26:18 -0400
Subject: [Rspec-devel] New Lead Developer
Message-ID: <9F6AADB6-40F5-4D8E-A057-F13F081B6861@pobox.com>

Everyone,

I first wrote RSpec a year ago as a personal exercise to improve my  
understanding of, and abilities utilizing, metaprogramming in Ruby.   
Behaviour Driven Development was also new, and was just starting to  
get traction.  The increasing popularity of Ruby (likely as a result  
of Rails) combined with the introduction of fresh ideas with BDD  
caused RSpec to become wildly popular.

What was originally intended as a throw away project, just to see if  
I could, has turned into something that I no longer really have the  
vision for.  I have learned a great deal working on RSpec, but I have  
outlived my utility as the lead developer.  As RSpec matures, I am  
far more interested in seeing what new developments in BDD are  
arising than I am in trying to blaze the trails myself.

David Chelimsky has been one of the most active contributors since he  
joined the project, in terms of code written, mailing list  
assistance, and new ideas.  Dave has a genuine interest in both the  
project, the community around the project, and the ideas that RSpec  
is encouraging people to learn.  Effective immediately, Dave will be  
the lead developer of RSpec.  In collective code ownership, this  
doesn't matter, but I've always leaned towards weak code ownership,  
though, and I find that it is especially important in Open Source  
projects.

Dave has been made an Admin on the Rubyforge project page.  In a few  
weeks, I'll ask him to reduce me to "Senior Developer" once we know  
that the transition issues are solved.  Thanks to Dave for taking  
this on, so that I can focus on other things.  I'm looking forward to  
seeing what happens next.

Oh yeah, the dots are his fault.

-Steven


From luke at agileevolved.com  Thu Aug  3 06:56:07 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 3 Aug 2006 11:56:07 +0100
Subject: [Rspec-devel]  [OT] rapt handling plugin versions
In-Reply-To: <8d961d900608010501s1ad6f6c7s7f551d914e2fdf21@mail.gmail.com>
References: <8d961d900607310412o7121977xceaddfa290b3f3c0@mail.gmail.com>
	<2c5e719e0607310425g384ae19ew145361a9ba5a79ec@mail.gmail.com>
	<8d961d900607311734y267605aey8472e635d7aaec1c@mail.gmail.com>
	<0E88FD09-FC83-4481-9EB1-DC8749BF1E4B@agileevolved.com>
	<8d961d900608010501s1ad6f6c7s7f551d914e2fdf21@mail.gmail.com>
Message-ID: <F00EFB57-3851-4FF0-9E3B-5DF2D2995D72@agileevolved.com>

Hi Guys

Further to my email below, I thought you'd be interested in a feature  
I checked into the RaPT trunk yesterday.

RaPT will now handle plugins that make use of the trunk/tags/branches  
structure. Furthermore, it will automatically detect plugin versions  
- "bleeding edge" for the trunk plus a version for every tag in the  
tags folder. All you need to do is point RaPT at the root of the  
repository and it will prompt you for which version you want to  
install. Alternatively you can explicitly specify a version with the  
--version switch. It will also make sure the plugin is installed into  
the plugins folder with the correct plugin name.

If you want to play around with it, you'll need to check out the  
latest source from the RaPT trunk (see http://rubyforge.org/projects/ 
rapt/) and compile and install the gem. You can now do:

$ rapt install http://opensource.agileevolved.com/svn/root/ 
rails_plugins/unobtrusive_javascript/

Or a specific version:

$ rapt install http://opensource.agileevolved.com/svn/root/ 
rails_plugins/unobtrusive_javascript/ --version=rel-0.2

Currently this only works with http:// repositories - I'll get it  
working with svn:// repositories today or tomorrow.

A final note, if a plugin doesn't use the trunk/tags/branches  
structure RaPT will assume it has a single "bleeding edge" version.  
Finally, if a plugin does only have a single version, RaPT will  
install it without prompting.

I'm going to press Geoffrey Grosenbach to push out a new release of  
RaPT in the coming week as it also has support for plugin packs now  
(see my blog). Work has also begun on the central plugin repository,  
more on that later.

If you have any questions or suggestions, feel free to email me off  
list.

Cheers
Luke
www.lukeredpath.co.uk

On 1 Aug 2006, at 13:01, aslak hellesoy wrote:

> On 8/1/06, Luke Redpath <luke at agileevolved.com> wrote:
>>> It *sould* be installed via the rails plugin system, but I actually
>>> recommend not to because the rails plugin system doesn't handle
>>> versions that well.
>>
>> FYI, I'm now on the committers team for the RaPT Rails plugin manager
>> system and we have a few ideas about managing plugins through a
>> central repository, including handling of different versions. Stay
>> tuned...
>>
>
> That sounds promising Luke. Thanks!
>
> Aslak
>
>> Cheers
>> Luke
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From luke at agileevolved.com  Thu Aug  3 07:00:05 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 3 Aug 2006 12:00:05 +0100
Subject: [Rspec-devel] Documentation issue: hpricot dependency
Message-ID: <06A47BF1-ACE9-4AF1-9ECE-DB59D2984C70@agileevolved.com>

I thought I'd give the rspec on rails plugin a go (we're gonna use it  
for the rails plugin repository) - I ran across one small issue that  
wasn't mentioned on the website - you need to have the hpricot gem  
installed other script/generate rspec barfs. It might be worth making  
a note of this.

Cheers
Luke

From luke at agileevolved.com  Thu Aug  3 07:03:52 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 3 Aug 2006 12:03:52 +0100
Subject: [Rspec-devel] Documentation issue: hpricot dependency - IGNORE
In-Reply-To: <06A47BF1-ACE9-4AF1-9ECE-DB59D2984C70@agileevolved.com>
References: <06A47BF1-ACE9-4AF1-9ECE-DB59D2984C70@agileevolved.com>
Message-ID: <120A0F69-11C2-4E0B-8920-9EE769AD027D@agileevolved.com>

Sorry, my bad. It turns out the app I was working on had the  
undocumented dependency, not rspec.

One of those days...

Cheers
Luke

On 3 Aug 2006, at 12:00, Luke Redpath wrote:

> I thought I'd give the rspec on rails plugin a go (we're gonna use it
> for the rails plugin repository) - I ran across one small issue that
> wasn't mentioned on the website - you need to have the hpricot gem
> installed other script/generate rspec barfs. It might be worth making
> a note of this.
>
> Cheers
> Luke
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From luke at agileevolved.com  Thu Aug  3 07:51:20 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 3 Aug 2006 12:51:20 +0100
Subject: [Rspec-devel] test2spec not working with Rails
Message-ID: <7AD09936-880D-4DC7-A996-A077A12360ED@agileevolved.com>

I'm having trouble getting the test2spec tool working with a Rails  
app. I've tried this with both trunk and 0.5.16 versions of the  
plugin. Here's what I'm getting:

http://pastie.caboo.se/7132

VersionTest and PluginTest are the two tests that should be  
translated. I have no idea where its getting  
ActionController::IntegrationTest from - there aren't any integration  
tests!

I have this at the top of my test_helper.rb file:

require File.dirname(__FILE__) + '/test2spec_help'
# require 'test_help'

Just doing require 'test2spec_help' didn't actually work for me.

Any ideas whats going on here? I'm running on OSX with Ruby 1.8.4 if  
it makes any difference.

Cheers
Luke

From luke at agileevolved.com  Thu Aug  3 07:53:45 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 3 Aug 2006 12:53:45 +0100
Subject: [Rspec-devel] test2spec not working with Rails
In-Reply-To: <7AD09936-880D-4DC7-A996-A077A12360ED@agileevolved.com>
References: <7AD09936-880D-4DC7-A996-A077A12360ED@agileevolved.com>
Message-ID: <FC13C764-6575-4779-A04F-C9547CA12122@agileevolved.com>

I should also mention I'm running on edge rails.

Cheers
Luke

On 3 Aug 2006, at 12:51, Luke Redpath wrote:

> I'm having trouble getting the test2spec tool working with a Rails
> app. I've tried this with both trunk and 0.5.16 versions of the
> plugin. Here's what I'm getting:
>
> http://pastie.caboo.se/7132
>
> VersionTest and PluginTest are the two tests that should be
> translated. I have no idea where its getting
> ActionController::IntegrationTest from - there aren't any integration
> tests!
>
> I have this at the top of my test_helper.rb file:
>
> require File.dirname(__FILE__) + '/test2spec_help'
> # require 'test_help'
>
> Just doing require 'test2spec_help' didn't actually work for me.
>
> Any ideas whats going on here? I'm running on OSX with Ruby 1.8.4 if
> it makes any difference.
>
> Cheers
> Luke
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From luke at agileevolved.com  Thu Aug  3 09:47:15 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 3 Aug 2006 14:47:15 +0100
Subject: [Rspec-devel] rails_plugin_fix merged to trunk
In-Reply-To: <1db558f00608010422q50efb583o391fa0cb8f30f922@mail.gmail.com>
References: <8d961d900607302159p58caceb9kf694baa6c650db4@mail.gmail.com>
	<57c63afe0607310213kb86391ch272b1e871b6f4e08@mail.gmail.com>
	<1db558f00608010422q50efb583o391fa0cb8f30f922@mail.gmail.com>
Message-ID: <A329E57B-873B-4ABB-A25E-2E64041D93FE@agileevolved.com>

Hi James

I've encountered a small problem using Stubba with RSpec and Rails.  
It seems - probably due to the way spec_helper.rb works - that  
teardown_with_stubba is being called twice, resulting in no method  
error when it tries to call nil.unstub_all and therefore failing all  
specs.

The solution was a simple one, I just added a small guard clause:

   def teardown_with_stubba
     return if $stubba.nil?
     $stubba.unstub_all
     $stubba = nil
   end

Cheers
Luke

> Hi David. I really like what you guys are doing with RSpec. I was
> wondering if you'd seen Stubba (http://mocha.rubyforge.org). It allows
> you to stub class methods like :new and :find and avoid hitting the
> database. Here's a trivial example...
>
> def test_should_find_expected_product
>   expected_product = Product.new
>   Product.stubs(:find).returns(product)
>   assert_equal expected_product, Product.find(123)
> end
>
> - The Product class reverts to its original behaviour after each test.
> - You can specify different return values in different tests.
> - The test is explicit, because the return value is defined in the  
> test.
>
> We're using it on Rails projects at Reevoo.
>
> James.
> http://blog.floehopper.org
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From dchelimsky at gmail.com  Fri Aug  4 06:54:25 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 4 Aug 2006 05:54:25 -0500
Subject: [Rspec-devel] New Lead Developer
In-Reply-To: <9F6AADB6-40F5-4D8E-A057-F13F081B6861@pobox.com>
References: <9F6AADB6-40F5-4D8E-A057-F13F081B6861@pobox.com>
Message-ID: <57c63afe0608040354y10a105d0i4af0dccd5f900b39@mail.gmail.com>

On 8/2/06, Steven R. Baker <srbaker at pobox.com> wrote:
> Everyone,
>
> I first wrote RSpec a year ago as a personal exercise to improve my
> understanding of, and abilities utilizing, metaprogramming in Ruby.
> Behaviour Driven Development was also new, and was just starting to
> get traction.  The increasing popularity of Ruby (likely as a result
> of Rails) combined with the introduction of fresh ideas with BDD
> caused RSpec to become wildly popular.
>
> What was originally intended as a throw away project, just to see if
> I could, has turned into something that I no longer really have the
> vision for.  I have learned a great deal working on RSpec, but I have
> outlived my utility as the lead developer.  As RSpec matures, I am
> far more interested in seeing what new developments in BDD are
> arising than I am in trying to blaze the trails myself.
>
> David Chelimsky has been one of the most active contributors since he
> joined the project, in terms of code written, mailing list
> assistance, and new ideas.  Dave has a genuine interest in both the
> project, the community around the project, and the ideas that RSpec
> is encouraging people to learn.  Effective immediately, Dave will be
> the lead developer of RSpec.  In collective code ownership, this
> doesn't matter, but I've always leaned towards weak code ownership,
> though, and I find that it is especially important in Open Source
> projects.
>
> Dave has been made an Admin on the Rubyforge project page.  In a few
> weeks, I'll ask him to reduce me to "Senior Developer" once we know
> that the transition issues are solved.  Thanks to Dave for taking
> this on, so that I can focus on other things.  I'm looking forward to
> seeing what happens next.

Me too! Thanks to Steve for getting this project started and welcoming
me in as a contributor. His little exercise has turned into what I
view as a very important resource for all of us interested in BDD, and
anyone else who is interested in improving the state of TDD.

Thanks also to Dave Astels for introducing me to rspec and BDD in the
first place, to Aslak Hellesoy for being such a passionate
contributor, and to everyone else who has contributed patches and
ideas along the way.

As Steve suggested, I am genuinely interested in the wider context of
BDD. Dan North, the guy that coined the name BDD, initially talked
about it (and continues to) as a collaborative approach to documenting
software acceptance criteria in a way that supports all team members
talking the same language and, as almost a side effect, provides clear
direction for developers in terms of what to build.

As a developer, I tend towards the same developer focus that most of
us do, but the team collaboration aspects of BDD are not only very
interesting to me, but I view them as the underlying principles of
this project. If we're going to call this a BDD framework it is
essential that we align the rspec vision with the wider BDD vision.

So what does that mean? Not much really. RSpec is already a partial
manifestation of that vision. There is nothing in it that conflicts
with the BDD vision. The same people that are currently involved will
remain involved as long as they care to. The same values that Steve
has held (most especially keeping the users in focus) will remain.
I've been acting as a pragmatist/moderator of sorts anyhow, so this
simply makes that role an official one.

Thanks again to all who care about and contribute to this exciting project.

Cheers,
David

> Oh yeah, the dots are his fault.

Oh yeah, the dots that removed almost all of the Object pollution are
my fault :)

From lists-rspec at shopwatch.org  Fri Aug  4 07:05:06 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Fri, 04 Aug 2006 07:05:06 -0400
Subject: [Rspec-devel] New Lead Developer
In-Reply-To: <9F6AADB6-40F5-4D8E-A057-F13F081B6861@pobox.com>
References: <9F6AADB6-40F5-4D8E-A057-F13F081B6861@pobox.com>
Message-ID: <44D329E2.6020500@rubyforge.org>

Steven R.Baker wrote:
 > Effective immediately, Dave will be the lead developer of RSpec.

Congratulations, David!  I look forward to an era of new prosperity, 
lower taxes, a chicken in every repository, etc.

Jay Levitt


From dchelimsky at gmail.com  Fri Aug  4 19:52:32 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Fri, 4 Aug 2006 18:52:32 -0500
Subject: [Rspec-devel] a commitment to underscores
Message-ID: <57c63afe0608041652n10744519pc102b65eedb65cc@mail.gmail.com>

rspec'ers

We've been living in a world for a couple of months in which rspec
supports both dots and underscores. Supporting both is gumming up the
works at this point and I'd like to commit to one or the other.
Assuming that all would prefer underscores, I've changed all of the
tests to use only underscores, fixing a few new problems as they
appeared.

Unless there is a surprising and overwhelming desire to revert to
dots, I'd like to commit to supporting only underscores (not dots).
Doing so will allow us to clean up quite a bit of code.

Any concerns? Objections?

Thanks,
David

From dchelimsky at gmail.com  Sat Aug  5 17:07:14 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 5 Aug 2006 16:07:14 -0500
Subject: [Rspec-devel] underscore commitment committed
Message-ID: <57c63afe0608051407m25ff711dm6b15846567108bb@mail.gmail.com>

rspec'ers

I've committed numerous changes relating to dots, underscores, and
mocks. This code will break your specs that use dots (with a couple of
exceptions noted below), so  you'll have to change the dots to
underscores if you've been using them. Feel free to check out the
trunk, run it against your existing specs and report back any problems
other than those related to dots and underscores (I'm expecting none,
but you never know).

Note that there are still a couple of places where dots seem more
correct. For example:

    mock.should_receive(:message).once.and_return(value)

that makes more sense (IMO) than:

    mock.should_receive(:message).once_and_return(value)

because "once_and_return" doesn't really make sense as a message to me.

Assuming there are no major issues, we'll do a release mid-week.

Thanks,
David

From dchelimsky at gmail.com  Wed Aug  9 10:28:35 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 9 Aug 2006 09:28:35 -0500
Subject: [Rspec-devel] Given,Then,When
Message-ID: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>

Fellow rspec'ers:

One thing lacking in the current rspec syntax is direct support of the
BDD triad: Given,When,Then. Right now, rspec supports Given in the
form of contexts and combines When and Then in specify blocks. This
lends itself well to structural aspects of the code we're specifying
(i.e. "A standard deck of cards should have 52 cards", but does not do
a good job of separating out events (When) from expected outcomes
(Then).

In addition to better alignment w/ BDD-speak, separating out the Then
from the When would also support things like using the expectations to
drive documentation when there is only one expectation in the "then"

behavior_of "A mug" do
  given "an empty mug" do
    @mug = Mug.new
    @bartender = Bartender.new
  end
  when "the bartender is finished pouring beer into it" do
    @bartender.pour_beer_into @mug
  end
  then do
    @mug.should_be_full
  end
end

producing something like:

Given an empty mug
When the bartender is finished pouring beer into it
Then mug should be full

If you want that to read "Then the mug should be full" (adding "the"
for readability), you could always pass a string to the method, but
this would mean that you wouldn't have to, eliminating some of the
duplication between documentation and code.

This could possibly work for mocks as well. Because we have control
over the various blocks, we might be able to reverse execution order
when mocks are involved. This would allow us to keep the expectations
at the end when mocks are used (rather than setting them in advance),
preserving the Given,When,Then format!

behaviour_of "A deck of cards" do
  given "A freshly shuffled deck" do
    @deck = Deck.new
    @deck.shuffle
    @first_hand = mock("hand")
    @second_hand = mock("hand")
  end
  when "asked to deal a standard poker hand" do
    @deck.deal [@hand]
  end
  then "the hand should receive five cards" do
    @hand.should_receive(:add_card).exactly(5).times
  end
end

Thoughts?

David

From dchelimsky at gmail.com  Wed Aug  9 16:08:49 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 9 Aug 2006 15:08:49 -0500
Subject: [Rspec-devel] [ANN] RSpec 0.6.0
Message-ID: <57c63afe0608091308l91e2440x46126d1333c8fdd9@mail.gmail.com>

This release represents a formal commitment to underscores (dots are
no longer supported), which allowed us to reduce the code base by
nearly 10%.

http://rubyforge.org/frs/shownotes.php?release_id=6377
http://rspec.rubyforge.org/

To be clear, if you have dots in your examples, they may break. The
only exception to the rule is after "once" or "twice" when setting
mock expectations:
http://rspec.rubyforge.org/documentation/mocks.html

Additionally, there are several other improvements to the mock API, as
well as some bug fixes.

Enjoy!
David

From aslak.hellesoy at gmail.com  Wed Aug  9 17:04:41 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 9 Aug 2006 16:04:41 -0500
Subject: [Rspec-devel] [Rspec-users] [ANN] RSpec 0.6.0
In-Reply-To: <57c63afe0608091308l91e2440x46126d1333c8fdd9@mail.gmail.com>
References: <57c63afe0608091308l91e2440x46126d1333c8fdd9@mail.gmail.com>
Message-ID: <8d961d900608091404n54fc6b6s831bfe86b1e008e2@mail.gmail.com>

I haven't looked at the recent changes, so bear with me...

On 8/9/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> This release represents a formal commitment to underscores (dots are
> no longer supported),

What exactly do we mean by "supported"? Dots still seem to work ok.
Can you give an example of when thet will not work?

> which allowed us to reduce the code base by
> nearly 10%.
>

That's awesome! What code got sliced?

I see sugar is still in there, so I assume underscored syntax is just
delegating to the dotted one. If that's so, doesn't that mean that
using dots is just as good as using underscores (in case anyone is
masochistic enough to do it - I'm all for underscores)?

> http://rubyforge.org/frs/shownotes.php?release_id=6377
> http://rspec.rubyforge.org/
>
> To be clear, if you have dots in your examples, they may break. The

Ho ho ho - David is playing with a new word - "examples" :-)
Is it about time to announce that the T word is now verboten on this list?

Which brings up another point of discussion. What's the best word to
use instead of the T word? (See separate mail)

> only exception to the rule is after "once" or "twice" when setting
> mock expectations:
> http://rspec.rubyforge.org/documentation/mocks.html
>
> Additionally, there are several other improvements to the mock API, as
> well as some bug fixes.
>
> Enjoy!
> David
> _______________________________________________
> Rspec-users mailing list
> Rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

From aslak.hellesoy at gmail.com  Wed Aug  9 17:12:10 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 9 Aug 2006 16:12:10 -0500
Subject: [Rspec-devel] Lingo
Message-ID: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>

We all hate the T word. We have a few alternatives for it. Whatever
word we end up with, I think it's important that the word:

o fits well with the BDD mantra and vocabulary
o and this ruby framework's name be aligned
o can be used effectively in conversations between (possibly
non-trechnical) people

Here is my take on some of them

== Spec ==
Pro: Fits well with the RSpec name
Con: Not so easy to 'talk' about
Con: Doesn't underline the Behavioural gist of BDD

== Example ==
Pro: Easy to talk about
Con: Doesn't fit with the RSpec name
Con: doesn't fit with BDD lingo

== Behaviour ==
Pro: Fits with the BDD lingo
Con: May be hard to talk about in some situations / with some people
Con: Doesn't fit the RSpec name

Personally I'm a fan of 'Example'. It's easy to explain to people. So
how would we address the two cons? For the RSpec name, we could simply
change the name of RSpec to something else. For the mismatch with BDD
lingo, perhaps we could start talking about "Behaviour Driven
Development by Example"? (We give examples of the software's desired
behaviour).

What do you think folks?

Aslak

From dchelimsky at gmail.com  Wed Aug  9 17:14:12 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 9 Aug 2006 16:14:12 -0500
Subject: [Rspec-devel] [Rspec-users] [ANN] RSpec 0.6.0
In-Reply-To: <8d961d900608091404n54fc6b6s831bfe86b1e008e2@mail.gmail.com>
References: <57c63afe0608091308l91e2440x46126d1333c8fdd9@mail.gmail.com>
	<8d961d900608091404n54fc6b6s831bfe86b1e008e2@mail.gmail.com>
Message-ID: <57c63afe0608091414p6e7a79aelbb7ec0e5b1d0c142@mail.gmail.com>

On 8/9/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> I haven't looked at the recent changes, so bear with me...
>
> On 8/9/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > This release represents a formal commitment to underscores (dots are
> > no longer supported),
>
> What exactly do we mean by "supported"? Dots still seem to work ok.
> Can you give an example of when thet will not work?

should.be.an.instance.of
should.be.a.kind.of
at.least
at.most

to name a few

There are some that will continue to work for now due to the
underlying implementation, but that may or may not change based on
future needs of the system.

>
> > which allowed us to reduce the code base by
> > nearly 10%.
> >
>
> That's awesome! What code got sliced?

Most of it came from should_helper, should_negator and we got rid of
several other helpers.

>
> I see sugar is still in there, so I assume underscored syntax is just
> delegating to the dotted one. If that's so, doesn't that mean that
> using dots is just as good as using underscores (in case anyone is
> masochistic enough to do it - I'm all for underscores)?

Sugar will live on. It is what all who spoke up prefer. Except for Dave ;)

>
> > http://rubyforge.org/frs/shownotes.php?release_id=6377
> > http://rspec.rubyforge.org/
> >
> > To be clear, if you have dots in your examples, they may break. The
>
> Ho ho ho - David is playing with a new word - "examples" :-)
> Is it about time to announce that the T word is now verboten on this list?

I like the word examples better than specs because it works better w/
statements like "run the examples". It removes the test/spec
confusion.

>
> Which brings up another point of discussion. What's the best word to
> use instead of the T word? (See separate mail)

Example, I say. Well, Brian Marick probably said it first. Dan likes
to use scenario, but that carries a lot of other baggage w/ it
("scenario testing"). We'll leave more discussion for the other email.

From dchelimsky at gmail.com  Wed Aug  9 17:33:26 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 9 Aug 2006 16:33:26 -0500
Subject: [Rspec-devel] Lingo
In-Reply-To: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>
References: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>
Message-ID: <57c63afe0608091433r284878b7x8a5482586576d9af@mail.gmail.com>

On 8/9/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> We all hate the T word. We have a few alternatives for it. Whatever
> word we end up with, I think it's important that the word:
>
> o fits well with the BDD mantra and vocabulary
> o and this ruby framework's name be aligned
> o can be used effectively in conversations between (possibly
> non-trechnical) people

Hear, hear!

>
> Here is my take on some of them
>
> == Spec ==
> Pro: Fits well with the RSpec name
> Con: Not so easy to 'talk' about
> Con: Doesn't underline the Behavioural gist of BDD
-1
We're there now and we all struggle w/ it. I don't think there's a
problem w/ the name. The only other good names have example or behave
in them, and that's sort of Brain and Dan's territory.

>
> == Example ==
> Pro: Easy to talk about
> Con: Doesn't fit with the RSpec name
> Con: doesn't fit with BDD lingo
+1
I don't really care about the name that much. We can still call it a
spec framework that allows you to automate examples of the spec. I
also don't think that it conflicts w/ the BDD lingo. Dan's using
scenario, but that carries more baggage than "test" does ("scenario
testing"). Saying that we break down a story into examples sounds
close enough to breaking it into scenarios for my money.

> == Behaviour ==
> Pro: Fits with the BDD lingo
> Con: May be hard to talk about in some situations / with some people
> Con: Doesn't fit the RSpec name
+1
I think that behavior is a superset of examples. It parallels the user
story, whereas the examples map to scenarios.

> Personally I'm a fan of 'Example'. It's easy to explain to people.
Not just easy - but it makes sense from many perspectives. They are
examples of the behaviour described in the stories, and they are
examples of the actual code being specified. You can't run specs (can
you?), we don't want to run tests, but we could easily run examples.

> So
> how would we address the two cons? For the RSpec name, we could simply
> change the name of RSpec to something else. For the mismatch with BDD
> lingo, perhaps we could start talking about "Behaviour Driven
> Development by Example"? (We give examples of the software's desired
> behaviour).

I don't think we need to add "by Example" to start using the word.
It's still BDD, and the examples are examples of the B that we use to
D the D.

As for the name - that's tricky. Dan's already got xBehave. Brian's
website is exampleR. Then you have to consider the other languages:

rexample
jexample
and, everyone's favorite....
sexample

you get the idea.

Other ideas?

From luke at agileevolved.com  Thu Aug 10 03:49:47 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 10 Aug 2006 08:49:47 +0100
Subject: [Rspec-devel] Lingo
In-Reply-To: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>
References: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>
Message-ID: <BAC262F0-C03F-481D-846C-A4CD3DF46485@agileevolved.com>

> Here is my take on some of them
>
> == Spec ==
> Pro: Fits well with the RSpec name
> Con: Not so easy to 'talk' about
> Con: Doesn't underline the Behavioural gist of BDD

+1

Whilst I still find myself using the T word out of habit, I'm trying  
to get into the habit of using the word spec - I like it. It goes  
hand in hand with RSpec (which I also like the sound of), I can say  
that I'm "speccing" my code/app and I have no problem with "running  
my specs". It also keeps to the notion of executable specifications.

>
> == Example ==
> Pro: Easy to talk about
> Con: Doesn't fit with the RSpec name
> Con: doesn't fit with BDD lingo

-1

I just don't like the word example used in this context. To me the  
word example has to many other uses/connotations to make it worth  
considering. It sounds silly to me to talk about your code "examples".

>
> == Behaviour ==
> Pro: Fits with the BDD lingo
> Con: May be hard to talk about in some situations / with some people
> Con: Doesn't fit the RSpec name

-1

This is a lot better than example but it doesn't roll off the tongue  
like the word spec does.

I'm certainly not keen on the idea of changing RSpec's name. I like  
the name, I'm always trying to plug it on forums/IRC chat etc. and  
changing the name now would just make the job of promoting RSpec  
harder. It will confuse people who have vaguely heard of RSpec but  
haven't got around to using it yet IMO.

Cheers
Luke


From dchelimsky at gmail.com  Thu Aug 10 04:35:38 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 10 Aug 2006 03:35:38 -0500
Subject: [Rspec-devel] Lingo
In-Reply-To: <BAC262F0-C03F-481D-846C-A4CD3DF46485@agileevolved.com>
References: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>
	<BAC262F0-C03F-481D-846C-A4CD3DF46485@agileevolved.com>
Message-ID: <57c63afe0608100135x3338ccf5yde829a45aa0e0ec7@mail.gmail.com>

On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
> > Here is my take on some of them
> >
> > == Spec ==
> > Pro: Fits well with the RSpec name
> > Con: Not so easy to 'talk' about
> > Con: Doesn't underline the Behavioural gist of BDD
>
> +1
>
> Whilst I still find myself using the T word out of habit, I'm trying
> to get into the habit of using the word spec - I like it. It goes
> hand in hand with RSpec (which I also like the sound of), I can say
> that I'm "speccing" my code/app and I have no problem with "running
> my specs". It also keeps to the notion of executable specifications.

The problem w/ using "spec" is that specifications tend to be more
general, and often supply examples:
===================================
A savings account should apply interest on the last day of the month
based on an average daily balance for that calendar month.

For example, given a savings account with $100 on January 1st, no
additional deposits in January, at an interest rate of 5%, then the
balance should be $100 on January 30th.

Given the same account and the same conditions, the balance should be
$100.42 on January 31st.
===================================
In this case, you couldn't really have an rspec spec/example that
expressed the spec:

context "A savings account" do
  ...
  specify "should apply interest on the last day of the month based on
an average daily balance for that calendar month" do
...

You could, however, expess the individual examples:

context "a savings account with $100 on January 1st, no additional
deposits in January, at an interest rate of 5%" do
  ...
  specify "should have a balance of $100 on Jan 30" do
    ...
  end
  specify "should have a balance of $100.42 on Jan 31" do
    ...
  end
end

That make sense?

> >
> > == Example ==
> > Pro: Easy to talk about
> > Con: Doesn't fit with the RSpec name
> > Con: doesn't fit with BDD lingo
>
> -1
>
> I just don't like the word example used in this context. To me the
> word example has to many other uses/connotations to make it worth
> considering. It sounds silly to me to talk about your code "examples".

This is subjective. For me, "examples" is so general that it really
doesn't carry the same baggage as "spec", "scenario" or "test". I'm
sure we'll find many different opinions on this.

> > == Behaviour ==
> > Pro: Fits with the BDD lingo
> > Con: May be hard to talk about in some situations / with some people
> > Con: Doesn't fit the RSpec name
>
> -1
>
> This is a lot better than example but it doesn't roll off the tongue
> like the word spec does.
>
> I'm certainly not keen on the idea of changing RSpec's name. I like
> the name, I'm always trying to plug it on forums/IRC chat etc. and
> changing the name now would just make the job of promoting RSpec
> harder. It will confuse people who have vaguely heard of RSpec but
> haven't got around to using it yet IMO.

I have mixed feelings about this. On the one hand, I agree that the
name wouldn't need to change regardless of the underlying
nomenclature. We can still talk about rspec as being a tool we use to
express (and automate the execution of) concrete examples of
specifications.

On the other hand, rspec is presented to the world as BDD framework,
but BDD is not about specifications. It's about discovering and
automating the execution of acceptance criteria in the form of
concrete examples of specifications (sound familiar?). It's about
providing a common vocabulary for project owners, developers and
testers. Using this common language, the project owner gets to define
acceptance criteria. Using the same vocabulary, testers then know
precisely what to test and developers know precisely what to develop.

The "it's not about testing" mantra is still true, but only at the
point that you sit down to write some code. When we're using examples
to drive the code, thinking about the behaviour helps us to write more
clear, useful examples and more flexible structures in our code. For
project owners and testers, its still all about testing.

Anyhow, I digress. The point being that perhaps the "spec" in "rspec"
carries the same baggage that "test" in "rtest" might. True, there is
some name recognition as you suggest. It is catchy. And I don't think
we've seen any good alternative candidates yet. On the other hand,
this is still its infancy, and I think it's too early for us to feel
trapped by the name. So I'd like to leave the floor open for
suggestions. We might not come up with anything more suitable. But
then again we might.

Thanks for reading :)
David

From jchris at mfdz.com  Thu Aug 10 13:41:02 2006
From: jchris at mfdz.com (Chris Anderson)
Date: Thu, 10 Aug 2006 10:41:02 -0700
Subject: [Rspec-devel] Given,Then,When
In-Reply-To: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>
References: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>
Message-ID: <e282921e0608101041j188739f7nf2b314d0245051bf@mail.gmail.com>

Specrs,

I haven't been mailing the list much, but I have been using rSpec in
some projects and for fun. Most of the discussion about name-change /
syntax changes has been unexciting to me, but this stuff really seems
to hit the nail on the head. Not only does it clean up the
documentation side of things, if it were implemented correctly it
could cut down on a lot of setup code dupliction. I'm imagining
calling out to shared methods in the "given" blocks, so that common
elements of setup can be shared. I think this works because of the
addition of the "when" block, which really makes clear the event
central to defining the behaviour being focussed on in this "spec".

Granted, there is still more to work out in this syntax (eg multiple
given/when/then blocks to specify a deck of cards, etc.)

Hmm... I'm still liking specify - it connotes writing your specs first.

Alot to think about. My two cents as an rSpec user: I'd just like the
framework to be stable soon. If I were confident that the specs I
write now will be useful for the life of my project, I'd probably stop
using test:unit altogether.

RSpec,
Chris

On 8/9/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> Fellow rspec'ers:
>
> One thing lacking in the current rspec syntax is direct support of the
> BDD triad: Given,When,Then. Right now, rspec supports Given in the
> form of contexts and combines When and Then in specify blocks. This
> lends itself well to structural aspects of the code we're specifying
> (i.e. "A standard deck of cards should have 52 cards", but does not do
> a good job of separating out events (When) from expected outcomes
> (Then).

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

From dastels at daveastels.com  Thu Aug 10 14:42:57 2006
From: dastels at daveastels.com (David Astels)
Date: Thu, 10 Aug 2006 14:42:57 -0400
Subject: [Rspec-devel] Lingo
In-Reply-To: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>
References: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>
Message-ID: <B6BD6F04-3DA7-4305-A986-8D2490A6308F@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 9-Aug-06, at 5:12 PM, aslak hellesoy wrote:

>
> Personally I'm a fan of 'Example'. It's easy to explain to people. So
> how would we address the two cons? For the RSpec name, we could simply
> change the name of RSpec to something else. For the mismatch with BDD
> lingo, perhaps we could start talking about "Behaviour Driven
> Development by Example"? (We give examples of the software's desired
> behaviour).
>
> What do you think folks?

I've been getting more in favour of "example" as time goes on.

Instead of rSpec... hmm... I remember having this discussion at  
Agile'05.  rEx, rExample, exampleR, exR, egR, rEg...

BDD by Example... let's leave that in case Kent gets onboard and  
wants to write a book.

I don't see a big misfit... we write example of the behaviour we want  
to see evidenced.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE234yauez/L4x7g4RAgXuAJ9Im1epdzBCcO/9STOIp4JrGL4GSACfaxzm
IDI+ymIrMdUbqnwd059ZyWo=
=X4W4
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Thu Aug 10 16:42:08 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 10 Aug 2006 15:42:08 -0500
Subject: [Rspec-devel] Lingo
In-Reply-To: <BAC262F0-C03F-481D-846C-A4CD3DF46485@agileevolved.com>
References: <8d961d900608091412h16870f5cy8f3280e77c0fec47@mail.gmail.com>
	<BAC262F0-C03F-481D-846C-A4CD3DF46485@agileevolved.com>
Message-ID: <8d961d900608101342t50107dc9h214d43c114fba02a@mail.gmail.com>

On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
> > Here is my take on some of them
> >
> > == Spec ==
> > Pro: Fits well with the RSpec name
> > Con: Not so easy to 'talk' about
> > Con: Doesn't underline the Behavioural gist of BDD
>
> +1
>
> Whilst I still find myself using the T word out of habit, I'm trying
> to get into the habit of using the word spec - I like it. It goes
> hand in hand with RSpec (which I also like the sound of), I can say
> that I'm "speccing" my code/app and I have no problem with "running
> my specs". It also keeps to the notion of executable specifications.
>

My main gripe with specifications is the formal and general baggage
associated with the word. Almost mathematical proof-like. Design by
Contract is a way to *generally* specify contracts between objects.
It's more formal, and specification seems appropriate for DBC.

Let's assume that in order for something to be a specification, it has
to be general to some extent.

By this assumption I would argue that what we do with xUnit and RSpec
isn't really specifying. We're not stating something that needs to be
generally true. We're only giving descrete examples (hopefully lots of
them) of what it means for the software to be doing what it should.

This is the main reason why I'm starting to prefer example over specification.

> >
> > == Example ==
> > Pro: Easy to talk about
> > Con: Doesn't fit with the RSpec name
> > Con: doesn't fit with BDD lingo
>
> -1
>
> I just don't like the word example used in this context. To me the
> word example has to many other uses/connotations to make it worth
> considering. It sounds silly to me to talk about your code "examples".
>

One of the holy grails of BDD is to bridge the gap between developers,
business analysts, customers and testers by providing a more ubiqutous
language.

If you ask a customer or BA for a specification of what the software
should do, they're likely to come up with an exhaustive list of
acceptance criteria. Sometimes they will even cook up some acceptance
criteria that are so generic that it's hard and error-prone to
translate it into code. Consider the simple example of a Celcius to
Fahrenheit conversion program. If you ask for a specification, you're
likely to just get a mathematical formula. Then it's up to the
developers to translate that into descrete cases (examples) that can
be verified.

This of course is a trivial example, but it illustrates my point of a
disconnect in form of what the customer wants and what the programmers
have to do in order to implement it.

Now consider the situation where you ask the customer/BA for examples
of valid temperature conversions. You're much more likely to get a set
of numbers that you can easily, with less risk of misinterpretation,
translate into code.

I think using example is key to making the requirements people express
what they need in a less ambiguous and easier translateble-to-code
format than if you ask for specs.

> >
> > == Behaviour ==
> > Pro: Fits with the BDD lingo
> > Con: May be hard to talk about in some situations / with some people
> > Con: Doesn't fit the RSpec name
>
> -1
>
> This is a lot better than example but it doesn't roll off the tongue
> like the word spec does.
>

I agree that used alone, it's pretty useless. However, if I ask
someone: "Can you give me some concrete examples of how the system
should behave", you'd be surprised how a lot of miscommunication and
misinterpretation just goes away.

> I'm certainly not keen on the idea of changing RSpec's name. I like
> the name, I'm always trying to plug it on forums/IRC chat etc. and
> changing the name now would just make the job of promoting RSpec
> harder. It will confuse people who have vaguely heard of RSpec but
> haven't got around to using it yet IMO.
>

I don't think we *have* to change the name. With proper documentation
(perhaps a lingo translation cheatsheet) we can get people to use the
words we want. I should stress at this point that we're not trying to
get people to use new words just for the hell of it. We're trying to
change the way people *think* - including the people who define the
behaviour of software. Although I'm not well-read on
http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis I think there is a
lot of truth to it.

And even if we did decide to change RSpec's name to something else I
don't think it would be a big deal. It's still an underdog and there
are plenty of successful name changes (Switchtower => Capistrano is
one of them. EJBDoclet => XDoclet another one, hahaha)

Cheers,
Aslak

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

From luke at agileevolved.com  Thu Aug 10 16:59:34 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 10 Aug 2006 21:59:34 +0100
Subject: [Rspec-devel] RSpec on Rails fubarred on edge rails?
Message-ID: <2BE4F31A-8176-40D4-82B1-EFCD47758B6C@agileevolved.com>

Is anybody else having problems running controller specs with edge  
rails? This is possibly an issue in 1.1.6 but I haven't been able to  
confirm that.

It relates to the deprecation of @params, @session which now throws  
deprecation warnings.

Here's some example output:

@session is deprecated! Call session.inspect instead of  
@session.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@flash is deprecated! Call flash.inspect instead of @flash.inspect.  
Args: [] (inspect_for_expectation_not_met_error at /usr/local/lib/ 
ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
@params is deprecated! Call params.inspect instead of  
@params.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@session is deprecated! Call session.inspect instead of  
@session.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@params is deprecated! Call params.inspect instead of  
@params.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@flash is deprecated! Call flash.inspect instead of @flash.inspect.  
Args: [] (inspect_for_expectation_not_met_error at /usr/local/lib/ 
ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
F at session is deprecated! Call session.inspect instead of  
@session.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@params is deprecated! Call params.inspect instead of  
@params.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@flash is deprecated! Call flash.inspect instead of @flash.inspect.  
Args: [] (inspect_for_expectation_not_met_error at /usr/local/lib/ 
ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
@session is deprecated! Call session.inspect instead of  
@session.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@flash is deprecated! Call flash.inspect instead of @flash.inspect.  
Args: [] (inspect_for_expectation_not_met_error at /usr/local/lib/ 
ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
@params is deprecated! Call params.inspect instead of  
@params.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@session is deprecated! Call session.inspect instead of  
@session.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@params is deprecated! Call params.inspect instead of  
@params.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@flash is deprecated! Call flash.inspect instead of @flash.inspect.  
Args: [] (inspect_for_expectation_not_met_error at /usr/local/lib/ 
ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
@session is deprecated! Call session.inspect instead of  
@session.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@params is deprecated! Call params.inspect instead of  
@params.inspect. Args: [] (inspect_for_expectation_not_met_error at / 
usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
should_base.rb:10)
@flash is deprecated! Call flash.inspect instead of @flash.inspect.  
Args: [] (inspect_for_expectation_not_met_error at /usr/local/lib/ 
ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)

Cheers
Luke

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

From aslak.hellesoy at gmail.com  Thu Aug 10 17:26:54 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 10 Aug 2006 16:26:54 -0500
Subject: [Rspec-devel] RSpec on Rails fubarred on edge rails?
In-Reply-To: <2BE4F31A-8176-40D4-82B1-EFCD47758B6C@agileevolved.com>
References: <2BE4F31A-8176-40D4-82B1-EFCD47758B6C@agileevolved.com>
Message-ID: <8d961d900608101426g7a5132c2wdf42138a6daba766@mail.gmail.com>

It doesn't look like it's fucked up beyond all recognition - this is
just warnings ;-)

In any case - I haven't seen it (yet). I'm not near the rspec code
right now, but have you checked whether your own code uses the
deprecated variables - or if the rspec rails code does?

Aslak

On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
>
> Is anybody else having problems running controller specs with edge rails?
> This is possibly an issue in 1.1.6 but I haven't been able to confirm that.
>
> It relates to the deprecation of @params, @session which now throws
> deprecation warnings.
>
> Here's some example output:
>
> @session is deprecated! Call session.inspect instead of @session.inspect.
> Args: [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @flash is deprecated! Call flash.inspect instead of @flash.inspect. Args: []
> (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @params is deprecated! Call params.inspect instead of @params.inspect. Args:
> [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @session is deprecated! Call session.inspect instead of @session.inspect.
> Args: [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @params is deprecated! Call params.inspect instead of @params.inspect. Args:
> [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @flash is deprecated! Call flash.inspect instead of @flash.inspect. Args: []
> (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> F at session is deprecated! Call session.inspect instead of @session.inspect.
> Args: [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @params is deprecated! Call params.inspect instead of @params.inspect. Args:
> [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @flash is deprecated! Call flash.inspect instead of @flash.inspect. Args: []
> (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @session is deprecated! Call session.inspect instead of @session.inspect.
> Args: [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @flash is deprecated! Call flash.inspect instead of @flash.inspect. Args: []
> (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @params is deprecated! Call params.inspect instead of @params.inspect. Args:
> [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @session is deprecated! Call session.inspect instead of @session.inspect.
> Args: [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @params is deprecated! Call params.inspect instead of @params.inspect. Args:
> [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @flash is deprecated! Call flash.inspect instead of @flash.inspect. Args: []
> (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @session is deprecated! Call session.inspect instead of @session.inspect.
> Args: [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @params is deprecated! Call params.inspect instead of @params.inspect. Args:
> [] (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
> @flash is deprecated! Call flash.inspect instead of @flash.inspect. Args: []
> (inspect_for_expectation_not_met_error at
> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/should_base.rb:10)
>
> Cheers
> Luke
>
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From luke at agileevolved.com  Thu Aug 10 18:04:21 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Thu, 10 Aug 2006 23:04:21 +0100
Subject: [Rspec-devel] RSpec on Rails fubarred on edge rails?
In-Reply-To: <8d961d900608101426g7a5132c2wdf42138a6daba766@mail.gmail.com>
References: <2BE4F31A-8176-40D4-82B1-EFCD47758B6C@agileevolved.com>
	<8d961d900608101426g7a5132c2wdf42138a6daba766@mail.gmail.com>
Message-ID: <38BB4485-8308-4EFB-93FB-81E53EDD1B02@agileevolved.com>

I'm definitely not using them.

Its probably a simple fix so would you like me to submit a patch to  
save some time?

Cheers
Luke

On 10 Aug 2006, at 22:26, aslak hellesoy wrote:

> It doesn't look like it's fucked up beyond all recognition - this is
> just warnings ;-)
>
> In any case - I haven't seen it (yet). I'm not near the rspec code
> right now, but have you checked whether your own code uses the
> deprecated variables - or if the rspec rails code does?
>
> Aslak
>
> On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
>>
>> Is anybody else having problems running controller specs with edge  
>> rails?
>> This is possibly an issue in 1.1.6 but I haven't been able to  
>> confirm that.
>>
>> It relates to the deprecation of @params, @session which now throws
>> deprecation warnings.
>>
>> Here's some example output:
>>
>> @session is deprecated! Call session.inspect instead of  
>> @session.inspect.
>> Args: [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @flash is deprecated! Call flash.inspect instead of  
>> @flash.inspect. Args: []
>> (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @params is deprecated! Call params.inspect instead of  
>> @params.inspect. Args:
>> [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @session is deprecated! Call session.inspect instead of  
>> @session.inspect.
>> Args: [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @params is deprecated! Call params.inspect instead of  
>> @params.inspect. Args:
>> [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @flash is deprecated! Call flash.inspect instead of  
>> @flash.inspect. Args: []
>> (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> F at session is deprecated! Call session.inspect instead of  
>> @session.inspect.
>> Args: [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @params is deprecated! Call params.inspect instead of  
>> @params.inspect. Args:
>> [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @flash is deprecated! Call flash.inspect instead of  
>> @flash.inspect. Args: []
>> (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @session is deprecated! Call session.inspect instead of  
>> @session.inspect.
>> Args: [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @flash is deprecated! Call flash.inspect instead of  
>> @flash.inspect. Args: []
>> (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @params is deprecated! Call params.inspect instead of  
>> @params.inspect. Args:
>> [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @session is deprecated! Call session.inspect instead of  
>> @session.inspect.
>> Args: [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @params is deprecated! Call params.inspect instead of  
>> @params.inspect. Args:
>> [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @flash is deprecated! Call flash.inspect instead of  
>> @flash.inspect. Args: []
>> (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @session is deprecated! Call session.inspect instead of  
>> @session.inspect.
>> Args: [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @params is deprecated! Call params.inspect instead of  
>> @params.inspect. Args:
>> [] (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>> @flash is deprecated! Call flash.inspect instead of  
>> @flash.inspect. Args: []
>> (inspect_for_expectation_not_met_error at
>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/ 
>> should_base.rb:10)
>>
>> Cheers
>> Luke
>>
>>
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Thu Aug 10 18:23:33 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 10 Aug 2006 17:23:33 -0500
Subject: [Rspec-devel] RSpec on Rails fubarred on edge rails?
In-Reply-To: <38BB4485-8308-4EFB-93FB-81E53EDD1B02@agileevolved.com>
References: <2BE4F31A-8176-40D4-82B1-EFCD47758B6C@agileevolved.com>
	<8d961d900608101426g7a5132c2wdf42138a6daba766@mail.gmail.com>
	<38BB4485-8308-4EFB-93FB-81E53EDD1B02@agileevolved.com>
Message-ID: <8d961d900608101523n2ccb8dcdv25f70b58be6b01ef@mail.gmail.com>

On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
> I'm definitely not using them.
>
> Its probably a simple fix so would you like me to submit a patch to
> save some time?
>

Yes please :-)

Aslak

> Cheers
> Luke
>
> On 10 Aug 2006, at 22:26, aslak hellesoy wrote:
>
> > It doesn't look like it's fucked up beyond all recognition - this is
> > just warnings ;-)
> >
> > In any case - I haven't seen it (yet). I'm not near the rspec code
> > right now, but have you checked whether your own code uses the
> > deprecated variables - or if the rspec rails code does?
> >
> > Aslak
> >
> > On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
> >>
> >> Is anybody else having problems running controller specs with edge
> >> rails?
> >> This is possibly an issue in 1.1.6 but I haven't been able to
> >> confirm that.
> >>
> >> It relates to the deprecation of @params, @session which now throws
> >> deprecation warnings.
> >>
> >> Here's some example output:
> >>
> >> @session is deprecated! Call session.inspect instead of
> >> @session.inspect.
> >> Args: [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @flash is deprecated! Call flash.inspect instead of
> >> @flash.inspect. Args: []
> >> (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @params is deprecated! Call params.inspect instead of
> >> @params.inspect. Args:
> >> [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @session is deprecated! Call session.inspect instead of
> >> @session.inspect.
> >> Args: [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @params is deprecated! Call params.inspect instead of
> >> @params.inspect. Args:
> >> [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @flash is deprecated! Call flash.inspect instead of
> >> @flash.inspect. Args: []
> >> (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> F at session is deprecated! Call session.inspect instead of
> >> @session.inspect.
> >> Args: [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @params is deprecated! Call params.inspect instead of
> >> @params.inspect. Args:
> >> [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @flash is deprecated! Call flash.inspect instead of
> >> @flash.inspect. Args: []
> >> (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @session is deprecated! Call session.inspect instead of
> >> @session.inspect.
> >> Args: [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @flash is deprecated! Call flash.inspect instead of
> >> @flash.inspect. Args: []
> >> (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @params is deprecated! Call params.inspect instead of
> >> @params.inspect. Args:
> >> [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @session is deprecated! Call session.inspect instead of
> >> @session.inspect.
> >> Args: [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @params is deprecated! Call params.inspect instead of
> >> @params.inspect. Args:
> >> [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @flash is deprecated! Call flash.inspect instead of
> >> @flash.inspect. Args: []
> >> (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @session is deprecated! Call session.inspect instead of
> >> @session.inspect.
> >> Args: [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @params is deprecated! Call params.inspect instead of
> >> @params.inspect. Args:
> >> [] (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >> @flash is deprecated! Call flash.inspect instead of
> >> @flash.inspect. Args: []
> >> (inspect_for_expectation_not_met_error at
> >> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
> >> should_base.rb:10)
> >>
> >> Cheers
> >> Luke
> >>
> >>
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From lachiec at gmail.com  Thu Aug 10 19:37:28 2006
From: lachiec at gmail.com (Lachie)
Date: Fri, 11 Aug 2006 09:37:28 +1000
Subject: [Rspec-devel] Given,Then,When
In-Reply-To: <e282921e0608101041j188739f7nf2b314d0245051bf@mail.gmail.com>
References: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>
	<e282921e0608101041j188739f7nf2b314d0245051bf@mail.gmail.com>
Message-ID: <2c5e719e0608101637j723dc618u10ca65b0ed6aa222@mail.gmail.com>

> My two cents as an rSpec user: I'd just like the
> framework to be stable soon. If I were confident that the specs I
> write now will be useful for the life of my project, I'd probably stop
> using test:unit altogether.

+1000
For example, dropping dots between releases is a huge pain for me. In
our current project I chose dots because of the uncertainty of using
underscores in rails. Now there's 279/453 expectations to fix :(

Sorry, its turned into something of a rant.

I have the freedom to use whatever I want, but I'm trying to drag
others along who are resistant to BDD (or even TDD). Although I
understand the reason behind things changing (and the pain of
premature legacy), the changes seems arbitrary to these people. The
dragging is becoming more and more difficult with each change to
RSpec.

Perhaps the core guys should bite the bullet and plan a 1.0 roadmap.
Although I'm really interested in where RSpec will end up, the main
thing I use it for is as a Test::Unit replacement. Its a means to an
end at my 9-5 job, producing apps entirely orthogonal to RSpec and its
philosophy.

RSpec is in use *as is*, and its making many people happier. In other
words, it may not yet have achieved BDD nirvana, but its already
playing a very important role as exists now.

The thing is, RSpec is so much better and more rubyish that I could
see it replacing test::unit as the xDD of choice for ruby apps -- but
it would need some stabilisation and some Rails-style marketing.

What about providing new functionality/facilities without removing the
existing ones?
The Given,When,Then stuff sounds great, but if specify just becomes
"unsupported" like dots, I will cry.

I realise that accruing legacy cruft is something you want to avoid
this early. Perhaps if you worked towards a 1.0, it would give us
users the stability we want, while giving you a place to experiment
with future directions (2.x), backporting when appropriate.

sorry again for the frustration apparent in this post...
I really do love RSpec and thank you all for the work you've done on it :)

Lachie

From aschur1 at telus.net  Thu Aug 10 23:33:18 2006
From: aschur1 at telus.net (Alvin Schur)
Date: Thu, 10 Aug 2006 21:33:18 -0600
Subject: [Rspec-devel] Given,Then,When
In-Reply-To: <e282921e0608101041j188739f7nf2b314d0245051bf@mail.gmail.com>
References: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>
	<e282921e0608101041j188739f7nf2b314d0245051bf@mail.gmail.com>
Message-ID: <200608102133.18976.aschur1@telus.net>

Is it reasonable to say that the Given, Then, When is able to describe 
everything we need?

Is it reasonable to say that Context, Specify is able to describe everything 
we need?

If not, will rSpec allow users to define their own terminology suitable for 
their domain?

Is internationalization allowed?

contexte, specifique; and if I could find the accent aigu it would look like 
French.

Changing terminology from "test" to "specification" changes thought processes, 
but does it change the underlying semantics or implementation?

Thanks,
Alvin.

On Thursday 10 August 2006 11:41, Chris Anderson wrote:
> Specrs,
>
> I haven't been mailing the list much, but I have been using rSpec in
> some projects and for fun. Most of the discussion about name-change /
> syntax changes has been unexciting to me, but this stuff really seems
> to hit the nail on the head. Not only does it clean up the
> documentation side of things, if it were implemented correctly it
> could cut down on a lot of setup code dupliction. I'm imagining
> calling out to shared methods in the "given" blocks, so that common
> elements of setup can be shared. I think this works because of the
> addition of the "when" block, which really makes clear the event
> central to defining the behaviour being focussed on in this "spec".
>
> Granted, there is still more to work out in this syntax (eg multiple
> given/when/then blocks to specify a deck of cards, etc.)
>
> Hmm... I'm still liking specify - it connotes writing your specs first.
>
> Alot to think about. My two cents as an rSpec user: I'd just like the
> framework to be stable soon. If I were confident that the specs I
> write now will be useful for the life of my project, I'd probably stop
> using test:unit altogether.
>
> RSpec,
> Chris
>
> On 8/9/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > Fellow rspec'ers:
> >
> > One thing lacking in the current rspec syntax is direct support of the
> > BDD triad: Given,When,Then. Right now, rspec supports Given in the
> > form of contexts and combines When and Then in specify blocks. This
> > lends itself well to structural aspects of the code we're specifying
> > (i.e. "A standard deck of cards should have 52 cards", but does not do
> > a good job of separating out events (When) from expected outcomes
> > (Then).

From dchelimsky at gmail.com  Thu Aug 10 23:48:56 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Thu, 10 Aug 2006 22:48:56 -0500
Subject: [Rspec-devel] Given,Then,When
In-Reply-To: <2c5e719e0608101637j723dc618u10ca65b0ed6aa222@mail.gmail.com>
References: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>
	<e282921e0608101041j188739f7nf2b314d0245051bf@mail.gmail.com>
	<2c5e719e0608101637j723dc618u10ca65b0ed6aa222@mail.gmail.com>
Message-ID: <57c63afe0608102048k39a9de17k667d77a66591596e@mail.gmail.com>

On 8/10/06, Lachie <lachiec at gmail.com> wrote:
> > My two cents as an rSpec user: I'd just like the
> > framework to be stable soon. If I were confident that the specs I
> > write now will be useful for the life of my project, I'd probably stop
> > using test:unit altogether.
>
> +1000
> For example, dropping dots between releases is a huge pain for me. In
> our current project I chose dots because of the uncertainty of using
> underscores in rails. Now there's 279/453 expectations to fix :(

While I appreciate your frustration, this was going to happen sooner
or later. Users have overwhelmingly expressed a preference for
underscores. Removing support for dots helped us move towards a
smaller and cleaner code base.

>
> Sorry, its turned into something of a rant.

It happens. ;)

>
> I have the freedom to use whatever I want, but I'm trying to drag
> others along who are resistant to BDD (or even TDD). Although I
> understand the reason behind things changing (and the pain of
> premature legacy), the changes seems arbitrary to these people. The
> dragging is becoming more and more difficult with each change to
> RSpec.

I like your use of "premature legacy".

I can assure you that we have no intention of flipping things around
all the time. We, too, want to stabilize the API, but we want to do it
in a way that is consistent w/ a long term vision.

> Perhaps the core guys should bite the bullet and plan a 1.0 roadmap.

That's a good idea. I can tell you that we're all quite busy right
now, so it's going to be a few weeks before we can even really discuss
what that means in detail. Please bear with us.

> Although I'm really interested in where RSpec will end up, the main
> thing I use it for is as a Test::Unit replacement. Its a means to an
> end at my 9-5 job, producing apps entirely orthogonal to RSpec and its
> philosophy.
>
> RSpec is in use *as is*, and its making many people happier. In other
> words, it may not yet have achieved BDD nirvana, but its already
> playing a very important role as exists now.

That's great to hear, and something we'll definitely consider as we
press forward.

>
> The thing is, RSpec is so much better and more rubyish that I could
> see it replacing test::unit as the xDD of choice for ruby apps -- but
> it would need some stabilisation and some Rails-style marketing.
>
> What about providing new functionality/facilities without removing the
> existing ones?
> The Given,When,Then stuff sounds great, but if specify just becomes
> "unsupported" like dots, I will cry.

We can't let that happen without at least supplying some tissues.

One thing I've been thinking about is separating out the different
APIs so people can use them in different contexts. For example, the
expectation API could be its own gem, and then you could use it with
test/unit if you wanted to.

With that in mind, perhaps there is a spec API that lives on
separately from the Given/Then/When API. I'm not sure what that looks
like yet, so give it time. Let's just say for now that your concern is
duly noted and won't be disregarded.

>
> I realise that accruing legacy cruft is something you want to avoid
> this early. Perhaps if you worked towards a 1.0, it would give us
> users the stability we want, while giving you a place to experiment
> with future directions (2.x), backporting when appropriate.
>
> sorry again for the frustration apparent in this post...
> I really do love RSpec and thank you all for the work you've done on it :)

Thanks for saying so, and thanks for your contributions.

Cheers,
David

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

From luke at agileevolved.com  Fri Aug 11 05:47:36 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Fri, 11 Aug 2006 10:47:36 +0100
Subject: [Rspec-devel] RSpec on Rails fubarred on edge rails?
In-Reply-To: <8d961d900608101523n2ccb8dcdv25f70b58be6b01ef@mail.gmail.com>
References: <2BE4F31A-8176-40D4-82B1-EFCD47758B6C@agileevolved.com>
	<8d961d900608101426g7a5132c2wdf42138a6daba766@mail.gmail.com>
	<38BB4485-8308-4EFB-93FB-81E53EDD1B02@agileevolved.com>
	<8d961d900608101523n2ccb8dcdv25f70b58be6b01ef@mail.gmail.com>
Message-ID: <7FD50136-C49A-4C8F-A065-4C7D4E9E5B27@agileevolved.com>

As ever with these things it wasn't as simple as I first thought and  
I just can't track this one down.

I'm not sure if the problem is with rspec or the rails plugin.

Sorry I couldn't be of more help!

Luke Redpath
Senior Software Engineer

Agile Evolved Limited

On 10 Aug 2006, at 23:23, aslak hellesoy wrote:

> On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
>> I'm definitely not using them.
>>
>> Its probably a simple fix so would you like me to submit a patch to
>> save some time?
>>
>
> Yes please :-)
>
> Aslak
>
>> Cheers
>> Luke
>>
>> On 10 Aug 2006, at 22:26, aslak hellesoy wrote:
>>
>>> It doesn't look like it's fucked up beyond all recognition - this is
>>> just warnings ;-)
>>>
>>> In any case - I haven't seen it (yet). I'm not near the rspec code
>>> right now, but have you checked whether your own code uses the
>>> deprecated variables - or if the rspec rails code does?
>>>
>>> Aslak
>>>
>>> On 8/10/06, Luke Redpath <luke at agileevolved.com> wrote:
>>>>
>>>> Is anybody else having problems running controller specs with edge
>>>> rails?
>>>> This is possibly an issue in 1.1.6 but I haven't been able to
>>>> confirm that.
>>>>
>>>> It relates to the deprecation of @params, @session which now throws
>>>> deprecation warnings.
>>>>
>>>> Here's some example output:
>>>>
>>>> @session is deprecated! Call session.inspect instead of
>>>> @session.inspect.
>>>> Args: [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @flash is deprecated! Call flash.inspect instead of
>>>> @flash.inspect. Args: []
>>>> (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @params is deprecated! Call params.inspect instead of
>>>> @params.inspect. Args:
>>>> [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @session is deprecated! Call session.inspect instead of
>>>> @session.inspect.
>>>> Args: [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @params is deprecated! Call params.inspect instead of
>>>> @params.inspect. Args:
>>>> [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @flash is deprecated! Call flash.inspect instead of
>>>> @flash.inspect. Args: []
>>>> (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> F at session is deprecated! Call session.inspect instead of
>>>> @session.inspect.
>>>> Args: [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @params is deprecated! Call params.inspect instead of
>>>> @params.inspect. Args:
>>>> [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @flash is deprecated! Call flash.inspect instead of
>>>> @flash.inspect. Args: []
>>>> (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @session is deprecated! Call session.inspect instead of
>>>> @session.inspect.
>>>> Args: [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @flash is deprecated! Call flash.inspect instead of
>>>> @flash.inspect. Args: []
>>>> (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @params is deprecated! Call params.inspect instead of
>>>> @params.inspect. Args:
>>>> [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @session is deprecated! Call session.inspect instead of
>>>> @session.inspect.
>>>> Args: [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @params is deprecated! Call params.inspect instead of
>>>> @params.inspect. Args:
>>>> [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @flash is deprecated! Call flash.inspect instead of
>>>> @flash.inspect. Args: []
>>>> (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @session is deprecated! Call session.inspect instead of
>>>> @session.inspect.
>>>> Args: [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @params is deprecated! Call params.inspect instead of
>>>> @params.inspect. Args:
>>>> [] (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>> @flash is deprecated! Call flash.inspect instead of
>>>> @flash.inspect. Args: []
>>>> (inspect_for_expectation_not_met_error at
>>>> /usr/local/lib/ruby/gems/1.8/gems/rspec-0.5.16/lib/spec/api/helper/
>>>> should_base.rb:10)
>>>>
>>>> Cheers
>>>> Luke
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

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

From aslak.hellesoy at gmail.com  Fri Aug 11 09:08:08 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 11 Aug 2006 08:08:08 -0500
Subject: [Rspec-devel] Given,Then,When
In-Reply-To: <200608102133.18976.aschur1@telus.net>
References: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>
	<e282921e0608101041j188739f7nf2b314d0245051bf@mail.gmail.com>
	<200608102133.18976.aschur1@telus.net>
Message-ID: <8d961d900608110608g5680331eo997cbda68a340136@mail.gmail.com>

On 8/10/06, Alvin Schur <aschur1 at telus.net> wrote:
> Is it reasonable to say that the Given, Then, When is able to describe
> everything we need?
>

It's Given When Then. (Given, Then, When is David's fault ;-)

The GWT format started as a general format for User Story acceptance
criteria (used by agile teams). -Written on 3x5 index cards and put on
an story wall. It's great for this purpose because it's terse and very
precise.

In the spirit of the ubiqutous language idea from Eric Evans' Domain
Driven Design book, early BDDers experimented with adopting this
format in code. See http://jbehave.codehaus.org/ In JBehave, Given
When Then are first class constructs.

> Is it reasonable to say that Context, Specify is able to describe everything
> we need?
>

Perhaps. But we're not only trying to describe everything we need.

We're also trying to get customers, business analysts, testers and
programmers to speak the same language.

User Story acceptance criteria usually get translated into
tests/specs. Context/Specify is not a format that is well suited for
User Story acceptance criteria, and this is the main reason we're
exploring other alternatives/words. We don't want to do the
translation because it's error prone and time consuming.

Whatever we end up with, we'll try very hard to make the
context/specify style be backwards compatible.

> If not, will rSpec allow users to define their own terminology suitable for
> their domain?
>

Sure! It's Ruby. Just put a require 'spec_helper' in the top of your
spec, and monkey-patch or alias the methods you want.

> Is internationalization allowed?
>
> contexte, specifique; and if I could find the accent aigu it would look like
> French.
>

Malheureusement pas. Inside RSpec, context and specify are method
definitions, and Ruby doesn't allow accents here.

> Changing terminology from "test" to "specification" changes thought processes,
> but does it change the underlying semantics or implementation?
>

Implementation of what? RSpec never used "test"

Cheers,
Aslak

> Thanks,
> Alvin.
>
> On Thursday 10 August 2006 11:41, Chris Anderson wrote:
> > Specrs,
> >
> > I haven't been mailing the list much, but I have been using rSpec in
> > some projects and for fun. Most of the discussion about name-change /
> > syntax changes has been unexciting to me, but this stuff really seems
> > to hit the nail on the head. Not only does it clean up the
> > documentation side of things, if it were implemented correctly it
> > could cut down on a lot of setup code dupliction. I'm imagining
> > calling out to shared methods in the "given" blocks, so that common
> > elements of setup can be shared. I think this works because of the
> > addition of the "when" block, which really makes clear the event
> > central to defining the behaviour being focussed on in this "spec".
> >
> > Granted, there is still more to work out in this syntax (eg multiple
> > given/when/then blocks to specify a deck of cards, etc.)
> >
> > Hmm... I'm still liking specify - it connotes writing your specs first.
> >
> > Alot to think about. My two cents as an rSpec user: I'd just like the
> > framework to be stable soon. If I were confident that the specs I
> > write now will be useful for the life of my project, I'd probably stop
> > using test:unit altogether.
> >
> > RSpec,
> > Chris
> >
> > On 8/9/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > Fellow rspec'ers:
> > >
> > > One thing lacking in the current rspec syntax is direct support of the
> > > BDD triad: Given,When,Then. Right now, rspec supports Given in the
> > > form of contexts and combines When and Then in specify blocks. This
> > > lends itself well to structural aspects of the code we're specifying
> > > (i.e. "A standard deck of cards should have 52 cards", but does not do
> > > a good job of separating out events (When) from expected outcomes
> > > (Then).
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From nyarly-rspec at redfivellc.com  Fri Aug 11 18:08:45 2006
From: nyarly-rspec at redfivellc.com (Judson Lester)
Date: Fri, 11 Aug 2006 15:08:45 -0700
Subject: [Rspec-devel] Skeleton Generator
Message-ID: <44DCFFED.7010207@redfivellc.com>

I've been taking small steps into using rspec recently and have been
much enjoying it as an alternative to Test::Unit.  Rake integration is
certainly a nice feature.

What I'd been considering working on under Test::Unit (and was dissuaded
by it's byzantine internals) was a skeleton code generation tool.  Short
form: write your specs with the knowledge that they'll fail.  The spec
runner catches NameError and NoMethodError and starts constructing the
basic skeleton of actual classes, until specs fail for other reasons.

The driving motivation here is the same as automated testing: the easier
it is to do, the more I'll do it.  And if I can get the class and method
definitions started for the price of writing starter specs, not only is
it easier (because I cut out the "write the class defs to that the test
doesn't fail there" steps) , but I actually get work done for me.  Time
profit!

Now, I anticipate that there'll be a bunch of spongy problems to solve
in attempting this, but the reason I post the idea here is: is this
something the the larger community would be interested in, and might it
have a home in rspec eventually?

Judson




From srbaker at pobox.com  Fri Aug 11 18:40:38 2006
From: srbaker at pobox.com (Steven R. Baker)
Date: Fri, 11 Aug 2006 18:40:38 -0400
Subject: [Rspec-devel] Skeleton Generator
In-Reply-To: <44DCFFED.7010207@redfivellc.com>
References: <44DCFFED.7010207@redfivellc.com>
Message-ID: <FDFA3642-C926-4193-889A-17F415963471@pobox.com>

> What I'd been considering working on under Test::Unit (and was  
> dissuaded
> by it's byzantine internals) was a skeleton code generation tool.   
> Short
> form: write your specs with the knowledge that they'll fail.  The spec
> runner catches NameError and NoMethodError and starts constructing the
> basic skeleton of actual classes, until specs fail for other reasons.

I think a tool to do this for Test::Unit is already in ZenTest.  I  
know there's one that goes the other way.

> The driving motivation here is the same as automated testing: the  
> easier
> it is to do, the more I'll do it.  And if I can get the class and  
> method
> definitions started for the price of writing starter specs, not  
> only is
> it easier (because I cut out the "write the class defs to that the  
> test
> doesn't fail there" steps) , but I actually get work done for me.   
> Time
> profit!
>
> Now, I anticipate that there'll be a bunch of spongy problems to solve
> in attempting this, but the reason I post the idea here is: is this
> something the the larger community would be interested in, and  
> might it
> have a home in rspec eventually?

This is probably a desirable feature for many would-be users, but it  
really defeats the purpose of what we're trying to do.  It removes  
the "Driven" part.  If you're writing more than one spec/example/ 
behaviour at a time, then you're writing code to make more than one  
pass.

-Steven




From nyarly-rspec at redfivellc.com  Fri Aug 11 19:30:58 2006
From: nyarly-rspec at redfivellc.com (Judson Lester)
Date: Fri, 11 Aug 2006 16:30:58 -0700
Subject: [Rspec-devel] Skeleton Generator
In-Reply-To: <FDFA3642-C926-4193-889A-17F415963471@pobox.com>
References: <44DCFFED.7010207@redfivellc.com>
	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>
Message-ID: <44DD1332.1060701@redfivellc.com>

Steven R. Baker wrote:
>> What I'd been considering working on under Test::Unit (and was  
>> dissuaded
>> by it's byzantine internals) was a skeleton code generation tool.   
>> Short
>> form: write your specs with the knowledge that they'll fail.  The spec
>> runner catches NameError and NoMethodError and starts constructing the
>> basic skeleton of actual classes, until specs fail for other reasons.
>>     
>
> I think a tool to do this for Test::Unit is already in ZenTest.  I  
> know there's one that goes the other way.
On reflection, I'm sure there is.  In fact, zentest takes a switch to do
the generation.  The basic difference between ZenTest and what I'm
considering is this: ZenTest essentially performs a textual conversion
between TestClass names and Class names.  So TestA::TestB#test_amethod
<=> A::B#amethod.  Which is fine, as far as it goes.
>> The driving motivation here is the same as automated testing: the  
>> easier
>> it is to do, the more I'll do it.  And if I can get the class and  
>> method
>> definitions started for the price of writing starter specs, not  
>> only is
>> it easier (because I cut out the "write the class defs to that the  
>> test
>> doesn't fail there" steps) , but I actually get work done for me.   
>> Time
>> profit!
>>
>> Now, I anticipate that there'll be a bunch of spongy problems to solve
>> in attempting this, but the reason I post the idea here is: is this
>> something the the larger community would be interested in, and  
>> might it
>> have a home in rspec eventually?
>>     
>
> This is probably a desirable feature for many would-be users, but it  
> really defeats the purpose of what we're trying to do.  It removes  
> the "Driven" part.  If you're writing more than one spec/example/ 
> behaviour at a time, then you're writing code to make more than one  
> pass.
>   
Perhaps there's a philosophical point I'm missing, and it would probably
be enlightening to me (and maybe others) if you could show me where I'm
going wrong.  Let me make an example:

I write the following:

context "A fresh pack of cards" do
  setup do
    @deck = Deck.new(52)
  end
  specify "should be shuffleable" do
    @deck.shuffle
  end
end

And the following is generated:

class Deck
  def initialize(number)
  end

  def shuffle
  end
end

Now I can review the generated code, and then add specify blocks to my
spec file in order  to drive development.

What purpose does this defeat?

Judson

From srbaker at pobox.com  Fri Aug 11 20:02:29 2006
From: srbaker at pobox.com (Steven R. Baker)
Date: Fri, 11 Aug 2006 20:02:29 -0400
Subject: [Rspec-devel] Skeleton Generator
In-Reply-To: <44DD1332.1060701@redfivellc.com>
References: <44DCFFED.7010207@redfivellc.com>
	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>
	<44DD1332.1060701@redfivellc.com>
Message-ID: <D7467369-3B2C-4E28-8D68-2F3A5D339624@pobox.com>

[snip]
> And the following is generated:
>
> class Deck
>   def initialize(number)
>   end
>
>   def shuffle
>   end
> end
>
> Now I can review the generated code, and then add specify blocks to my
> spec file in order  to drive development.

Realistically, if you can't type a method definition or two quicker  
than you can run the generator, you should probably find a new  
career. ;)  Hell, Emacs, TextMate, and VIM will all generate the  
class...end and def...end for you, so you only have to type method  
*names*.

In this example, it may be slightly useful.  But if this tool exists,  
people are going to run it on much bigger specs.  And then we're back  
at zero.

-Steven


From dastels at daveastels.com  Fri Aug 11 20:42:42 2006
From: dastels at daveastels.com (David Astels)
Date: Fri, 11 Aug 2006 21:42:42 -0300
Subject: [Rspec-devel] Skeleton Generator
In-Reply-To: <44DD1332.1060701@redfivellc.com>
References: <44DCFFED.7010207@redfivellc.com>
	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>
	<44DD1332.1060701@redfivellc.com>
Message-ID: <C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 11-Aug-06, at 8:30 PM, Judson Lester wrote:

>>
> Perhaps there's a philosophical point I'm missing, and it would  
> probably
> be enlightening to me (and maybe others) if you could show me where  
> I'm
> going wrong.  Let me make an example:
>
> I write the following:
>
> context "A fresh pack of cards" do
>   setup do
>     @deck = Deck.new(52)
>   end
>   specify "should be shuffleable" do
>     @deck.shuffle
>   end
> end

First of all, this makes no statement about behaviour.  All that it  
is doing is sending the "shuffle" message to @deck.  No behaviour is  
being specified.  What is the result or side-effect of Deck.shuffle?

Also, nothing is said about the purpose/meaning/value of the argument  
to Deck.new.  What happens for Deck.new(0)?  Deck.new(104)?

>
> And the following is generated:
>
> class Deck
>   def initialize(number)
>   end
>
>   def shuffle
>   end
> end
>
> Now I can review the generated code, and then add specify blocks to my
> spec file in order  to drive development.
>
> What purpose does this defeat?

There is no failing specification/example/test/anything, therefore  
there should be no code.  The whole idea is that you write a tiny bit  
of spec... just enough to fail because the required behaviour does  
not exist.  Then you write just enough code to satisfy the spec that  
is failing.  How is having automated generation of any help?

Dave




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE3SQCauez/L4x7g4RAnGBAJsER52oskVUkpw7hXaSzk51naLo9gCgktXJ
SsHDMGZaElPc4XLtsHnnrjM=
=lRpT
-----END PGP SIGNATURE-----

From nyarly-rspec at redfivellc.com  Mon Aug 14 16:56:51 2006
From: nyarly-rspec at redfivellc.com (Judson Lester)
Date: Mon, 14 Aug 2006 13:56:51 -0700
Subject: [Rspec-devel] Skeleton Generator
In-Reply-To: <C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
Message-ID: <44E0E393.60306@redfivellc.com>

David Astels wrote:
> On 11-Aug-06, at 8:30 PM, Judson Lester wrote:
>   
>> context "A fresh pack of cards" do
>>   setup do
>>     @deck = Deck.new(52)
>>   end
>>   specify "should be shuffleable" do
>>     @deck.shuffle
>>   end
>> end
>>     
>
> First of all, this makes no statement about behaviour.  All that it  
> is doing is sending the "shuffle" message to @deck.  No behaviour is  
> being specified.  What is the result or side-effect of Deck.shuffle?
>
> Also, nothing is said about the purpose/meaning/value of the argument  
> to Deck.new.  What happens for Deck.new(0)?  Deck.new(104)?
>
>   
Fair enough.  I was writing to my concept rather than as a real spec.  
Should have been obvious at the end where against the generated code 
there were no failures.

Swap in this:

  specify "should have 52 cards" do
    @deck.size.should_equal(52)
  end

with a corresponding generated Deck#size method.  Then the result is 
that the code gets generated, and there's a failure, because @deck.size 
doesn't return 52.
> There is no failing specification/example/test/anything, therefore  
> there should be no code.  The whole idea is that you write a tiny bit  
> of spec... just enough to fail because the required behaviour does  
> not exist.  Then you write just enough code to satisfy the spec that  
> is failing.  How is having automated generation of any help?
>   
There isn't a human-involved iteration of "NoMethodError: size"

There's less room for human error - because you only typed in the method 
name once.  (Granted, there's room for automatic error, if you reference 
a method twice in spec and misspell it the second time...)

Generally, my thought is this is a corollary to the philosophy that 
testing should be as automatic as possible.

Judson

From dastels at daveastels.com  Mon Aug 14 18:37:10 2006
From: dastels at daveastels.com (David Astels)
Date: Mon, 14 Aug 2006 19:37:10 -0300
Subject: [Rspec-devel] Skeleton Generator
In-Reply-To: <44E0E393.60306@redfivellc.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
Message-ID: <F0FE4589-89DE-4802-B230-08502E4CDA1E@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 14-Aug-06, at 5:56 PM, Judson Lester wrote:

>
> Swap in this:
>
>   specify "should have 52 cards" do
>     @deck.size.should_equal(52)
>   end
>
> with a corresponding generated Deck#size method.  Then the result is
> that the code gets generated, and there's a failure, because  
> @deck.size
> doesn't return 52.

Granted this is all out of context....

but is the size of a deck part of it's behaviour.. or just part of  
it's state.  Put another way.. does anyone care that they can ask a  
deck for its size?  Or are they more interested in having hands  
dealt, etc?

> There's less room for human error - because you only typed in the  
> method
> name once.  (Granted, there's room for automatic error, if you  
> reference
> a method twice in spec and misspell it the second time...)

true.  A good IDE would help mitigate that, though.

In all some interesting thoughts.

Dave


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4PsWauez/L4x7g4RApSsAKCCgTmZkmI4rgb/uPzyqE6Waj8YcgCg44ld
XwKZ0zC/yAaNwe/IyN3OwhE=
=Fo2M
-----END PGP SIGNATURE-----

From dastels at daveastels.com  Mon Aug 14 18:40:53 2006
From: dastels at daveastels.com (David Astels)
Date: Mon, 14 Aug 2006 19:40:53 -0300
Subject: [Rspec-devel] I'm back
In-Reply-To: <44E0E393.60306@redfivellc.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
Message-ID: <36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've been rather quiet on here lately... various things have  
distracted me form rspec and ruby/rails.

Various other things have conspired to push me (not completely  
unwillingly) back into the RoR world with a vengeance (funny how part  
ownership in a web 2.0 startup will do that ;) ).

So I'm diving back into my learning of rails, and re-experiencing the  
level of raw productivity.  This time I'm doing it with rspec in hand :)

I expect that I'll come out of this with a rspec on rails tutorial.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4Pv1auez/L4x7g4RAo09AKDd83BBVYoHUFjg0Uh6Zw75yZjX2ACgkiQE
pZzcDSFUkOgY2fscLF7ujyE=
=ZooO
-----END PGP SIGNATURE-----

From dastels at daveastels.com  Mon Aug 14 20:49:40 2006
From: dastels at daveastels.com (David Astels)
Date: Mon, 14 Aug 2006 21:49:40 -0300
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
Message-ID: <6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have the notes finished for an rspec/ruby tutorial.  It will be  
given at SD Best Practices next month in Boston.  I'd appreciate if  
anyone who has some time could have a look at it, maybe even working  
through the exercise, and give me any feedback.  Once I'm happy with  
it, I'll make it publicly available.

It's at

	http://blog.daveastels.com/files/mastermind-ruby.pdf

Dave


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4Rokauez/L4x7g4RAg+MAJ9mQ5N82nVNGI2bA2LTzTSCQdhXGACaAj3u
oMCELZJTixGOIPk5MB2QGi4=
=/be8
-----END PGP SIGNATURE-----

From aschur1 at telus.net  Mon Aug 14 21:58:35 2006
From: aschur1 at telus.net (Alvin Schur)
Date: Mon, 14 Aug 2006 19:58:35 -0600
Subject: [Rspec-devel] Given, When, Then
In-Reply-To: <8d961d900608110608g5680331eo997cbda68a340136@mail.gmail.com>
References: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>
	<200608102133.18976.aschur1@telus.net>
	<8d961d900608110608g5680331eo997cbda68a340136@mail.gmail.com>
Message-ID: <200608141958.36576.aschur1@telus.net>


On Friday 11 August 2006 07:08, aslak hellesoy wrote:
>
> > Is internationalization allowed?
> >
> > contexte, specifique; and if I could find the accent aigu it would look
> > like French.
>
> Malheureusement pas. Inside RSpec, context and specify are method
> definitions, and Ruby doesn't allow accents here.
>
Is it possible to override Kernel::require?

The new implementation of require can convert accents and keywords (then) to 
something more palatable to ruby before passing the file on to the original 
require method.

> > Changing terminology from "test" to "specification" changes thought
> > processes, but does it change the underlying semantics or implementation?
>
> Implementation of what? RSpec never used "test"
I see the difference between TDD and BDD as a change in terminology.  Both 
approaches appear to use the same semantics:

1) prepare the system under test
2) activate the system under test
3) verify facts about the system under test
4) clean up after the system under test

Are there any other semantic descriptions that make sense?

One option suggested on the list was a "story"

1) prepare the system under test
2) activate the system under test
3) verify facts about the system under test
x) repeat 2 and 3 as desired
4) clean up after the system under test

With a separation of terminology (DSL) and semantics perhaps RSpec can have 
plugins for semantics and map terminology to various semantic concepts.

BDD context / specify
setup -> 1
specify -> 2 and 3
teardown -> 4

TDD
setup -> 1
test_ -> 2 and 3
teardown -> 4

BDD given when then
given -> 1
when -> 2
then -> 3
teardown? -> 4

BDD story-arc
prelude/preface/introduction -> 1
episode-> 2
climax -> 3
(repeat above as desired)
epilogue / denouement -> 4


Alvin.

From aslak.hellesoy at gmail.com  Tue Aug 15 00:48:14 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 14 Aug 2006 23:48:14 -0500
Subject: [Rspec-devel] Given, When, Then
In-Reply-To: <200608141958.36576.aschur1@telus.net>
References: <57c63afe0608090728h57667c42qfdb6712a5c8eb117@mail.gmail.com>
	<200608102133.18976.aschur1@telus.net>
	<8d961d900608110608g5680331eo997cbda68a340136@mail.gmail.com>
	<200608141958.36576.aschur1@telus.net>
Message-ID: <8d961d900608142148l61e92190p6564156ed1853588@mail.gmail.com>

On 8/14/06, Alvin Schur <aschur1 at telus.net> wrote:
>
> On Friday 11 August 2006 07:08, aslak hellesoy wrote:
> >
> > > Is internationalization allowed?
> > >
> > > contexte, specifique; and if I could find the accent aigu it would look
> > > like French.
> >
> > Malheureusement pas. Inside RSpec, context and specify are method
> > definitions, and Ruby doesn't allow accents here.
> >
> Is it possible to override Kernel::require?
>

Yes

> The new implementation of require can convert accents and keywords (then) to
> something more palatable to ruby before passing the file on to the original
> require method.
>

I have a feeling that's going to be hard, but by all means give it a try.

> > > Changing terminology from "test" to "specification" changes thought
> > > processes, but does it change the underlying semantics or implementation?

The Test::Unit library implementation is completely different from the
RSpec library implementation. -But not directly because of the
terminology changes.

> >
> > Implementation of what? RSpec never used "test"
> I see the difference between TDD and BDD as a change in terminology.  Both
> approaches appear to use the same semantics:
>
> 1) prepare the system under test
> 2) activate the system under test
> 3) verify facts about the system under test
> 4) clean up after the system under test
>
> Are there any other semantic descriptions that make sense?
>
> One option suggested on the list was a "story"
>
> 1) prepare the system under test
> 2) activate the system under test
> 3) verify facts about the system under test
> x) repeat 2 and 3 as desired
> 4) clean up after the system under test
>
> With a separation of terminology (DSL) and semantics perhaps RSpec can have
> plugins for semantics and map terminology to various semantic concepts.
>

?

> BDD context / specify
> setup -> 1
> specify -> 2 and 3
> teardown -> 4
>
> TDD
> setup -> 1
> test_ -> 2 and 3
> teardown -> 4
>
> BDD given when then
> given -> 1
> when -> 2
> then -> 3
> teardown? -> 4
>
> BDD story-arc
> prelude/preface/introduction -> 1
> episode-> 2
> climax -> 3
> (repeat above as desired)
> epilogue / denouement -> 4
>

Sounds very complicated.

Aslak

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

From luke at agileevolved.com  Tue Aug 15 08:41:39 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 15 Aug 2006 13:41:39 +0100
Subject: [Rspec-devel] BDD with Rails, deciding on context boundaries
Message-ID: <DE15BE94-B04A-4E2F-89F5-55608291F568@agileevolved.com>

Hi Everybody

I've been working with RSpec on my latest project and I'm currently  
writing a 5 part article about testing Rails apps properly and I plan  
on mentioning BDD and RSpec. First of all though, I want to clear up  
some of my own confusion. I believe *may* have been focussing on  
testing state in my specs rather than behaviour and I'd like advice  
on how to improve what I'm doing if I am indeed going in the wrong  
direction.

Let me focus on model tests for the moment. Lets take a User model. I  
find that the first few contexts for an ActiveRecord model in Rails  
tend to be the same, generally a "New foo" and a "Saved foo". I try  
to avoid testing built-in AR features such as find/destroy/create as  
this should be covered by AR's own tests. Here's some specs for a  
User model on my current project:

http://svn.lazyatom.com/public/plugin_repository/branches/ 
community_features/spec/models/user_spec.rb

Does this look like the right approach to take? If not how could  
these specs be better - more BDD-like? Instead of this:

context "New user" do
   specify "should not be valid" do
     @user.should_not_be_valid
   end
end

Should I be doing something more like this:

context "New user" do
   specify "should return false when calling valid" do
     @user.should_not_be_valid
   end
end

I guess the main difference between the two is the first looks more  
like a user story whereas the second looks more like an explicit test  
of the code's behaviour (rather than the behaviour of the conceptual  
model itself). Which is more correct?

The next thing I want to discuss is controller specs. First of all, I  
think a Rails controller is far too wide in scope to focus on as a  
whole - its always irked me that Rails' unit test stubs for  
controllers (*ahem* sorry *functional* tests if we believe Rails'  
terminology) generate a stub testcase for the entire controller. I  
instead prefer to concentrate on the individual actions.

So lets take, for example, a UserController#create action. Now how  
can we break this down into contexts? One way of looking at  
controller actions is a conceptual "object" that you send "messages"  
to, like normal objects, except in this case the "object" is really  
just a controller method and the "messages" are HTTP Verbs and  
parameters. So would we split the contexts up by verb? But what about  
different results - a create could be successful or it could fail.  
Where does this fit into things? One way of breaking it up would be  
like this

User creation via GET
- should never create a user
- should flash an "invalid request" message
- should redirect back to the previous page

Successful user creation via POST
- should create a new user
- should flash a success message
- should redirect to the user list page

Failed user creation via POST
- should not create a new user
- should flash an error message
- should redirect back to the new user page

Would this be how you would break it down? Also, do you believe these  
specs are the place to specifiy the behaviour of the resulting view  
as well as the action behaviour? Or should the view behaviours have  
their own specs entirely? Or is test::unit and rspec the wrong place  
to try and test your view output - would an acceptance testing tool  
like selenium or watir be more suited to the task?

Finally, what are your thoughts on simulating the above situations  
like successful/failed creations by stubbing out ActiveRecord methods  
like save() (the Stubba library that comes with Mocha -  
mocha.rubyforge.org - is particularly good at doing this)? I feel  
that by simulating successful/failed requests by passing the  
appropriate parameters, you are coupling your controller tests to  
your model's implementation - i.e. if what makes a model valid  
changes, you also need to change your controller tests, which seems  
like a bad smell to me.

What would be really nice is to use mocks so that your model *and*  
controller tests never touch the database. Believe it or not,  
ActiveRecord doesn't make this easy - ActiveRecord barfs if you send  
it a mock when it expects another ActiveRecord object - it explicitly  
type checks. So much for duck typing!

Thanks for listening to my semi-coherent ramblings!

Cheers
Luke Redpath

From luke at agileevolved.com  Tue Aug 15 09:06:51 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 15 Aug 2006 14:06:51 +0100
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
	<6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
Message-ID: <66655060-012A-42BF-93F8-218BA17A928D@agileevolved.com>

Dave, great tutorial! I'll be sure to mention it in my own  
forthcoming testing rails articles (once its publicly available of  
course).

I haven't gone over it with a fine tooth comb but I did notice one  
small error on page 10, under tallying white pegs:

   setup do
     all_white_code = Mastermind::Code.new(:red, :white, :white, :white)
     all_white_guess = Mastermind::Code.new 
(:black, :black, :black, :red)
     @score = all_white_code.mark(all_white_guess)
   end

The variable names all_white_code and all_white_guess don't make  
sense in this example.

Cheers
Luke

On 15 Aug 2006, at 01:49, David Astels wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have the notes finished for an rspec/ruby tutorial.  It will be
> given at SD Best Practices next month in Boston.  I'd appreciate if
> anyone who has some time could have a look at it, maybe even working
> through the exercise, and give me any feedback.  Once I'm happy with
> it, I'll make it publicly available.
>
> It's at
>
> 	http://blog.daveastels.com/files/mastermind-ruby.pdf
>
> Dave
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
>
> iD8DBQFE4Rokauez/L4x7g4RAg+MAJ9mQ5N82nVNGI2bA2LTzTSCQdhXGACaAj3u
> oMCELZJTixGOIPk5MB2QGi4=
> =/be8
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

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

From aslak.hellesoy at gmail.com  Tue Aug 15 11:09:47 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 15 Aug 2006 10:09:47 -0500
Subject: [Rspec-devel] BDD with Rails, deciding on context boundaries
In-Reply-To: <DE15BE94-B04A-4E2F-89F5-55608291F568@agileevolved.com>
References: <DE15BE94-B04A-4E2F-89F5-55608291F568@agileevolved.com>
Message-ID: <8d961d900608150809y519be1eds24dba3150f1eba58@mail.gmail.com>

On 8/15/06, Luke Redpath <luke at agileevolved.com> wrote:
> Hi Everybody
>
> I've been working with RSpec on my latest project and I'm currently
> writing a 5 part article about testing Rails apps properly and I plan
> on mentioning BDD and RSpec. First of all though, I want to clear up
> some of my own confusion. I believe *may* have been focussing on
> testing state in my specs rather than behaviour and I'd like advice
> on how to improve what I'm doing if I am indeed going in the wrong
> direction.
>

I'm going to suggest some categories to help distinguish between an
object's state and behaviour. (It would be nice to get help to nail
these - I'd like to have it in RSpec's docs)

= State =
* Instance variables (attr_reader)
* Methods that return values without
** modifying internal state
** invoking methods on other objects that may modifying their state
* Methods that modify internal state

= Behaviour =
* Methods that invoke methods on other objects

> Let me focus on model tests for the moment. Lets take a User model. I
> find that the first few contexts for an ActiveRecord model in Rails
> tend to be the same, generally a "New foo" and a "Saved foo". I try
> to avoid testing built-in AR features such as find/destroy/create as
> this should be covered by AR's own tests. Here's some specs for a
> User model on my current project:
>
> http://svn.lazyatom.com/public/plugin_repository/branches/
> community_features/spec/models/user_spec.rb
>
> Does this look like the right approach to take? If not how could
> these specs be better - more BDD-like? Instead of this:
>
> context "New user" do
>    specify "should not be valid" do
>      @user.should_not_be_valid
>    end
> end
>
> Should I be doing something more like this:
>
> context "New user" do
>    specify "should return false when calling valid" do
>      @user.should_not_be_valid
>    end
> end
>

As you're experiencing, the context/specify (CS) style allows for a
lot of different styles (as do xUnit). Since we're still stuck with CS
I think either is fine. Which style is more appropriate is a judgement
call on how complex/intricate your case is. In this case it's rather
simple so I'd prefer the first.

One of the goals of the upcoming? GWT format is to reduce confusion
about format as you describe here. In GWT it might look something
like:

given "A new user" do
  setup do
    @user = User.new
  end

  when "valid is invoked" # When is like a comment, but it would
appear in specdocs
  then "the result is true"
    @user.should_be_valid
  end
end

> I guess the main difference between the two is the first looks more
> like a user story whereas the second looks more like an explicit test
> of the code's behaviour (rather than the behaviour of the conceptual
> model itself). Which is more correct?
>

Like I said above, either is fine to me. Once we get a richer BDD API
you'll have less choices.

Now, regarding whether you're verifying state rather than behaviour.
In this example we're definitely verifying state, not behaviour.
ActiveRecord (as most ORMs) are inherently very state-centric. And the
state centric aspects of AR is - as you mention - tested in AR's own
test suite.

This doesn't mean AR objects can't exibhit additional behaviour
defined by you. I very often find myself refactoring behaviour defined
in controllers into the AR classes themselves. One example would be:

given a saved user with email # known initial state
when the password is changed # event
then a password notification email is sent to the user # expected behaviour

> The next thing I want to discuss is controller specs. First of all, I
> think a Rails controller is far too wide in scope to focus on as a
> whole - its always irked me that Rails' unit test stubs for
> controllers (*ahem* sorry *functional* tests if we believe Rails'
> terminology)

Agree - it's not a 'functional' spec in my book either.

> generate a stub testcase for the entire controller. I
> instead prefer to concentrate on the individual actions.
>
> So lets take, for example, a UserController#create action. Now how
> can we break this down into contexts? One way of looking at
> controller actions is a conceptual "object" that you send "messages"
> to, like normal objects, except in this case the "object" is really
> just a controller method and the "messages" are HTTP Verbs and
> parameters. So would we split the contexts up by verb?

I'm torn here. I *really* want my GWT now! :-)

Since controllers represent the user interface (to some degree) I
would try to write them in a way that could be understood by a user.
Ideally you'd work with the user to write the specs. Example:

given I am on the user signup screen
when I submit an unused user name and password
then I will get confirmation that a new account is created

The verb+params map to a method (event) so I think this is more
related to the 'when'.
But maybe this is more appropriate for the 'integration' specs.

> But what about
> different results - a create could be successful or it could fail.
> Where does this fit into things? One way of breaking it up would be
> like this
>
> User creation via GET
> - should never create a user
> - should flash an "invalid request" message
> - should redirect back to the previous page
>
> Successful user creation via POST
> - should create a new user
> - should flash a success message
> - should redirect to the user list page
>
> Failed user creation via POST
> - should not create a new user
> - should flash an error message
> - should redirect back to the new user page
>

This is how I currently tend to break things down. It does express a
lot of the system's behaviour. The main problem is that it doesn't
necessarily make sense to a non-technical user. Another problem is
that it's somewhat in conflict with what we're trying to achieve with
contexts or 'given' - break things up by initial state.

But in the current incarnation of RSpec I think the way you're doing it is fine.

> Would this be how you would break it down? Also, do you believe these
> specs are the place to specifiy the behaviour of the resulting view
> as well as the action behaviour? Or should the view behaviours have
> their own specs entirely?

If you put on the user hat I think it makes sense to verify the
controller and the view together. Example:

Given I am not logged in # Initial state
When I try to navigate to the user admin section # Controller - invoke
controller method
Then I am told to log in # View - verify the HTML

Now - we're not really verifying the behaviour of the view here -
we're verifying the behaviour of the system - at a higher granularity.
We're just using the view to verify the expected behaviour of the
*system*. Which IMO is pragmatic and fine.

> Or is test::unit and rspec the wrong place
> to try and test your view output - would an acceptance testing tool
> like selenium or watir be more suited to the task?
>

They are not exclusive - they are yin and yang! You can use RSpec (and
Test::Unit for that matter) with both Watir and Selenium remote
control. Here is one of my RSpec/Selenium RC specs (I'm writing an
XP/Scrum story/iteration/planning tool):

context "A running iteration" do
  setup do
    @sel = Selenium::SeleneseInterpreter.new("localhost", 4444,
"*firefox", "http://localhost:3000", 5000)
    @sel.start
  end

  specify "should allow finishing and tag all stages and stories" do
    @sel.open_and_wait "http://localhost:3000/iterations/1"
    # TODO: verify that the iteration is still 'running' (visual clue)
    @sel.click_and_wait "link=Iteration Status"
    @sel.click_and_wait "link=Finish this iteration"
    # TODO: verify that the iteration is 'finished' (visual clue)
  end

  teardown do
    @sel.stop
  end
end

You can do similar things with Watir - it's just a library that lets
you talk to the browser. Stick it in your specs!

I think Watir/Selenium serve the same purpose as Rails integration
tests. I'd use either of them for high level stuff. Which one is more
appropriate is more a question of which one is more suited for you
*technically*.

> Finally, what are your thoughts on simulating the above situations
> like successful/failed creations by stubbing out ActiveRecord methods
> like save() (the Stubba library that comes with Mocha -
> mocha.rubyforge.org - is particularly good at doing this)? I feel
> that by simulating successful/failed requests by passing the
> appropriate parameters, you are coupling your controller tests to
> your model's implementation - i.e. if what makes a model valid
> changes, you also need to change your controller tests, which seems
> like a bad smell to me.
>

Word!

I think that controller 'unit' specs should ideally talk to mock
models. Stubba seems great for this although I haven't tried it. I
know David is experimenting with some similar stuff on on of the RSpec
branches too.

> What would be really nice is to use mocks so that your model *and*
> controller tests never touch the database. Believe it or not,
> ActiveRecord doesn't make this easy - ActiveRecord barfs if you send
> it a mock when it expects another ActiveRecord object - it explicitly
> type checks. So much for duck typing!
>

Controllers should definitely be verifiable without having to talk to
the real models (using RSpec's mocks or Stubba or something).

When it comes to AR - I agree it's a pain to try to divorce it from
the database, but I don't see this as as much of a limitation
(although sometimes it is).

I'm still doing a fair amount of Java using JMock. In my early days of
mocking I tried to mock everything - including the JDBC and servlet
APIs. Until Joe Walnes taught me "only mock your own APIs".

ActiveRecord is where the rubber (your code) hits the road (the
database). If you have model level logic that you want to verify
without a database, consider implementing this in vanilla POROs - not
AR classes. In a running system they would talk to AR models, but yoy
could mock the AR classes (they are your own) when you verify these
'non-persistent' models' behaviour (trying hard to avoid the T word
here hehe).

Of course this has a tradeoff of introducing extra layers - diverging
from the AR pattern and 'behaviour goes with data' OO principles. But
in some cases it makes sense.

> Thanks for listening to my semi-coherent ramblings!
>

Likewise!

Cheers,
Aslak

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

From dominique.plante at gmail.com  Tue Aug 15 17:36:31 2006
From: dominique.plante at gmail.com (Dominique Plante)
Date: Tue, 15 Aug 2006 14:36:31 -0700
Subject: [Rspec-devel] rSpec tutorial
Message-ID: <a4150eba0608151436o2f53f7cet191503d870de6e0b@mail.gmail.com>

Dear Dave:

This is a great tutorial!  I have read it all (and started coding some
of it), and I think it should be easy for most people to follow along.
 I like how you also demonstrate how to use mock, and get a fully
functional app going.  I haven't went through all the code at the
keyboard (yet), but tried to use enough to get me feet wet.

I'd like to mention that I am very excited about  rpsec, I don't
consider myself a ruby expert (by any means), I have seen your
presentation on rspec via google video, and also Steve Baker's talk on
rspec at the Silicon Valley Ruby Conference a while back...

I just thought I'd mention that you can play a game essentially like
Mastermind if you have a personalized google home page - look for the
deduction game when you add content (so people reading article can try
out a similar game).

Depending on who the audience is (or where this appears), you may want
to point people to stuff on CRC cards, where to find rspec, mock
objects etc... (or at least point out that they should have a fairly
good understanding of these things for this tutorial to be useful to
them)

When I tried to get the code going on my machine, I ran into some issues...

I'm on a windows box with ruby at c:\ruby, with ruby -v returning ruby
1.8.4 (2006-04-14) [i386-mswin32]

I installed rspec via gem install rspec (and got version 0.6.0)

I created the root folder for this in a folder e:\ruby\mastermind

>From looking at your command line output I noticed that the specs
should be going into specs (you don't mention this explicitly).

My Ruby isn't very good, so I couldn't put classes in modules and be able to do
require File.dirname(__FILE__) + '/../mastermind'

I did get classes the real classes to be recognized by rspec by
putting them into the same folder as the specs, and not putting in the
module declaration.  You might want to better describe the folder
structure you intended people to use for rubiots like myself.

(very minor) I also noticed that to get an error message on line 4:

NameError in 'An all white code with an all white guess should score 4
black pegs'
uninitialized constant Code
./specs/all_white_code_spec.rb:4:in `setup'
(page 3)

would require there to be no blank lines in the spec file

Finally here are various copy editing comments...

page 2 - (and loosing after 10) should be (and losing after 10)

page 2 - ... seeing how good the guess, is, and reporting back to the user.

could be written as:

.... seeing how good the player's guess is, and reporting the 'marks'
back to him/her.

page 3: in the footnote, used the wrong word 'he src folder' should be
'the src folder'

page 5:
"That could be to refactor to a better design, or to write the next
spec which will
drive us to generalize. In this case, we will do the latter."

could be written as:

"We could either decide to refactor to a better design, or write the
next spec which will drive us to generalize.  In this case, we will
choose the latter option."

page 5:
"See the works of Allen Holub 2 for a great treatment of this topic."

could be written as:

"See the works of Allen Holub 2 for a great treatment on this topic."

page 9:
"i.e. how many pegs in the guess exactly match pegs in the code (I
also cleaned up some
names):"

could be written as:

"i.e. how many pegs in the guess exactly match the color and placement
of the pegs in the code (I also cleaned up some names):"

page 11:
"Now to find pegs of the right colour in the wrong place."

could be written as:

"Now we need to find the pegs that are in the wrong place, but have
the wrong but have the right color."

page 29:
Back to our Regularly Scheduled Develpment

missing o in Development


Hope this helps!
Dominique

-------------------------------------------------------------
dom.website = http://www.binaryshift.com

From dastels at daveastels.com  Tue Aug 15 20:57:22 2006
From: dastels at daveastels.com (David Astels)
Date: Tue, 15 Aug 2006 21:57:22 -0300
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <66655060-012A-42BF-93F8-218BA17A928D@agileevolved.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
	<6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
	<66655060-012A-42BF-93F8-218BA17A928D@agileevolved.com>
Message-ID: <E64BFA4B-F23A-4E99-BC18-9BB0FA2237E7@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15-Aug-06, at 10:06 AM, Luke Redpath wrote:

> Dave, great tutorial! I'll be sure to mention it in my own  
> forthcoming testing rails articles (once its publicly available of  
> course).
>
> I haven't gone over it with a fine tooth comb but I did notice one  
> small error on page 10, under tallying white pegs:
>
>   setup do
>     all_white_code = Mastermind::Code.new 
> (:red, :white, :white, :white)
>     all_white_guess = Mastermind::Code.new 
> (:black, :black, :black, :red)
>     @score = all_white_code.mark(all_white_guess)
>   end
>
> The variable names all_white_code and all_white_guess don't make  
> sense in this example.

Thanks for all the above Luke!

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4m1zauez/L4x7g4RAvv1AJ0VXiFzQ3X7oIkFgchVnU9sFC+xwACgyRQX
Rr6P1XfGmpZ5mi79a5gfl90=
=CsXf
-----END PGP SIGNATURE-----

From dastels at daveastels.com  Tue Aug 15 20:59:13 2006
From: dastels at daveastels.com (David Astels)
Date: Tue, 15 Aug 2006 21:59:13 -0300
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <a4150eba0608151436o2f53f7cet191503d870de6e0b@mail.gmail.com>
References: <a4150eba0608151436o2f53f7cet191503d870de6e0b@mail.gmail.com>
Message-ID: <75B07064-5E98-4319-B40D-F4930C334131@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15-Aug-06, at 6:36 PM, Dominique Plante wrote:

> Dear Dave:
>
> This is a great tutorial!

Thanks

> I'd like to mention that I am very excited about  rpsec

Good to hear

> Depending on who the audience is (or where this appears), you may want
> to point people to stuff on CRC cards, where to find rspec, mock
> objects etc...

Yes, I'll be adding that.

> Hope this helps!

A great deal, thanks for your input.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4m3hauez/L4x7g4RAvhrAJ9zOHyUli/RC8l8VfJp//kFrAaE6QCfaiKL
AC/Le6qmhUzK8jrZU6tX9as=
=DUot
-----END PGP SIGNATURE-----

From dastels at daveastels.com  Tue Aug 15 21:07:07 2006
From: dastels at daveastels.com (David Astels)
Date: Tue, 15 Aug 2006 22:07:07 -0300
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <a4150eba0608151436o2f53f7cet191503d870de6e0b@mail.gmail.com>
References: <a4150eba0608151436o2f53f7cet191503d870de6e0b@mail.gmail.com>
Message-ID: <2D2D84A0-BFC3-4688-A955-93D5C20C46D1@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15-Aug-06, at 6:36 PM, Dominique Plante wrote:

>
> Depending on who the audience is (or where this appears), you may want
> to point people to stuff on CRC cards, where to find rspec, mock
> objects etc...

So what's the recommended way to install Ruby for Windows?  I've only  
ever used it on Linux and OS X.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4m+7auez/L4x7g4RAk73AJoCxbsjGSqwsAZbiCIZT9bthWX7kgCdFxz1
gewZOR6hNqyYJhFHt9XIsqQ=
=+XHB
-----END PGP SIGNATURE-----

From nyarly-rspec at redfivellc.com  Tue Aug 15 21:28:02 2006
From: nyarly-rspec at redfivellc.com (Judson Lester)
Date: Tue, 15 Aug 2006 18:28:02 -0700
Subject: [Rspec-devel] Feature requests
Message-ID: <44E274A2.3040001@redfivellc.com>

I've run into a couple of minor irritations working with rspec recently.

Mostly, I really like working with rspec.  Tidy DSL, good Rake 
integration, built in mocks and coverage are all major boons.  But:

proc.should_raise and should_not_raise both result in printing the 
backtrace of the the RSpec failure they raise, rather than the 
unexpected exception that was raised.  This leads to a fair amount of 
extra dev time spent hunting down the error, where a message along the 
lines of "proc should not have raised, but instead raised:" and the 
whole exception (not the standard Ruby "...400 lines skipped that 
include the line you care about..." :)

Contrarywise, other expectations also print their entire backtrace, 
which is rarely helpful and consumes a fair amount of scrollback and 
attention.

Finally hash.should_has_key(:key) fails (<hash> doesn't respond to has?) 
as do similar predicates (i.e. anything with an underscore). 

It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that 
as an expectation to be called at least 3 times, and warn if they were 
told otherwise - it's certainly not Least Surprise when the class being 
specced against fails because it's getting the wrong result.

Am I the voice in the wilderness here?  I'm more than willing to submit 
patches, if there's some chance they'll be accepted.

Judson

From dastels at daveastels.com  Wed Aug 16 00:33:53 2006
From: dastels at daveastels.com (David Astels)
Date: Wed, 16 Aug 2006 01:33:53 -0300
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
	<6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
Message-ID: <BB7D9B84-8C5F-4BC1-8878-3339FDBC857F@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Updated with the feedback received so far.  Same place:

> 	http://blog.daveastels.com/files/mastermind-ruby.pdf

Dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4qAxauez/L4x7g4RAtDMAKCfiscBZ9lMuVY99IqCA95G/qJDzgCbBeM/
a2APNuzLJOpsrxLfA7aNNYw=
=8GLn
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Wed Aug 16 00:41:37 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 15 Aug 2006 23:41:37 -0500
Subject: [Rspec-devel] Feature requests
In-Reply-To: <44E274A2.3040001@redfivellc.com>
References: <44E274A2.3040001@redfivellc.com>
Message-ID: <8d961d900608152141g72b21db8h9f57748841505def@mail.gmail.com>

On 8/15/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
> I've run into a couple of minor irritations working with rspec recently.
>
> Mostly, I really like working with rspec.  Tidy DSL, good Rake
> integration, built in mocks and coverage are all major boons.  But:
>
> proc.should_raise and should_not_raise both result in printing the
> backtrace of the the RSpec failure they raise, rather than the
> unexpected exception that was raised.  This leads to a fair amount of
> extra dev time spent hunting down the error, where a message along the
> lines of "proc should not have raised, but instead raised:" and the
> whole exception (not the standard Ruby "...400 lines skipped that
> include the line you care about..." :)
>
> Contrarywise, other expectations also print their entire backtrace,
> which is rarely helpful and consumes a fair amount of scrollback and
> attention.
>
> Finally hash.should_has_key(:key) fails (<hash> doesn't respond to has?)
> as do similar predicates (i.e. anything with an underscore).
>
> It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> as an expectation to be called at least 3 times, and warn if they were
> told otherwise - it's certainly not Least Surprise when the class being
> specced against fails because it's getting the wrong result.
>
> Am I the voice in the wilderness here?

No

> I'm more than willing to submit
> patches, if there's some chance they'll be accepted.
>

Absolutely!

Bring on the patches in our tracker at Rubyforge. You don't have to
provide a fix (although it's nice if you do). The most important is
some code that would allow us to reproduce a long and ugly backtrace.
We'd be able to fix that fairly quickly.

Cheers,
Aslak

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

From dastels at daveastels.com  Wed Aug 16 00:48:01 2006
From: dastels at daveastels.com (David Astels)
Date: Wed, 16 Aug 2006 01:48:01 -0300
Subject: [Rspec-devel] Feature requests
In-Reply-To: <44E274A2.3040001@redfivellc.com>
References: <44E274A2.3040001@redfivellc.com>
Message-ID: <9E844D10-065B-41C3-A1AB-9CF4387056DA@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 15-Aug-06, at 10:28 PM, Judson Lester wrote:

>
> It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> as an expectation to be called at least 3 times, and warn if they were
> told otherwise - it's certainly not Least Surprise when the class  
> being
> specced against fails because it's getting the wrong result.

I rather like this.. ok.. ok... what I really said when I read this  
was "why didn't I think of that!" ;)

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE4qOBauez/L4x7g4RApTSAJ90Y3xtgBO3nUBP2Sy7k1FwAvHLQACdERdD
mgML2mjUSF86vp4s59fn9Qk=
=94ib
-----END PGP SIGNATURE-----

From jim.weirich at gmail.com  Wed Aug 16 01:06:58 2006
From: jim.weirich at gmail.com (Jim Weirich)
Date: Wed, 16 Aug 2006 01:06:58 -0400
Subject: [Rspec-devel] Feature requests
In-Reply-To: <44E274A2.3040001@redfivellc.com>
References: <44E274A2.3040001@redfivellc.com>
Message-ID: <d4dd9080608152206o5ec61aa6gb093d57165ddfc3@mail.gmail.com>

On 8/15/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
>
> It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> as an expectation to be called at least 3 times, and warn if they were
> told otherwise -



Hmmm ... how would one specify that it returned an array consisting of the
numbers 1, 2 and 3?

Perhaps this convention would work:

.and_return([1,2,3])  -- Returns once, the array [1,2,3]
.and_return(1,2,3)    -- Returns three times, first a 1, then a 2, then a 3

-- 
-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060816/09623c48/attachment.html 

From brian.takita at gmail.com  Wed Aug 16 01:25:12 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Tue, 15 Aug 2006 22:25:12 -0700
Subject: [Rspec-devel] Feature requests
In-Reply-To: <d4dd9080608152206o5ec61aa6gb093d57165ddfc3@mail.gmail.com>
References: <44E274A2.3040001@redfivellc.com>
	<d4dd9080608152206o5ec61aa6gb093d57165ddfc3@mail.gmail.com>
Message-ID: <1d7ddd110608152225l24383c9fhf76b5182a5928d60@mail.gmail.com>

>
> .and_return(1,2,3)    -- Returns three times, first a 1, then a 2, then a
> 3


Yes, I like that.

On 8/15/06, Jim Weirich <jim.weirich at gmail.com> wrote:
>
> On 8/15/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
>
> > It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> > as an expectation to be called at least 3 times, and warn if they were
> > told otherwise -
>
>
>
> Hmmm ... how would one specify that it returned an array consisting of the
> numbers 1, 2 and 3?
>
> Perhaps this convention would work:
>
> .and_return([1,2,3])  -- Returns once, the array [1,2,3]
> .and_return(1,2,3)    -- Returns three times, first a 1, then a 2, then a
> 3
>
> --
> --
> -- Jim Weirich     jim at weirichhouse.org     http://onestepback.org
> -----------------------------------------------------------------
> "Beware of bugs in the above code; I have only proved it correct,
> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060815/cd91a291/attachment-0001.html 

From aslak.hellesoy at gmail.com  Wed Aug 16 01:33:06 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 16 Aug 2006 00:33:06 -0500
Subject: [Rspec-devel] Feature requests
In-Reply-To: <1d7ddd110608152225l24383c9fhf76b5182a5928d60@mail.gmail.com>
References: <44E274A2.3040001@redfivellc.com>
	<d4dd9080608152206o5ec61aa6gb093d57165ddfc3@mail.gmail.com>
	<1d7ddd110608152225l24383c9fhf76b5182a5928d60@mail.gmail.com>
Message-ID: <8d961d900608152233s25b430a4i14314cb7b087b111@mail.gmail.com>

On 8/16/06, Brian Takita <brian.takita at gmail.com> wrote:
>
> > .and_return(1,2,3)    -- Returns three times, first a 1, then a 2, then a
> 3
>
>
> Yes, I like that.
>

Please register an RFE. I'd do it myself, but I'm in the midst of moving....

A

>
> On 8/15/06, Jim Weirich <jim.weirich at gmail.com> wrote:
> >
>
> On 8/15/06, Judson Lester <nyarly-rspec at redfivellc.com > wrote:
>
> > It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> > as an expectation to be called at least 3 times, and warn if they were
> > told otherwise -
>
>
>
> Hmmm ... how would one specify that it returned an array consisting of the
> numbers 1, 2 and 3?
>
> Perhaps this convention would work:
>
> .and_return([1,2,3])  -- Returns once, the array [1,2,3]
> .and_return(1,2,3)    -- Returns three times, first a 1, then a 2, then a 3
>
> --
>  --
> -- Jim Weirich     jim at weirichhouse.org     http://onestepback.org
> -----------------------------------------------------------------
> "Beware of bugs in the above code; I have only proved it correct,
> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From luke at agileevolved.com  Wed Aug 16 04:54:40 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Wed, 16 Aug 2006 09:54:40 +0100
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <2D2D84A0-BFC3-4688-A955-93D5C20C46D1@daveastels.com>
References: <a4150eba0608151436o2f53f7cet191503d870de6e0b@mail.gmail.com>
	<2D2D84A0-BFC3-4688-A955-93D5C20C46D1@daveastels.com>
Message-ID: <A8539080-384C-4CBB-BC46-59856EFC3FF8@agileevolved.com>

Its gotta be the one click ruby installer, available from rubyforge.  
It gives you ruby, gems, ri, rdoc and scite.

Cheers
Luke

On 16 Aug 2006, at 02:07, David Astels wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On 15-Aug-06, at 6:36 PM, Dominique Plante wrote:
>
>>
>> Depending on who the audience is (or where this appears), you may  
>> want
>> to point people to stuff on CRC cards, where to find rspec, mock
>> objects etc...
>
> So what's the recommended way to install Ruby for Windows?  I've only
> ever used it on Linux and OS X.
>
> Dave
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
>
> iD8DBQFE4m+7auez/L4x7g4RAk73AJoCxbsjGSqwsAZbiCIZT9bthWX7kgCdFxz1
> gewZOR6hNqyYJhFHt9XIsqQ=
> =+XHB
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From asbradbury at tekcentral.org  Wed Aug 16 09:27:30 2006
From: asbradbury at tekcentral.org (A. S. Bradbury)
Date: Wed, 16 Aug 2006 14:27:30 +0100
Subject: [Rspec-devel] SpecMatcher doesn't escape strings before matching
Message-ID: <200608161427.31260.asbradbury@tekcentral.org>

This bug [#5141] has been sitting in the queue for getting on a month now, so 
I hope you won't mind me brining it to the list. I've just been bitten by it 
when trying to specify behaviour for a #[] method. I assume this behaviour 
isn't intentional?

Alex

From dastels at daveastels.com  Wed Aug 16 13:25:57 2006
From: dastels at daveastels.com (David Astels)
Date: Wed, 16 Aug 2006 14:25:57 -0300
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <BB7D9B84-8C5F-4BC1-8878-3339FDBC857F@daveastels.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
	<6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
	<BB7D9B84-8C5F-4BC1-8878-3339FDBC857F@daveastels.com>
Message-ID: <5A46468F-C111-4A5E-B299-B025B142017C@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Another update, with the latest feedback (including file tagging :) ):

	http://blog.daveastels.com/files/mastermind-ruby.pdf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE41Ulauez/L4x7g4RAp/RAKCM3VJ782RATHOie++VANR9IfkH6wCdE7FZ
e3jHHEcD/U5cutZic/r58R4=
=dhXJ
-----END PGP SIGNATURE-----

From dominique.plante at gmail.com  Wed Aug 16 18:44:04 2006
From: dominique.plante at gmail.com (Dominique Plante)
Date: Wed, 16 Aug 2006 15:44:04 -0700
Subject: [Rspec-devel] rSpec tutorial
Message-ID: <a4150eba0608161544r28ef7891o100ae6e95fc98ad@mail.gmail.com>

Dave:

The easiest way to install ruby for windows is via the one-click ruby
installer for windows ( go to
http://rubyinstaller.rubyforge.org/wiki/wiki.pl, then click on
download)  It should go very cleanly, but I would recommend you go to
a command prompt and type set and copy and paste all the output to a
text file in case your path or something else gets overwritten before
doing this.

A couple of other points/suggestions on the Mastermind Project pdf.

* In the intro, you might want to say Let's do some BDD to create the
mastermind game

*  In the first and third paragraph of your article, you use the term
"solution" (which you later refer to as the code").  In the CRC cards,
the solution and a guess are both a code.  Things might read more
clearly if you used solution where you currently use code, but leave
the Code class the way it is.

* In the introduction, you might also want to say that after any
guess, there will be between 0 - 4 white markers set based on the
guess, and 0 - 4 black markers set based on the guess, and maybe that
the the sum of white markers + black markers will never be greater
than 4.

* On page 2 of the article where you list all the classes and their
responsibilities, you may want to say "Game:  coordinates the play,
counts turns (with the game over after 10), gets input, sees how good
the guess is, and reports back to the user."

* You may want to put in the margin the name of the spec files you are
showing - I noticed that:
* on page 3 the spec is all_white_code_spec.rb
* the one on page 8 is all_white_code_with_all_black_guess_spec.rb
* the one on page 10 is one_peg_right_colour_wrong_place_spec.rb

* Page 5: "We added a method rather than [an - spelled a in your
article] attribute reader because...   Also, I guess I would have to
read those articles because I thought attr_reader and attr_writer were
better than accessors and mutators... (if I read what you wrote
properly)

* page 10: you might want to say under "Tallying white pegs" - "So we
are going to write a spec in which only one peg in the guess is the
right colour, but it is in the wrong spot."

* page 12: from looking at the output of spec, it seems like a new
spec was written or one was renamed - I think it's the latest version
of all_white_code_spec.rb -  I'm referring to
all_white_code_with_all_white_guessspec.rb, which following your
naming convention should have been
all_white_code_with_all_white_guess_spec.rb)

* page 12: found_at[each] = false - this line should be bolded (since
it is a new line)

* page 13: considerable -> considerably

* page 16: I think you mean to write "the concrete implementation of
this will be a thin wrapper around whatever *random* generator is
provided by the language/library in use."

* page 16: We will need a random generator that gives us a series of
integers between 0 and 5 inclusive (corresponding to the 6 allowable
colours)

* You use some of the really cool Ruby features, blocks, enumerable
methods... Which is great.... But to be honest the code in bold at
white = .... on page 11 started getting kind of hard for me to follow
(as well as the the code white = ... on page 12)... it's good that it
got a  little bit more readable by page 13 with any? !

Sorry I haven't finished re-reading past page 20 looking for the
really picky things...

It's still a great article!!!!!!!!!!!

Thanks!
Dominique

-------------------------------------------------------------
dom.website = http://www.binaryshift.com

From nicksieger at gmail.com  Thu Aug 17 15:44:47 2006
From: nicksieger at gmail.com (Nick Sieger)
Date: Thu, 17 Aug 2006 14:44:47 -0500
Subject: [Rspec-devel] Spec stats
Message-ID: <f0b861390608171244p39e170a0ja4c5899e45559575@mail.gmail.com>

I'm starting a new Rails project all BDD with RSpec, and one thing I noticed
is that "rake stats" includes tests but not specs.  Adding this to your
rspec.rake fixes that:

namespace :spec do
  desc "Setup specs for stats"
  task :statsetup do
    require 'code_statistics'
    ::STATS_DIRECTORIES << %w(Model\ specs spec/models)
    ::STATS_DIRECTORIES << %w(Controller\ specs spec/controllers)
    ::CodeStatistics::TEST_TYPES << "Model specs"
    ::CodeStatistics::TEST_TYPES << "Controller specs"
    ::STATS_DIRECTORIES.delete_if {|a| a[0] =~ /test/}
  end
end

task :stats => "spec:statsetup"

Patch in tracker [1].

$ rake stats
(in /Users/nicksieger/Work/rapids)
+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Helpers              |     5 |     4 |       0 |       0 |   0 |     0 |
| Controllers          |    23 |    19 |       2 |       2 |   1 |     7 |
| Models               |    14 |    12 |       1 |       1 |   1 |    10 |
| Libraries            |     0 |     0 |       0 |       0 |   0 |     0 |
|   Model specs        |    27 |    22 |       0 |       0 |   0 |     0 |
|   Controller specs   |    33 |    26 |       0 |       1 |   0 |    24 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |   102 |    83 |       3 |       4 |   1 |    18 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 35     Test LOC: 48     Code to Test Ratio: 1:1.4

Cheers,
/Nick

[1]:
http://rubyforge.org/tracker/index.php?func=detail&aid=5449&group_id=797&atid=3151
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060817/bba77077/attachment.html 

From daniel at dr-siemssen.de  Thu Aug 17 17:16:27 2006
From: daniel at dr-siemssen.de (Daniel Siemssen)
Date: Thu, 17 Aug 2006 23:16:27 +0200
Subject: [Rspec-devel] run specs FAST with rails_spec
In-Reply-To: <8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com>
References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com>	<44AA6C31.5040703@rubyforge.org>
	<8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com>
Message-ID: <44E4DCAB.9040206@dr-siemssen.de>

On 04.07.2006 16:59, aslak hellesoy wrote:
> On 7/4/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>   
>> Probably nothing.  The tests completed in no time!  But then I ran them
>> again, and they all failed, with errors like:
>>     
>
> I get a similar error running from the demo app. However it's the
> model classes that aren't found - not the ficture ones:
>
> $ script/rails_spec spec/models/person_spec.rb
>
> 1)
> NameError in 'The Person model should find an existing person'
> uninitialized constant Person
>
> etc.....
>
>   
>> FixtureClassNotFound in 'The BBB receipt can handle adding the bunny
>> slippers'
>> The class "Receipt" was not found.
>> /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/fixtures.rb:403:in
>> `find'
>> ./spec/models/receipt_spec.rb:68:in `setup'
>> script/rails_spec_runner:25:in `run'
>> /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
>> /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
>> /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
>> /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
>> /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
>> /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
>> /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
>> /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
>> /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
>> script/rails_spec_runner:46
>>
>> Finished in 0.341 seconds
>>
>> 32 specifications, 32 failures
>>
>> Did I miss a step, or is this a bug with rails_spec_runner's handling of
>> fixtures?
>>
>>     
>
> This is definitely a bug, and it's not fixture specific. Nothing works
> on a second run.
> I don't know what's causing this yet.
>
> And it needs to get fixed!
>
> Aslak
>   
>
The models fail to load in the second run because rails can't reload the 
models after Dispatcher.reset_application! in test mode. Why is rails 
doing that? Because config.cache_classes = true by default in test mode 
and the initialize_dependency_mechanism in Rails::Initializer sets the 
Dependencies.mechanism depending on the value of config.cache_classes. 
Thus Dependencies.mechanism = :load is reset to :require after the first 
call of Dispatcher.reset_application! and models won't get loaded 
anymore. All you have to do is put a Dependencies.mechanism = :load 
before the "Dispatcher.reset_application!"-line or set cache_classes = 
false.

Daniel

From daniel at dr-siemssen.de  Thu Aug 17 17:29:43 2006
From: daniel at dr-siemssen.de (Daniel Siemssen)
Date: Thu, 17 Aug 2006 23:29:43 +0200
Subject: [Rspec-devel] RSpec on Rails and Rails Engines
Message-ID: <44E4DFC7.2080208@dr-siemssen.de>

Why do you have the require lines for controller_mixin.rb and 
rspec_on_rails.rb in your init.rb and not in the spec_helper.rb? When 
these require lines are in the init.rb they cause errors for Rails 
Engines users because rspec_on_rails.rb requires 'application'. Since 
application might have some include lines like 'include myengine' and 
since the rspec_on_rails plugin gets loaded before any engine, you'll 
certainly run into troubles when loading your rails environment.
So, my question is, can you put these lines into spec_helper.rb and if 
not please tell me why.

Keep up the good work!

Daniel


From aslak.hellesoy at gmail.com  Thu Aug 17 20:36:45 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 17 Aug 2006 19:36:45 -0500
Subject: [Rspec-devel] run specs FAST with rails_spec
In-Reply-To: <44E4DCAB.9040206@dr-siemssen.de>
References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com>
	<44AA6C31.5040703@rubyforge.org>
	<8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com>
	<44E4DCAB.9040206@dr-siemssen.de>
Message-ID: <8d961d900608171736p1c99b5e6kd61f0e889ba1c000@mail.gmail.com>

On 8/17/06, Daniel Siemssen <daniel at dr-siemssen.de> wrote:
> On 04.07.2006 16:59, aslak hellesoy wrote:
> > On 7/4/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> >
> >> Probably nothing.  The tests completed in no time!  But then I ran them
> >> again, and they all failed, with errors like:
> >>
> >
> > I get a similar error running from the demo app. However it's the
> > model classes that aren't found - not the ficture ones:
> >
> > $ script/rails_spec spec/models/person_spec.rb
> >
> > 1)
> > NameError in 'The Person model should find an existing person'
> > uninitialized constant Person
> >
> > etc.....
> >
> >
> >> FixtureClassNotFound in 'The BBB receipt can handle adding the bunny
> >> slippers'
> >> The class "Receipt" was not found.
> >> /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/fixtures.rb:403:in
> >> `find'
> >> ./spec/models/receipt_spec.rb:68:in `setup'
> >> script/rails_spec_runner:25:in `run'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
> >> /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
> >> script/rails_spec_runner:46
> >>
> >> Finished in 0.341 seconds
> >>
> >> 32 specifications, 32 failures
> >>
> >> Did I miss a step, or is this a bug with rails_spec_runner's handling of
> >> fixtures?
> >>
> >>
> >
> > This is definitely a bug, and it's not fixture specific. Nothing works
> > on a second run.
> > I don't know what's causing this yet.
> >
> > And it needs to get fixed!
> >
> > Aslak
> >
> >
> The models fail to load in the second run because rails can't reload the
> models after Dispatcher.reset_application! in test mode. Why is rails
> doing that? Because config.cache_classes = true by default in test mode
> and the initialize_dependency_mechanism in Rails::Initializer sets the
> Dependencies.mechanism depending on the value of config.cache_classes.
> Thus Dependencies.mechanism = :load is reset to :require after the first
> call of Dispatcher.reset_application! and models won't get loaded
> anymore. All you have to do is put a Dependencies.mechanism = :load
> before the "Dispatcher.reset_application!"-line or set cache_classes =
> false.
>

Does this mean you've succeeded in getting the fast rails drb spec
runner working?
Would be awesome.

Aslak

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

From aslak.hellesoy at gmail.com  Thu Aug 17 20:38:42 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 17 Aug 2006 19:38:42 -0500
Subject: [Rspec-devel] RSpec on Rails and Rails Engines
In-Reply-To: <44E4DFC7.2080208@dr-siemssen.de>
References: <44E4DFC7.2080208@dr-siemssen.de>
Message-ID: <8d961d900608171738x2a47cff7s4942219206ea1bed@mail.gmail.com>

On 8/17/06, Daniel Siemssen <daniel at dr-siemssen.de> wrote:
> Why do you have the require lines for controller_mixin.rb and
> rspec_on_rails.rb in your init.rb and not in the spec_helper.rb? When
> these require lines are in the init.rb they cause errors for Rails
> Engines users because rspec_on_rails.rb requires 'application'. Since
> application might have some include lines like 'include myengine' and
> since the rspec_on_rails plugin gets loaded before any engine, you'll
> certainly run into troubles when loading your rails environment.
> So, my question is, can you put these lines into spec_helper.rb and if
> not please tell me why.
>

It's been a month or two since I worked on this so my memory is a bit
rusty on this. Do you have a patch that you would like us to
incorporate?

Aslak

> Keep up the good work!
>
> Daniel
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Thu Aug 17 20:41:50 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 17 Aug 2006 19:41:50 -0500
Subject: [Rspec-devel] Spec stats
In-Reply-To: <f0b861390608171244p39e170a0ja4c5899e45559575@mail.gmail.com>
References: <f0b861390608171244p39e170a0ja4c5899e45559575@mail.gmail.com>
Message-ID: <8d961d900608171741j6267fd97n4dd34ceb87447175@mail.gmail.com>

On 8/17/06, Nick Sieger <nicksieger at gmail.com> wrote:
> I'm starting a new Rails project all BDD with RSpec, and one thing I noticed
> is that "rake stats" includes tests but not specs.  Adding this to your
> rspec.rake fixes that:
>
> namespace :spec do
>   desc "Setup specs for stats"
>   task :statsetup do
>     require 'code_statistics'
>     ::STATS_DIRECTORIES << %w(Model\ specs spec/models)
>     ::STATS_DIRECTORIES << %w(Controller\ specs spec/controllers)
>     ::CodeStatistics::TEST_TYPES << "Model specs"
>     ::CodeStatistics::TEST_TYPES << "Controller specs"
>     ::STATS_DIRECTORIES.delete_if {|a| a[0] =~ /test/}
>   end
> end
>
> task :stats => "spec:statsetup"
>
> Patch in tracker [1].
>
> $ rake stats
> (in /Users/nicksieger/Work/rapids)
> +----------------------+-------+-------+---------+---------+-----+-------+
> | Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
> +----------------------+-------+-------+---------+---------+-----+-------+
> | Helpers              |     5 |     4 |       0 |       0 |   0 |     0 |
> | Controllers          |    23 |    19 |       2 |       2 |   1 |     7 |
> | Models               |    14 |    12 |       1 |       1 |   1 |    10 |
> | Libraries            |     0 |     0 |       0 |       0 |   0 |     0 |
> |   Model specs        |    27 |    22 |       0 |       0 |   0 |     0 |
> |   Controller specs   |    33 |    26 |       0 |       1 |   0 |    24 |
> +----------------------+-------+-------+---------+---------+-----+-------+
> | Total                |   102 |    83 |       3 |       4 |   1 |    18 |
> +----------------------+-------+-------+---------+---------+-----+-------+
>   Code LOC: 35     Test LOC: 48     Code to Test Ratio: 1:1.4
>
> Cheers,
> /Nick
>
> [1]:
> http://rubyforge.org/tracker/index.php?func=detail&aid=5449&group_id=797&atid=3151
>

Good stuff Nick - we love patches. I'll get to it as soon as I get my
head above water(just moved).

Aslak

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

From nicksieger at gmail.com  Thu Aug 17 21:47:18 2006
From: nicksieger at gmail.com (Nick Sieger)
Date: Thu, 17 Aug 2006 20:47:18 -0500
Subject: [Rspec-devel] Spec stats
In-Reply-To: <8d961d900608171741j6267fd97n4dd34ceb87447175@mail.gmail.com>
References: <f0b861390608171244p39e170a0ja4c5899e45559575@mail.gmail.com>
	<8d961d900608171741j6267fd97n4dd34ceb87447175@mail.gmail.com>
Message-ID: <f0b861390608171847s79ef2184k64948152bc19243d@mail.gmail.com>

On 8/17/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
>
> Good stuff Nick - we love patches. I'll get to it as soon as I get my
> head above water(just moved).


No worries -- I'm on vacation for a week and then I'll be doing the same
moving drill!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060817/8160498c/attachment.html 

From daniel at dr-siemssen.de  Fri Aug 18 03:47:34 2006
From: daniel at dr-siemssen.de (Daniel Siemssen)
Date: Fri, 18 Aug 2006 09:47:34 +0200
Subject: [Rspec-devel] run specs FAST with rails_spec
In-Reply-To: <8d961d900608171736p1c99b5e6kd61f0e889ba1c000@mail.gmail.com>
References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com>	<44AA6C31.5040703@rubyforge.org>	<8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com>	<44E4DCAB.9040206@dr-siemssen.de>
	<8d961d900608171736p1c99b5e6kd61f0e889ba1c000@mail.gmail.com>
Message-ID: <44E57096.3070109@dr-siemssen.de>

On 18.08.2006 02:36, aslak hellesoy wrote:
> On 8/17/06, Daniel Siemssen <daniel at dr-siemssen.de> wrote:
>   
>> On 04.07.2006 16:59, aslak hellesoy wrote:
>>     
>>> On 7/4/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>>>
>>>       
>>>> Probably nothing.  The tests completed in no time!  But then I ran them
>>>> again, and they all failed, with errors like:
>>>>
>>>>         
>>> I get a similar error running from the demo app. However it's the
>>> model classes that aren't found - not the ficture ones:
>>>
>>> $ script/rails_spec spec/models/person_spec.rb
>>>
>>> 1)
>>> NameError in 'The Person model should find an existing person'
>>> uninitialized constant Person
>>>
>>> etc.....
>>>
>>>
>>>       
>>>> FixtureClassNotFound in 'The BBB receipt can handle adding the bunny
>>>> slippers'
>>>> The class "Receipt" was not found.
>>>> /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/fixtures.rb:403:in
>>>> `find'
>>>> ./spec/models/receipt_spec.rb:68:in `setup'
>>>> script/rails_spec_runner:25:in `run'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
>>>> /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
>>>> script/rails_spec_runner:46
>>>>
>>>> Finished in 0.341 seconds
>>>>
>>>> 32 specifications, 32 failures
>>>>
>>>> Did I miss a step, or is this a bug with rails_spec_runner's handling of
>>>> fixtures?
>>>>
>>>>
>>>>         
>>> This is definitely a bug, and it's not fixture specific. Nothing works
>>> on a second run.
>>> I don't know what's causing this yet.
>>>
>>> And it needs to get fixed!
>>>
>>> Aslak
>>>
>>>
>>>       
>> The models fail to load in the second run because rails can't reload the
>> models after Dispatcher.reset_application! in test mode. Why is rails
>> doing that? Because config.cache_classes = true by default in test mode
>> and the initialize_dependency_mechanism in Rails::Initializer sets the
>> Dependencies.mechanism depending on the value of config.cache_classes.
>> Thus Dependencies.mechanism = :load is reset to :require after the first
>> call of Dispatcher.reset_application! and models won't get loaded
>> anymore. All you have to do is put a Dependencies.mechanism = :load
>> before the "Dispatcher.reset_application!"-line or set cache_classes =
>> false.
>>
>>     
>
> Does this mean you've succeeded in getting the fast rails drb spec
> runner working?
> Would be awesome.
>
> Aslak
>
>   
Yes, got it running. I'll send you a mail with the patches.
>> Daniel
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>     
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>   


From aslak.hellesoy at gmail.com  Sat Aug 19 06:41:04 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 19 Aug 2006 12:41:04 +0200
Subject: [Rspec-devel] run specs FAST with rails_spec
In-Reply-To: <44E57096.3070109@dr-siemssen.de>
References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com>
	<44AA6C31.5040703@rubyforge.org>
	<8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com>
	<44E4DCAB.9040206@dr-siemssen.de>
	<8d961d900608171736p1c99b5e6kd61f0e889ba1c000@mail.gmail.com>
	<44E57096.3070109@dr-siemssen.de>
Message-ID: <8d961d900608190341k1c207268xb6a5bf1ff4996f36@mail.gmail.com>

On 8/18/06, Daniel Siemssen <daniel at dr-siemssen.de> wrote:
> On 18.08.2006 02:36, aslak hellesoy wrote:
> > On 8/17/06, Daniel Siemssen <daniel at dr-siemssen.de> wrote:
> >
> >> On 04.07.2006 16:59, aslak hellesoy wrote:
> >>
> >>> On 7/4/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> >>>
> >>>
> >>>> Probably nothing.  The tests completed in no time!  But then I ran them
> >>>> again, and they all failed, with errors like:
> >>>>
> >>>>
> >>> I get a similar error running from the demo app. However it's the
> >>> model classes that aren't found - not the ficture ones:
> >>>
> >>> $ script/rails_spec spec/models/person_spec.rb
> >>>
> >>> 1)
> >>> NameError in 'The Person model should find an existing person'
> >>> uninitialized constant Person
> >>>
> >>> etc.....
> >>>
> >>>
> >>>
> >>>> FixtureClassNotFound in 'The BBB receipt can handle adding the bunny
> >>>> slippers'
> >>>> The class "Receipt" was not found.
> >>>> /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/fixtures.rb:403:in
> >>>> `find'
> >>>> ./spec/models/receipt_spec.rb:68:in `setup'
> >>>> script/rails_spec_runner:25:in `run'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
> >>>> /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
> >>>> script/rails_spec_runner:46
> >>>>
> >>>> Finished in 0.341 seconds
> >>>>
> >>>> 32 specifications, 32 failures
> >>>>
> >>>> Did I miss a step, or is this a bug with rails_spec_runner's handling of
> >>>> fixtures?
> >>>>
> >>>>
> >>>>
> >>> This is definitely a bug, and it's not fixture specific. Nothing works
> >>> on a second run.
> >>> I don't know what's causing this yet.
> >>>
> >>> And it needs to get fixed!
> >>>
> >>> Aslak
> >>>
> >>>
> >>>
> >> The models fail to load in the second run because rails can't reload the
> >> models after Dispatcher.reset_application! in test mode. Why is rails
> >> doing that? Because config.cache_classes = true by default in test mode
> >> and the initialize_dependency_mechanism in Rails::Initializer sets the
> >> Dependencies.mechanism depending on the value of config.cache_classes.
> >> Thus Dependencies.mechanism = :load is reset to :require after the first
> >> call of Dispatcher.reset_application! and models won't get loaded
> >> anymore. All you have to do is put a Dependencies.mechanism = :load
> >> before the "Dispatcher.reset_application!"-line or set cache_classes =
> >> false.
> >>
> >>
> >
> > Does this mean you've succeeded in getting the fast rails drb spec
> > runner working?
> > Would be awesome.
> >
> > Aslak
> >
> >
> Yes, got it running. I'll send you a mail with the patches.

Thanks a lot Daniel. For the future, please submit patches in RSpec's
tracker at Rubyforge.

I have committed your patch, but my controller specs are still failing
on the second run. (Model specs can run many times and also do seem to
get reloaded, which is great).

I'm running the specs for the demo app that the rspec_on_rails plugin lives in:

Shell 1:
cd vendor/rspec_on_rails
script/rails_spec_runner

Shell 2:
cd vendor/rspec_on_rails
script/rails_spec spec/models
script/rails_spec spec/models
script/rails_spec spec/controllers
script/rails_spec spec/controllers #fails

Any idea what causes this or how to fix it?

Cheers,
Aslak

> >> Daniel
> >> _______________________________________________
> >> 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
> >
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From daniel at dr-siemssen.de  Sat Aug 19 18:57:26 2006
From: daniel at dr-siemssen.de (Daniel Siemssen)
Date: Sun, 20 Aug 2006 00:57:26 +0200
Subject: [Rspec-devel] run specs FAST with rails_spec
In-Reply-To: <8d961d900608190341k1c207268xb6a5bf1ff4996f36@mail.gmail.com>
References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com>	<44AA6C31.5040703@rubyforge.org>	<8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com>	<44E4DCAB.9040206@dr-siemssen.de>	<8d961d900608171736p1c99b5e6kd61f0e889ba1c000@mail.gmail.com>	<44E57096.3070109@dr-siemssen.de>
	<8d961d900608190341k1c207268xb6a5bf1ff4996f36@mail.gmail.com>
Message-ID: <44E79756.40106@dr-siemssen.de>

On 19.08.2006 12:41, aslak hellesoy wrote:
> On 8/18/06, Daniel Siemssen <daniel at dr-siemssen.de> wrote:
>   
>> On 18.08.2006 02:36, aslak hellesoy wrote:
>>     
>>> On 8/17/06, Daniel Siemssen <daniel at dr-siemssen.de> wrote:
>>>
>>>       
>>>> On 04.07.2006 16:59, aslak hellesoy wrote:
>>>>
>>>>         
>>>>> On 7/4/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Probably nothing.  The tests completed in no time!  But then I ran them
>>>>>> again, and they all failed, with errors like:
>>>>>>
>>>>>>
>>>>>>             
>>>>> I get a similar error running from the demo app. However it's the
>>>>> model classes that aren't found - not the ficture ones:
>>>>>
>>>>> $ script/rails_spec spec/models/person_spec.rb
>>>>>
>>>>> 1)
>>>>> NameError in 'The Person model should find an existing person'
>>>>> uninitialized constant Person
>>>>>
>>>>> etc.....
>>>>>
>>>>>
>>>>>
>>>>>           
>>>>>> FixtureClassNotFound in 'The BBB receipt can handle adding the bunny
>>>>>> slippers'
>>>>>> The class "Receipt" was not found.
>>>>>> /usr/lib/ruby/gems/1.8/gems/activerecord-1.14.2/lib/active_record/fixtures.rb:403:in
>>>>>> `find'
>>>>>> ./spec/models/receipt_spec.rb:68:in `setup'
>>>>>> script/rails_spec_runner:25:in `run'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
>>>>>> /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
>>>>>> script/rails_spec_runner:46
>>>>>>
>>>>>> Finished in 0.341 seconds
>>>>>>
>>>>>> 32 specifications, 32 failures
>>>>>>
>>>>>> Did I miss a step, or is this a bug with rails_spec_runner's handling of
>>>>>> fixtures?
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>> This is definitely a bug, and it's not fixture specific. Nothing works
>>>>> on a second run.
>>>>> I don't know what's causing this yet.
>>>>>
>>>>> And it needs to get fixed!
>>>>>
>>>>> Aslak
>>>>>
>>>>>
>>>>>
>>>>>           
>>>> The models fail to load in the second run because rails can't reload the
>>>> models after Dispatcher.reset_application! in test mode. Why is rails
>>>> doing that? Because config.cache_classes = true by default in test mode
>>>> and the initialize_dependency_mechanism in Rails::Initializer sets the
>>>> Dependencies.mechanism depending on the value of config.cache_classes.
>>>> Thus Dependencies.mechanism = :load is reset to :require after the first
>>>> call of Dispatcher.reset_application! and models won't get loaded
>>>> anymore. All you have to do is put a Dependencies.mechanism = :load
>>>> before the "Dispatcher.reset_application!"-line or set cache_classes =
>>>> false.
>>>>
>>>>
>>>>         
>>> Does this mean you've succeeded in getting the fast rails drb spec
>>> runner working?
>>> Would be awesome.
>>>
>>> Aslak
>>>
>>>
>>>       
>> Yes, got it running. I'll send you a mail with the patches.
>>     
>
> Thanks a lot Daniel. For the future, please submit patches in RSpec's
> tracker at Rubyforge.
>
> I have committed your patch, but my controller specs are still failing
> on the second run. (Model specs can run many times and also do seem to
> get reloaded, which is great).
>
> I'm running the specs for the demo app that the rspec_on_rails plugin lives in:
>
> Shell 1:
> cd vendor/rspec_on_rails
> script/rails_spec_runner
>
> Shell 2:
> cd vendor/rspec_on_rails
> script/rails_spec spec/models
> script/rails_spec spec/models
> script/rails_spec spec/controllers
> script/rails_spec spec/controllers #fails
>
> Any idea what causes this or how to fix it?
>   
Fixed it (application.rb does not get reloaded). See patch in tracker.

Daniel
> Cheers,
> Aslak
>
>   
>>>> Daniel
>>>> _______________________________________________
>>>> 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
>>>
>>>       
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
>>     
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>   


From maillist at steelskies.com  Sun Aug 20 13:11:14 2006
From: maillist at steelskies.com (Jonathan del Strother)
Date: Sun, 20 Aug 2006 18:11:14 +0100
Subject: [Rspec-devel] rSpec tutorial
In-Reply-To: <5A46468F-C111-4A5E-B299-B025B142017C@daveastels.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
	<6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
	<BB7D9B84-8C5F-4BC1-8878-3339FDBC857F@daveastels.com>
	<5A46468F-C111-4A5E-B299-B025B142017C@daveastels.com>
Message-ID: <922377D9-1E9E-4979-B72E-66E3DC1F902F@steelskies.com>

On 16 Aug 2006, at 18:25, David Astels wrote:
> Another update, with the latest feedback (including file tagging :) ):
>
> 	http://blog.daveastels.com/files/mastermind-ruby.pdf


Nice work.  One minor bug report - all_white_code_spec.rb on page 4  
needs the Mastermind module specifying - ie Mastermind::Code.new(...)  
rather than just Code.new(...)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2114 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/rspec-devel/attachments/20060820/b18a8cc8/attachment-0001.bin 

From dastels at daveastels.com  Sun Aug 20 19:09:53 2006
From: dastels at daveastels.com (David Astels)
Date: Sun, 20 Aug 2006 20:09:53 -0300
Subject: [Rspec-devel] habtm collections
In-Reply-To: <44E79756.40106@dr-siemssen.de>
References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com>	<44AA6C31.5040703@rubyforge.org>	<8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com>	<44E4DCAB.9040206@dr-siemssen.de>	<8d961d900608171736p1c99b5e6kd61f0e889ba1c000@mail.gmail.com>	<44E57096.3070109@dr-siemssen.de>
	<8d961d900608190341k1c207268xb6a5bf1ff4996f36@mail.gmail.com>
	<44E79756.40106@dr-siemssen.de>
Message-ID: <5BE4BC23-1DD5-453C-B84B-F487FBC4536D@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It looks like we need better support for habtm virtual collections...  
at least based on the behaviour I'm seeing.

For example, instead of doing:

	@dave.tracks.should_include Track.find_by_name("School's Out")

I have to do:

	@dave.tracks.include?(Track.find_by_name("School's Out")).should_be  
true

Yuck.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE6OvBauez/L4x7g4RAlGaAKCUjKFYUlRuu8KoRxedgPMtFtXwXQCfRZ7x
1vgNY50aZK+phkDhAEUXVnk=
=29QJ
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Sun Aug 20 22:18:48 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 21 Aug 2006 04:18:48 +0200
Subject: [Rspec-devel] Feature requests
In-Reply-To: <d4dd9080608152206o5ec61aa6gb093d57165ddfc3@mail.gmail.com>
References: <44E274A2.3040001@redfivellc.com>
	<d4dd9080608152206o5ec61aa6gb093d57165ddfc3@mail.gmail.com>
Message-ID: <8d961d900608201918x6968ef95t41f072f6325114d6@mail.gmail.com>

On 8/16/06, Jim Weirich <jim.weirich at gmail.com> wrote:
> On 8/15/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
>
> > It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> > as an expectation to be called at least 3 times, and warn if they were
> > told otherwise -
>
>
>
> Hmmm ... how would one specify that it returned an array consisting of the
> numbers 1, 2 and 3?
>
> Perhaps this convention would work:
>
> .and_return([1,2,3])  -- Returns once, the array [1,2,3]
> .and_return(1,2,3)    -- Returns three times, first a 1, then a 2, then a 3
>

I've created a patch for this:
http://rubyforge.org/tracker/index.php?func=detail&aid=5435&group_id=797&atid=3152

David - you're the boss. Ok to commit this? It will break backwards
compatibility, but I think that's ok if we explain in the release
notes what needs to be changed. We're only 0.6 (We should bump to 0.7
if this goes in).

Aslak

> --
> --
> -- Jim Weirich     jim at weirichhouse.org     http://onestepback.org
> -----------------------------------------------------------------
> "Beware of bugs in the above code; I have only proved it correct,
> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From aslak.hellesoy at gmail.com  Sun Aug 20 22:31:14 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 21 Aug 2006 04:31:14 +0200
Subject: [Rspec-devel] Feature requests
In-Reply-To: <44E274A2.3040001@redfivellc.com>
References: <44E274A2.3040001@redfivellc.com>
Message-ID: <8d961d900608201931s644435fco1f113f7cc49bb72b@mail.gmail.com>

On 8/16/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
> I've run into a couple of minor irritations working with rspec recently.
>
> Mostly, I really like working with rspec.  Tidy DSL, good Rake
> integration, built in mocks and coverage are all major boons.  But:
>
> proc.should_raise and should_not_raise both result in printing the
> backtrace of the the RSpec failure they raise, rather than the
> unexpected exception that was raised.  This leads to a fair amount of
> extra dev time spent hunting down the error, where a message along the
> lines of "proc should not have raised, but instead raised:" and the
> whole exception (not the standard Ruby "...400 lines skipped that
> include the line you care about..." :)
>

Could you please submit an RFE for this? Preferrably in the form of a
patch that we can apply and reproduce what you're getting. I'm not
sure how you're getting 400 lines of trace. Are you on Rails? In that
case - you can write the patch against the semo app under
vendor/rspec_on_rails.

> Contrarywise, other expectations also print their entire backtrace,
> which is rarely helpful and consumes a fair amount of scrollback and
> attention.
>

Really? We're stripping off most of the backtraces already. See spec's
-b command line option. How can I reproduce a long backtrace as you
describe?

> Finally hash.should_has_key(:key) fails (<hash> doesn't respond to has?)
> as do similar predicates (i.e. anything with an underscore).
>

You can do this with should_include(:key)

> It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> as an expectation to be called at least 3 times, and warn if they were
> told otherwise - it's certainly not Least Surprise when the class being
> specced against fails because it's getting the wrong result.
>
> Am I the voice in the wilderness here?  I'm more than willing to submit
> patches, if there's some chance they'll be accepted.
>
> Judson
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From smartgpx at gmail.com  Mon Aug 21 12:50:02 2006
From: smartgpx at gmail.com (DeeJay)
Date: Mon, 21 Aug 2006 17:50:02 +0100
Subject: [Rspec-devel] Rake Task - not for Windows ?
Message-ID: <533048b70608210950g7319e781ie181bc80b4d6b3@mail.gmail.com>

After some head-scratching, I have come to the conclusion that
Spec::Rake::SpecTask will
not run on Windows - is that correct?

(Point of failure is likely to be a reference to 'sh' in the task's run
method.)

If I am right about this, a warning note on the pages
http://rspec.rubyforge.org/tools/rake.html
and http://rspec.rubyforge.org/tools/rcov.html might save others some
frustration.

David, Leicester, UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060821/03f11e58/attachment.html 

From aslak.hellesoy at gmail.com  Mon Aug 21 13:39:12 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 21 Aug 2006 19:39:12 +0200
Subject: [Rspec-devel] Rake Task - not for Windows ?
In-Reply-To: <533048b70608210950g7319e781ie181bc80b4d6b3@mail.gmail.com>
References: <533048b70608210950g7319e781ie181bc80b4d6b3@mail.gmail.com>
Message-ID: <8d961d900608211039m680fea8dgf0c1a2e26926d7f1@mail.gmail.com>

On 8/21/06, DeeJay <smartgpx at gmail.com> wrote:
>
>
> After some head-scratching, I have come to the conclusion that
> Spec::Rake::SpecTask will
> not run on Windows - is that correct?
>
> (Point of failure is likely to be a reference to 'sh' in the task's run
> method.)
>
> If I am right about this, a warning note on the pages
> http://rspec.rubyforge.org/tools/rake.html
> and http://rspec.rubyforge.org/tools/rcov.html might save
> others some frustration.
>

There is already a bug report about this:
http://rubyforge.org/tracker/index.php?func=detail&aid=4891&group_id=797&atid=3149

I personally don't have access to windows these days (only os x) so I
can't reproduce it.
I'll try to get this fixed before the next release though.

Aslak

> David, Leicester, UK
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From jim.weirich at gmail.com  Mon Aug 21 14:32:00 2006
From: jim.weirich at gmail.com (Jim Weirich)
Date: Mon, 21 Aug 2006 14:32:00 -0400
Subject: [Rspec-devel] Rake Task - not for Windows ?
In-Reply-To: <533048b70608210950g7319e781ie181bc80b4d6b3@mail.gmail.com>
References: <533048b70608210950g7319e781ie181bc80b4d6b3@mail.gmail.com>
Message-ID: <d4dd9080608211132s637a096bu7629268e52d317b4@mail.gmail.com>

On 8/21/06, DeeJay <smartgpx at gmail.com> wrote:
>
>
> After some head-scratching, I have come to the conclusion that
> Spec::Rake::SpecTask will
> not run on Windows - is that correct?
>
> (Point of failure is likely to be a reference to 'sh' in the task's run
> method.)
>

The "sh" command will work in windows.  However, since it invokes external
programs, those programs may or may not be available on the target machine.
What is that particular "sh" command trying to run?

-- 
-- 
-- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060821/bc3d26e3/attachment.html 

From nyarly-rspec at redfivellc.com  Mon Aug 21 16:54:03 2006
From: nyarly-rspec at redfivellc.com (Judson Lester)
Date: Mon, 21 Aug 2006 13:54:03 -0700
Subject: [Rspec-devel] Feature requests
In-Reply-To: <8d961d900608201931s644435fco1f113f7cc49bb72b@mail.gmail.com>
References: <44E274A2.3040001@redfivellc.com>
	<8d961d900608201931s644435fco1f113f7cc49bb72b@mail.gmail.com>
Message-ID: <44EA1D6B.3040303@redfivellc.com>

aslak hellesoy wrote:
> On 8/16/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
>   
>> I've run into a couple of minor irritations working with rspec recently.
>>
>> Mostly, I really like working with rspec.  Tidy DSL, good Rake
>> integration, built in mocks and coverage are all major boons.  But:
>>
>> proc.should_raise and should_not_raise both result in printing the
>> backtrace of the the RSpec failure they raise, rather than the
>> unexpected exception that was raised.  This leads to a fair amount of
>> extra dev time spent hunting down the error, where a message along the
>> lines of "proc should not have raised, but instead raised:" and the
>> whole exception (not the standard Ruby "...400 lines skipped that
>> include the line you care about..." :)
>>
>>     
>
> Could you please submit an RFE for this? Preferrably in the form of a
> patch that we can apply and reproduce what you're getting. I'm not
> sure how you're getting 400 lines of trace. Are you on Rails? In that
> case - you can write the patch against the semo app under
> vendor/rspec_on_rails.
>   
I'll certainly submit an RFE.  I'm not sure I follow the idea of
submitting a patch though - I could probably bung up a spec file that
would demonstrate what I'm talking about.  And I could probably submit a
patch that would produce the behavior I'd like.  Do you mean both?

The "400 lines" was a bit of an exaggeration.  But I do a fair about of
DRb programming, which produces pretty deep call chains, which get cored
by the ruby interpreter when they're printed.  The standard (read:
matz's) solution is to wrap the whole app in a "rescue Exception => e"
and print the backtrace explicitly.  For development, this winds up
being incredibly handy, and it'd be nice if spec provided this behavior
on backtraces.

>> Contrarywise, other expectations also print their entire backtrace,
>> which is rarely helpful and consumes a fair amount of scrollback and
>> attention.
>>
>>     
>
> Really? We're stripping off most of the backtraces already. See spec's
> -b command line option. How can I reproduce a long backtrace as you
> describe?
>   
Under -f s, spec generates output of the form

A Context
- should do the right thing (FAILED - 1)

1) Spec::Api::ExpectionNotMet -
"a thing" should be "another thing"
<Backtrace goes here>

without -b.  Forgive inconsistencies in the sample output: it's typed
from memory.

>> Finally hash.should_has_key(:key) fails (<hash> doesn't respond to has?)
>> as do similar predicates (i.e. anything with an underscore).
>>
>>     
>
> You can do this with should_include(:key)
>   
Certainly, but while I've come to like the way that TDD/BDD drives
development in ways you wouldn't expect, a don't know if I like the idea
of never writing a two word predicate again.  Hash#has_key? was a good
example, but hardly the only one.

Judson


From aslak.hellesoy at gmail.com  Mon Aug 21 17:46:06 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 21 Aug 2006 23:46:06 +0200
Subject: [Rspec-devel] Rake Task - not for Windows ?
In-Reply-To: <d4dd9080608211132s637a096bu7629268e52d317b4@mail.gmail.com>
References: <533048b70608210950g7319e781ie181bc80b4d6b3@mail.gmail.com>
	<d4dd9080608211132s637a096bu7629268e52d317b4@mail.gmail.com>
Message-ID: <8d961d900608211446m56c8674dq5ab6448845b8e16d@mail.gmail.com>

On 8/21/06, Jim Weirich <jim.weirich at gmail.com> wrote:
>
>
>
> On 8/21/06, DeeJay <smartgpx at gmail.com> wrote:
> >
> >
> >
> > After some head-scratching, I have come to the conclusion that
> Spec::Rake::SpecTask will
> > not run on Windows - is that correct?
> >
> > (Point of failure is likely to be a reference to 'sh' in the task's run
> method.)
>
>
> The "sh" command will work in windows.  However, since it invokes external
> programs, those programs may or may not be available on the target machine.
> What is that particular "sh" command trying to run?
>

I'm not sure what the command DeeJay is trying to run is. However -
the bug on rubyforge (http://rubyurl.com/dvp) happened when the user
ran:

rake examples_with_rcov --trace
(standing in the rspec svn root directory)

This results in the following being passed to sh:

"rcov --exclude \"lib\\/spec\\/.*\" -Ilib
\"/Users/aslakhellesoy/scm/rspec/trunk/bin/spec\"    --
\"examples/airport_spec.rb\" \"examples/bdd_framework_spec.rb\"
\"examples/custom_method_spec.rb\" \"examples/file_accessor_spec.rb\"
\"examples/io_processor_spec.rb\" \"examples/mocking_spec.rb\"
\"examples/stack_spec.rb\" \"examples/sugar_spec.rb\"
\"examples/test_case_spec.rb\""
{:verbose=>true, :noop=>false}

(I added "p *cmd" to the top of rake's sh method to see this)

Question to DeeJay:
1) What exactly should we do to reproduce this on a windows box?
2) Does the spec task behave badly for both plain ruby and rcov usage?

Aslak

> --
> --
> -- Jim Weirich    jim at weirichhouse.org     http://onestepback.org
> -----------------------------------------------------------------
> "Beware of bugs in the above code; I have only proved it correct,
> not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From aslak.hellesoy at gmail.com  Mon Aug 21 18:06:37 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 22 Aug 2006 00:06:37 +0200
Subject: [Rspec-devel] Feature requests
In-Reply-To: <44EA1D6B.3040303@redfivellc.com>
References: <44E274A2.3040001@redfivellc.com>
	<8d961d900608201931s644435fco1f113f7cc49bb72b@mail.gmail.com>
	<44EA1D6B.3040303@redfivellc.com>
Message-ID: <8d961d900608211506n48c4b08hde5c2d777d903a9a@mail.gmail.com>

On 8/21/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
> aslak hellesoy wrote:
> > On 8/16/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
> >
> >> I've run into a couple of minor irritations working with rspec recently.
> >>
> >> Mostly, I really like working with rspec.  Tidy DSL, good Rake
> >> integration, built in mocks and coverage are all major boons.  But:
> >>
> >> proc.should_raise and should_not_raise both result in printing the
> >> backtrace of the the RSpec failure they raise, rather than the
> >> unexpected exception that was raised.  This leads to a fair amount of
> >> extra dev time spent hunting down the error, where a message along the
> >> lines of "proc should not have raised, but instead raised:" and the
> >> whole exception (not the standard Ruby "...400 lines skipped that
> >> include the line you care about..." :)
> >>
> >>
> >
> > Could you please submit an RFE for this? Preferrably in the form of a
> > patch that we can apply and reproduce what you're getting. I'm not
> > sure how you're getting 400 lines of trace. Are you on Rails? In that
> > case - you can write the patch against the semo app under
> > vendor/rspec_on_rails.
> >
> I'll certainly submit an RFE.  I'm not sure I follow the idea of
> submitting a patch though - I could probably bung up a spec file that
> would demonstrate what I'm talking about.  And I could probably submit a
> patch that would produce the behavior I'd like.  Do you mean both?
>

1) get the latest rspec sources with subversion
(http://rubyforge.org/scm/?group_id=797)
2) make sure you can build it successfully (rake pre_commit). See README.
3) modify your local working copy until it exhibits the misbehaviour
you're talking about
4) svn diff > reproduce_stacktrace_bug.patch
5) create a new ticket at rubyforge and attach the patch file

So what do you do in step 3? The simplest is probably to modify some
of the files under examples (or maybe add a new one) and run bin/spec
examples until you get the ugly stack traces you're talking about.

> The "400 lines" was a bit of an exaggeration.  But I do a fair about of
> DRb programming, which produces pretty deep call chains, which get cored
> by the ruby interpreter when they're printed.  The standard (read:
> matz's) solution is to wrap the whole app in a "rescue Exception => e"
> and print the backtrace explicitly.  For development, this winds up
> being incredibly handy, and it'd be nice if spec provided this behavior
> on backtraces.
>

I'm still confused. You do want stack traces to be printed yes? But
you want parts of the stack trace to be stripped away? Again - RSpec
already tries to strip parts of it away. If there are still parts of
the stack trace you would like RSpec to strip away we need some code
to reproduce it (and add extra stripping logic).

> >> Contrarywise, other expectations also print their entire backtrace,
> >> which is rarely helpful and consumes a fair amount of scrollback and
> >> attention.
> >>
> >>
> >
> > Really? We're stripping off most of the backtraces already. See spec's
> > -b command line option. How can I reproduce a long backtrace as you
> > describe?
> >
> Under -f s, spec generates output of the form
>
> A Context
> - should do the right thing (FAILED - 1)
>
> 1) Spec::Api::ExpectionNotMet -
> "a thing" should be "another thing"
> <Backtrace goes here>
>
> without -b.  Forgive inconsistencies in the sample output: it's typed
> from memory.
>
> >> Finally hash.should_has_key(:key) fails (<hash> doesn't respond to has?)
> >> as do similar predicates (i.e. anything with an underscore).
> >>
> >>
> >
> > You can do this with should_include(:key)
> >
> Certainly, but while I've come to like the way that TDD/BDD drives
> development in ways you wouldn't expect, a don't know if I like the idea
> of never writing a two word predicate again.  Hash#has_key? was a good
> example, but hardly the only one.
>

I see what you mean. It would be even better if we could say:
{:foo => :bar}.should_have_key(:foo)

We'd have to add some grammatical rules to recognise common infinitive
verbs and try out their present form. Dave Astels actually showed me a
hack to do that yesterday.

This would be general, so if you have a method is_funny? then you can
say should_be_funny etc.

Cheers,
Aslak

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

From smartgpx at gmail.com  Tue Aug 22 03:46:29 2006
From: smartgpx at gmail.com (DeeJay)
Date: Tue, 22 Aug 2006 08:46:29 +0100
Subject: [Rspec-devel] Rake Task - not for Windows ?
Message-ID: <533048b70608220046r69b12743kcfcb2d0cfff3a03c@mail.gmail.com>

"Question to DeeJay:
1) What exactly should we do to reproduce this on a windows box?
2) Does the spec task behave badly for both plain ruby and rcov usage?"

To answer your questions first -

1)  As documented in #4891

>  rake examples_with_rcov --trace

where rakefile contains  the example given
in the first reversed-out code box at
http://rspec.rubyforge.org/tools/rcov.html

(rcov is installed on the system and produces results in coverage if invoked
from the command line.)

The response, ignoring the file-selection report, is:

rake aborted!
undefined method `exitstatus' for nil:NilClass
C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:722:in
`sh'
C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:729:in
`sh'
C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in
`sh'
C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rspec-0.6.0/lib/spec/rake/spectask.rb:140:in
`run'
[..further backtrace suppressed]


2) This only happens when t.rcov = true is set


Some background.

Assume (as a 'user-story' if you like) that I am coming to this with little
previous
experience or understanding of rake, rcov or rspec.

Refer to http://rspec.rubyforge.org/tools/rcov.html

What is the nature of the code in the reversed-out box? It looked like Ruby,
so
I tried passing it to ruby. Silence. It starts with "require 'rake' ", so it
didn't
seem logical to try to pass it to rake, but I tried. Silence. So I started
clicking through
http://rspec.rubyforge.org/rdoc/classes/Spec/Rake/SpecTask.html
and when I got to the source for 'run' and could not find 'sh' documented in
fxri I assumed I had found the  reason for what I perceived to be an
incompatibility between SpecTask and Windows.

A note with the sample task documenting how to run it would make
life easier for newcomers.  :-)}

I now know, by reference to bug #4891, that I have to invoke rake
with an argument that is extracted from a text string buried half-way
down the sample code. (I think I can see why, but I hope you can
see why it isn't obvious to a newcomer?)


Thanks for listening -

David/DeeJay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060822/3a7c9e5d/attachment.html 

From aslak.hellesoy at gmail.com  Tue Aug 22 06:48:09 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 22 Aug 2006 12:48:09 +0200
Subject: [Rspec-devel] Rake Task - not for Windows ?
In-Reply-To: <533048b70608220046r69b12743kcfcb2d0cfff3a03c@mail.gmail.com>
References: <533048b70608220046r69b12743kcfcb2d0cfff3a03c@mail.gmail.com>
Message-ID: <8d961d900608220348r19da4f82l83bf28f85ccfb218@mail.gmail.com>

On 8/22/06, DeeJay <smartgpx at gmail.com> wrote:
>
> "Question to DeeJay:
> 1) What exactly should we do to reproduce this on a windows box?
> 2) Does the spec task behave badly for both plain ruby and rcov usage?"
>
> To answer your questions first -
>
> 1)  As documented in #4891
>
> >  rake examples_with_rcov --trace
>
> where rakefile contains  the example given
> in the first reversed-out code box at
> http://rspec.rubyforge.org/tools/rcov.html
>
> (rcov is installed on the system and produces results in coverage if invoked
> from the command line.)
>
> The response, ignoring the file-selection report, is:
>
> rake aborted!
> undefined method `exitstatus' for nil:NilClass
> C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:722:in
> `sh'
> C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:729:in
> `sh'
> C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake.rb:812:in
> `sh'
> C:/OneClickRuby/ruby/lib/ruby/gems/1.8/gems/rspec-0.6.0/lib/spec/rake/spectask.rb:140:in
> `run'
> [..further backtrace suppressed]
>
>
> 2) This only happens when t.rcov = true is set
>

Ok,  I think I know what causes the bug. Ruby/Rubygems/Windows has a
"bug" that makes it impossible to run a shell script without its
extension. On Windows, there is no rcov script (but an rcov.cmd or
rcov.bat one) and telling ruby to run rcov won't work. The error
message that is seen is a sideeffect and doesn't really help
diagnosing this.

I think we can fix this in the next release (using "ruby -S rcov"
instead of "rcov") to fire up rcov.

In the meanwhile, try to hack your spectask.rb and change the line:

  interpreter = @rcov ? "rcov" : "ruby"

to this:

  interpreter = @rcov ? "rcov.cmd" : "ruby"

or possibly

  interpreter = @rcov ? "rcov.bat" : "ruby"

Hope this helps.

>
> Some background.
>
> Assume (as a 'user-story' if you like) that I am coming to this with little
> previous
> experience or understanding of rake, rcov or rspec.
>
> Refer to http://rspec.rubyforge.org/tools/rcov.html
>
> What is the nature of the code in the reversed-out box? It looked like Ruby,
> so
> I tried passing it to ruby. Silence. It starts with "require 'rake' ", so it
> didn't
> seem logical to try to pass it to rake, but I tried. Silence. So I started
> clicking through
> http://rspec.rubyforge.org/rdoc/classes/Spec/Rake/SpecTask.html
> and when I got to the source for 'run' and could not find 'sh' documented in
> fxri I assumed I had found the  reason for what I perceived to be an
> incompatibility between SpecTask and Windows.
>
> A note with the sample task documenting how to run it would make
> life easier for newcomers.  :-)}
>
> I now know, by reference to bug #4891, that I have to invoke rake
> with an argument that is extracted from a text string buried half-way
> down the sample code. (I think I can see why, but I hope you can
> see why it isn't obvious to a newcomer?)
>

I have updated the website documentation in subversion so it's more
newcomer friendly. It will be on the website after the next release
(we only upload the website when we release a new version of RSpec).

>
> Thanks for listening -
>

Thanks for helping us improve things.

Aslak

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

From smartgpx at gmail.com  Tue Aug 22 08:26:44 2006
From: smartgpx at gmail.com (DeeJay)
Date: Tue, 22 Aug 2006 13:26:44 +0100
Subject: [Rspec-devel] Rake Task - not for Windows ?
Message-ID: <533048b70608220526k4dd37b54k659326cb3b87cb50@mail.gmail.com>

OK - getting there. 3 quick things:

1] Changing line 97 of spectask.rb to refer to rcov.cmd does the trick.
(That's the name of the
stub or helper that gets planted in ruby/bin )

2] Possibly you would expect - but I didn't - that specifying an attribute
of rcov = true is
incompatible with specifying a value for spec_opts = .  (I think the
argument gets passed
to rcov, which does not know how to interpret it.)

3] A suggestion. If you make the default value of the name attribute of the
task equal to ":default"
(in lines 70 and 90 of spectask.rb ) then it is possible to write a
'simplest rakefile' using
 Spec::Rake::SpecTask.new  do |t| ... end   [ie. with no argument to new]
which can then be executed by just saying
 > rake [ Return ]

David/DeeJay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060822/6f54ae82/attachment.html 

From wayne at larsen.st  Tue Aug 22 18:15:15 2006
From: wayne at larsen.st (Wayne Larsen)
Date: Tue, 22 Aug 2006 18:15:15 -0400
Subject: [Rspec-devel] Selenium Integration
Message-ID: <ca8699b60608221515l24e023b0m2c8e38e067d4592@mail.gmail.com>

Hi All,

In my understanding, using selenium to test your app (I'm speaking
about rails specifically here) can be done several ways:

1. With the selenium_on_rails plugin.  This expands the rails test
directory to include a directory for selenium tests.  This plugin also
includes RSelenese, which is a ruby dsl that evals to the selenium
table testing language.  This allows you to write something like:

open '/admin/users'
click "link=New User"
wait_for_text_present "Login Fields"
type "users_login", "Marie"

The only structure to these tests is based on directories and files.
Directories define a suite, and each test gets its own file.

2. Using selenium-rc and the given framework.  Aslak posted an example
of this using rspec that looked something like:

context "A running iteration" do
  setup do
    @sel = Selenium::SeleneseInterpreter.new("localhost", 4444,
"*firefox", "http://localhost:3000", 5000)
    @sel.start
  end

  specify "should allow finishing and tag all stages and stories" do
    @sel.open_and_wait "http://localhost:3000/iterations/1"
    # TODO: verify that the iteration is still 'running' (visual clue)
    @sel.click_and_wait "link=Iteration Status"
    @sel.click_and_wait "link=Finish this iteration"
    # TODO: verify that the iteration is 'finished' (visual clue)
  end

  teardown do
    @sel.stop
  end
end

This allows you to make use of rspec's framework for running your
Specs/Behaviours/Examples.  The downsides to this is that the language
for writing tests is not at all like rspec's elegant language, and for
me, I've found that the runtime overhead of selenium-rc is just not
practical for quick iterations.

3. Other options, such as Rubinium (I've only briefly looked at this)
that provides a method of compiling ruby code to selenium test's,
using a dsl pretty much equal to selenium's.

A better way?

OK, given that, and the fact that I'm pretty new to both rspec and
selenium, I would like to propose a different integration approach.
Building off the selenium_on_rails plugin, one should be able to
define a new type of format (say .specenese for argument) that would
look like a normal rspec specification.  The spec would then translate
to the selenese format that can then be executed.  So, essentially,
combining the rselenese format with rspec, to produce something
handwavingly like:

context "Test create user" do
  specify "should create a user when given valid user information" do
    open '/admin/users' and wait
    page.should_include "All Users"
    click 'link=New User'
    fill {:users=>{:login=>'rob', :firstname=>'Rob', :lastname=>'Gordon'}}
  end
end

By taking advantage of rails conventions and rspec's capabilities, a
higher level functional api could be built.  I've started looking into
this, and believe it shouldn't be extremely difficult to do, but maybe
I'm missing something.

Also, with the api/dsl in place, it might be possible to switch
between browser driven and remote control modes based on some
configuration.

So questions:
Does this make sense?
Is anyone pursuing anything like this?
Is there a better way that I haven't seen?

I might keep poking away at this if it has any merit, but in the
meantime I need to get back to building the app in the first place, in
which case the best option does seem to be the
rselenese/selenium_on_rails way, which is not really tied to
Test::Unit or rspec.

Regards,
Wayne

btw, pardon me for using the t word in the above.  I am new to both
rspec and bdd -- the reason I started investigating this in the first
place, is that it seems that it should be possible for a non technical
user to write the functional specs in the first place, and the easier
that can be done, the better.

From aslak.hellesoy at gmail.com  Tue Aug 22 18:57:57 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 23 Aug 2006 00:57:57 +0200
Subject: [Rspec-devel] ANN: RSpec 0.6.1
Message-ID: <8d961d900608221557y4d7e35feu2ad3e420c2c64464@mail.gmail.com>

Hi all

Go grab the latest release of RSpec (gem install rspec). It has 9 bug
fixes and some extra features, most notably a working
rails_spec_runner, which allows you to run your Rails specs *fast*.

Release notes: http://rubyforge.org/frs/shownotes.php?release_id=6590

Cheers,
The RSpec team

From aslak.hellesoy at gmail.com  Tue Aug 22 19:12:30 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 23 Aug 2006 01:12:30 +0200
Subject: [Rspec-devel] Selenium Integration
In-Reply-To: <ca8699b60608221515l24e023b0m2c8e38e067d4592@mail.gmail.com>
References: <ca8699b60608221515l24e023b0m2c8e38e067d4592@mail.gmail.com>
Message-ID: <8d961d900608221612p74ded5c3iacff43b8633c05b4@mail.gmail.com>

On 8/23/06, Wayne Larsen <wayne at larsen.st> wrote:
> Hi All,
>
> In my understanding, using selenium to test your app (I'm speaking
> about rails specifically here) can be done several ways:
>
> 1. With the selenium_on_rails plugin.  This expands the rails test
> directory to include a directory for selenium tests.  This plugin also
> includes RSelenese, which is a ruby dsl that evals to the selenium
> table testing language.  This allows you to write something like:
>
> open '/admin/users'
> click "link=New User"
> wait_for_text_present "Login Fields"
> type "users_login", "Marie"
>
> The only structure to these tests is based on directories and files.
> Directories define a suite, and each test gets its own file.
>
> 2. Using selenium-rc and the given framework.  Aslak posted an example
> of this using rspec that looked something like:
>
> context "A running iteration" do
>   setup do
>     @sel = Selenium::SeleneseInterpreter.new("localhost", 4444,
> "*firefox", "http://localhost:3000", 5000)
>     @sel.start
>   end
>
>   specify "should allow finishing and tag all stages and stories" do
>     @sel.open_and_wait "http://localhost:3000/iterations/1"
>     # TODO: verify that the iteration is still 'running' (visual clue)
>     @sel.click_and_wait "link=Iteration Status"
>     @sel.click_and_wait "link=Finish this iteration"
>     # TODO: verify that the iteration is 'finished' (visual clue)
>   end
>
>   teardown do
>     @sel.stop
>   end
> end
>
> This allows you to make use of rspec's framework for running your
> Specs/Behaviours/Examples.  The downsides to this is that the language
> for writing tests is not at all like rspec's elegant language, and for
> me, I've found that the runtime overhead of selenium-rc is just not
> practical for quick iterations.
>
> 3. Other options, such as Rubinium (I've only briefly looked at this)
> that provides a method of compiling ruby code to selenium test's,
> using a dsl pretty much equal to selenium's.
>
> A better way?
>
> OK, given that, and the fact that I'm pretty new to both rspec and
> selenium, I would like to propose a different integration approach.
> Building off the selenium_on_rails plugin, one should be able to
> define a new type of format (say .specenese for argument) that would
> look like a normal rspec specification.  The spec would then translate
> to the selenese format that can then be executed.  So, essentially,
> combining the rselenese format with rspec, to produce something
> handwavingly like:
>
> context "Test create user" do
>   specify "should create a user when given valid user information" do
>     open '/admin/users' and wait
>     page.should_include "All Users"
>     click 'link=New User'

I'd prefer:
click :link => "New User"

>     fill {:users=>{:login=>'rob', :firstname=>'Rob', :lastname=>'Gordon'}}

What would this translate to in say, Selenium FIT-style HTML?

>   end
> end
>
> By taking advantage of rails conventions and rspec's capabilities, a
> higher level functional api could be built.  I've started looking into
> this, and believe it shouldn't be extremely difficult to do, but maybe
> I'm missing something.
>
> Also, with the api/dsl in place, it might be possible to switch
> between browser driven and remote control modes based on some
> configuration.
>
> So questions:
> Does this make sense?

As the writer of the initial rselenese and also an early selenium
contributor I should be able to tell you. But the fact is I don't
remember :-)

But it sure would be sweet with a nicer ruby API that integrates well
with RSpec.
It's fairly easy to add new helper methods such as open, click etc. to
RSpec in a spec_helper. Check out how it's done in the RSpec on Rails
spec_helper.rb

> Is anyone pursuing anything like this?

Not that I know of

> Is there a better way that I haven't seen?
>

It's hard to say before you try it ;-)

> I might keep poking away at this if it has any merit, but in the
> meantime I need to get back to building the app in the first place, in
> which case the best option does seem to be the
> rselenese/selenium_on_rails way, which is not really tied to
> Test::Unit or rspec.
>

Let us know how it goes. My main gripe with all of the in-browser
tools out there (selenium, watir, sahi) is the lack of AJAX support.
There is a workaround for Selenium (google it). If that could be made
more elegant with a ruby layer it would be sweet.

> Regards,
> Wayne
>
> btw, pardon me for using the t word in the above.  I am new to both
> rspec and bdd -- the reason I started investigating this in the first
> place, is that it seems that it should be possible for a non technical
> user to write the functional specs in the first place, and the easier
> that can be done, the better.

You're forgiven ;-)

Aslak

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

From dastels at daveastels.com  Tue Aug 22 21:16:44 2006
From: dastels at daveastels.com (David Astels)
Date: Tue, 22 Aug 2006 22:16:44 -0300
Subject: [Rspec-devel] ruby 1.8.5 and edge rails
Message-ID: <E62AD8AD-EFE8-460A-8A11-2B593219EBDD@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If you are using Ruby 1.8.5 and EdgeRails you might want to hack your  
copy of /usr/local/bin/spec to surpress warnings.  The first line  
should be changed to:

	#!/usr/bin/env ruby -W0

At least until the rails crew get things cleaned up.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE66x9auez/L4x7g4RAh2xAJ9BCYx5vW6K8uaodKE2moinwh4YpgCgggpE
CdUXn99R9i3YhsvnoaGwq40=
=LIe/
-----END PGP SIGNATURE-----

From smartgpx at gmail.com  Wed Aug 23 03:19:47 2006
From: smartgpx at gmail.com (DeeJay)
Date: Wed, 23 Aug 2006 08:19:47 +0100
Subject: [Rspec-devel] RSpec 0.6.1
Message-ID: <533048b70608230019t2f4421a8i77c39cc5dc7a4395@mail.gmail.com>

re: V-0.6.1

Documentation clarified, rake task for rcov runs on Windows, handling of
options in rake task made sane. Nice! Thank you.

Because it is part of the role of a user to never be satisfied [ :-)} ],
I am about to lodge a ticket relating to rake aborting noisily (on Windows
at least) if rspec fails a specification. That's cosmetic/distracting rather

than a functional error.

David/DeeJay
Leicester, UK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060823/1fda7593/attachment.html 

From smartgpx at gmail.com  Fri Aug 25 12:38:28 2006
From: smartgpx at gmail.com (DeeJay)
Date: Fri, 25 Aug 2006 17:38:28 +0100
Subject: [Rspec-devel] RSpec 0.6.1 [RESCIND]
Message-ID: <533048b70608250938o18cd943eme8027c4c044b05ec@mail.gmail.com>

Positive comments should stand.

'Noisy' failure of rake task is already dealt with by an attribute
fail_on_error
which defaults to true, but if set false would probable fix my problem.

Feel free to delete or close the Tracker bug report.

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

From lachiec at gmail.com  Fri Aug 25 21:16:50 2006
From: lachiec at gmail.com (Lachie)
Date: Sat, 26 Aug 2006 11:16:50 +1000
Subject: [Rspec-devel] Expecting Rails behaviour
Message-ID: <2c5e719e0608251816m371d8535ia7a269254fa4e185@mail.gmail.com>

Did you see the "Ruby, Rails, Test::Rails Cheat Sheet" at
http://nubyonrails.com/articles/read/741 by Geoffrey Grossenbach?

Despite what I think about these cheatsheets in general, this one
presents us with a golden opporunity.

We can use it as a check list of, or discussion pole for the state of
specifying Rails behaviour.

After we've worried/finessed the list below, and/or rspec-on-rails's
capabilities, perhaps we can create a cheatsheet or phrasebook of our
own as a marketing exercise. Although using rspec as a direct T::U
replacement isn't the goal, the translation of assertions into
expectations is quite clear and demonstrates one of rspec's greatest
strengths. Publishing something like a pretty cheatsheet might grab
some people's attention.

I've marked the Test::Unit assertions as TU and the rspec equivalent
as RS. Obviously my translations are not gospel, but I've added them
as a starting point based on my understanding. This also highlights
areas where the translation isn't clear.

Although they mostly cover the expectation api, there's some crossover
with the context api in that rspec-on-rails sets up some Controller
related gear by hooking the context api. And if I have to use "Test"
while talking about RSpec, its because some of the objects we reuse
from rails are actually called TestSomething :).

I've added a bit of background, sorry if its extraneous for you.


Test::Unit Assertions
=====================
All these are covered by rspec in the most wonderful of ways

TU assert boolean
RS boolean.should_be true
RS boolean.should_satisfy {|arg| ... }

TU assert_equal expected, actual
RS actual.should_be expected

TU assert_raise *args, &block
TU [deprecated] assert_raises *args, &block
RS lambda { ... }.should_raise *args

TU assert_instance_of klass, object
RS object.should_be_an_instance_of klass

TU assert_nil object
RS object.should_be nil

TU assert_kind_of klass, object
RS object.should_be_kind_of klass

TU assert_respond_to object, method
RS object.should_respond_to :method

TU assert_match pattern, string
RS pattern.should_match string

TU assert_same expected, actual
RS actual.should_be expected

TU assert_operator object1, operator, object2
RS object1.should_satisfy {|o| o <operator> object2}

TU assert_nothing_raised *args
RS lambda { ... }.should_not_raise *args

TU assert_not_same expected, actual
RS actual.should_not_be expected

TU assert_not_equal expected, actual
RS actual.should_not_equal expected

TU assert_not_nil object
RS object.should_not_be nil

TU assert_no_match regexp, string
RS regexp.should_not_match string

TU assert_throws expected_symbol, &proc
RS proc.should_throw expected_symbol

TU assert_nothing_thrown &proc
RS proc.should_not_throw

TU assert_in_delta expected_float, actual_float, delta
RS actual_float.should_be_close expected_float, delta

TU assert_send send_array
RS not sure why this one is necessary, but a direct translation would be:
RS send_array[0].send(*send_array[1..-1]).should_be true

Rails assertions
==========
These assertions hook into rails by
* instantiating an instance of the Controller under test
* instantiating some test-versions of Response, Request etc.
* simulating the request cycle via convenience methods such as get, post etc.

Rspec-on-rails does things pretty much the same way, but tends to
specify behaviour by interrogating the Test-version objects directly,
rather than wrapping them up in asserts. There are plenty of places
where we could monkey-or-officially patch some convenience or
linguistic optimisation into ShouldHelper.

TU assert_response type
RS @response.should_be_success

TU assert_redirected_to options = {}
RS @response.should_be_redirect
RS @response.should_redirect_match something

TU assert_template expected
RS @response.should_render expected

TU assert_recognizes expected_options, path, extras={}
TU assert_generates expected_path, options, defaults={}, extras = {}
TU assert_routing path, options, defaults={}, extras={}

TU assert_tag *opts
RS @response.should_have_tag *opts

TU assert_no_tag *opts
RS @response.should_not_have_tag *opts

TU assert_dom_equal expected, actual
TU assert_dom_not_equal expected, actual

TU assert_valid record
RS record.should_be_valid ** doesn't work!

Test::Rails assertions
===========
Part of ZenTest. It splits so-called "functional" testing into just
Controller and just View.

[Controller]
TU assert_assigned           ivar, value = NOTHING
RS assigns('ivar').should_not_be nil
*deny_assigned
RS assigns('ivar').should_be nil

TU assert_content_type       type, message = nil
RS @response.header['content-type'].should_equal type

TU assert_flash              key, content
RS @flash.should_include key

[View]
I've successfully integrated and used Test::Rails::ViewTestCase with
rspec-on-rails (I can post the code if you're interested). However, I
wasn't specifying HTML views, so I'm not sure what the best way to
handle these assertions is. Has anyone looked into using Hpricot?

TU assert_image              src
TU assert_error_on           field, type
TU assert_field              form_action, type, model, column, value = nil
TU assert_input              form_action, type, name, value = nil
TU assert_label              form_action, name, include_f = true
TU assert_links_to           href, content = nil
TU * deny_links_to
TU assert_multipart_form     form_action
TU assert_post_form          form_action
TU assert_select             form_action, model, column, options
TU assert_submit             form_action, value
TU assert_tag_in_form        form_action, options
TU * deny

[General]
Again, no-brainers for rspec!

TU assert_empty              obj
RS obj.should_be_empty
TU * deny_empty
RS obj.should_not_be_empty

TU assert_includes           obj, item, message = nil
RS obj.should_include item
TU * deny_includes
RS obj.should_not_include item


-- 
Lachie
http://lachie.info/
http://www.flickr.com/photos/lachie/

From dastels at daveastels.com  Sat Aug 26 02:17:49 2006
From: dastels at daveastels.com (David Astels)
Date: Sat, 26 Aug 2006 03:17:49 -0300
Subject: [Rspec-devel] latest rSpec tutorial
In-Reply-To: <66655060-012A-42BF-93F8-218BA17A928D@agileevolved.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
	<6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
	<66655060-012A-42BF-93F8-218BA17A928D@agileevolved.com>
Message-ID: <5D14877B-F373-44C1-83F7-8238A08931A9@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

More comments from DeeJay rolled in: http://blog.daveastels.com/files/ 
mastermind-ruby.pdf

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE7+eOauez/L4x7g4RAggYAKCIzHokQgyMUUQtynDOzzMXe4H0XgCfeHKO
kIOTPtZANNEUFD7Lddb+6ys=
=tHNi
-----END PGP SIGNATURE-----

From dastels at daveastels.com  Sat Aug 26 02:19:08 2006
From: dastels at daveastels.com (David Astels)
Date: Sat, 26 Aug 2006 03:19:08 -0300
Subject: [Rspec-devel] rSpec QuickRef
In-Reply-To: <66655060-012A-42BF-93F8-218BA17A928D@agileevolved.com>
References: <44DCFFED.7010207@redfivellc.com>	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
	<6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
	<66655060-012A-42BF-93F8-218BA17A928D@agileevolved.com>
Message-ID: <89CBEA5E-69B3-4304-8E73-15C9BF39EADC@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here's a quick ref card I've been working on for rSpec (general, not  
rails specific).  Let me know what you think

http://blog.daveastels.com/files/rSpec_QuickRef.pdf

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE7+feauez/L4x7g4RAoLAAKDe7TESf1kVoFHfeY2YPDuT67UifwCeI5Ul
NFt7JVcu8BUJs6nDKrJoFy8=
=BlDk
-----END PGP SIGNATURE-----

From luke at agileevolved.com  Sat Aug 26 07:34:39 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Sat, 26 Aug 2006 12:34:39 +0100
Subject: [Rspec-devel] Expecting Rails behaviour
In-Reply-To: <2c5e719e0608251816m371d8535ia7a269254fa4e185@mail.gmail.com>
References: <2c5e719e0608251816m371d8535ia7a269254fa4e185@mail.gmail.com>
Message-ID: <1734477C-F250-4157-89F1-95D8660AD989@agileevolved.com>

Lachie

Take a look at my blog post here:

http://www.lukeredpath.co.uk/2006/7/7/testing-your-rails-views-with- 
hpricot

I'd love to see something like this rolled into RSpec.

Cheers
Luke

> I've successfully integrated and used Test::Rails::ViewTestCase with
> rspec-on-rails (I can post the code if you're interested). However, I
> wasn't specifying HTML views, so I'm not sure what the best way to
> handle these assertions is. Has anyone looked into using Hpricot?
>
> TU assert_image              src
> TU assert_error_on           field, type
> TU assert_field              form_action, type, model, column,  
> value = nil
> TU assert_input              form_action, type, name, value = nil
> TU assert_label              form_action, name, include_f = true
> TU assert_links_to           href, content = nil
> TU * deny_links_to
> TU assert_multipart_form     form_action
> TU assert_post_form          form_action
> TU assert_select             form_action, model, column, options
> TU assert_submit             form_action, value
> TU assert_tag_in_form        form_action, options
> TU * deny
>
> [General]
> Again, no-brainers for rspec!
>
> TU assert_empty              obj
> RS obj.should_be_empty
> TU * deny_empty
> RS obj.should_not_be_empty
>
> TU assert_includes           obj, item, message = nil
> RS obj.should_include item
> TU * deny_includes
> RS obj.should_not_include item
>
>
> -- 
> Lachie
> http://lachie.info/
> http://www.flickr.com/photos/lachie/
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Sat Aug 26 08:13:31 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 26 Aug 2006 14:13:31 +0200
Subject: [Rspec-devel] RSpec 0.6.1 [RESCIND]
In-Reply-To: <533048b70608250938o18cd943eme8027c4c044b05ec@mail.gmail.com>
References: <533048b70608250938o18cd943eme8027c4c044b05ec@mail.gmail.com>
Message-ID: <8d961d900608260513t40be0e9i33ae45ce9da9ca0@mail.gmail.com>

On 8/25/06, DeeJay <smartgpx at gmail.com> wrote:
>
>
> Positive comments should stand.
>
> 'Noisy' failure of rake task is already dealt with by an attribute
> fail_on_error
> which defaults to true, but if set false would probable fix my problem.
>
> Feel free to delete or close the Tracker bug report.
>

Which one?

Aslak

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

From dchelimsky at gmail.com  Sat Aug 26 14:57:43 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 26 Aug 2006 13:57:43 -0500
Subject: [Rspec-devel] back from vacation
Message-ID: <57c63afe0608261157rf986ccbhdd3aae5aa01c4caf@mail.gmail.com>

Hi all. Sorry for the silence over the last couple of weeks but I just
got back from vacation. As you may imagine I have a ton to catch up
on, but I'll be chiming in on some of the threads over the next few
days.

Cheers,
David

From aslak.hellesoy at gmail.com  Sat Aug 26 16:06:14 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 26 Aug 2006 22:06:14 +0200
Subject: [Rspec-devel] [Rspec-users] back from vacation
In-Reply-To: <57c63afe0608261157rf986ccbhdd3aae5aa01c4caf@mail.gmail.com>
References: <57c63afe0608261157rf986ccbhdd3aae5aa01c4caf@mail.gmail.com>
Message-ID: <8d961d900608261306o11540229vdd9d06fea5b71c8f@mail.gmail.com>

On 8/26/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> Hi all. Sorry for the silence over the last couple of weeks but I just
> got back from vacation. As you may imagine I have a ton to catch up
> on, but I'll be chiming in on some of the threads over the next few
> days.
>

Welcome back David.

Could you please take a look at http://rubyurl.com/4HT

Cheers,
Aslak

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

From aslak.hellesoy at gmail.com  Sat Aug 26 16:23:57 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 26 Aug 2006 22:23:57 +0200
Subject: [Rspec-devel] ANN: RSpec 0.6.2
Message-ID: <8d961d900608261323t60004cf8qcc2d715584b54590@mail.gmail.com>

I just released RSpec 0.6.2

Hopefully this fixes the couple of glitches that went into 0.6.1 - the
RSpec rake task was heavily refactored in 0.6.1 and didn't work
properly when packaged as a gem. This should be fixed now. Holler if
things are still broken.

Cheers,
Aslak

From dchelimsky at gmail.com  Sat Aug 26 18:11:22 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 26 Aug 2006 17:11:22 -0500
Subject: [Rspec-devel] warnings when running rake test
Message-ID: <57c63afe0608261511jd3ad5e8w7fb97b6b1a5aa1bc@mail.gmail.com>

The test task is currently set to show all the warnings. I'd like to
either turn them off or modify code to get rid of them.

Preferences?

David

From aslak.hellesoy at gmail.com  Sat Aug 26 19:19:13 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 27 Aug 2006 01:19:13 +0200
Subject: [Rspec-devel] warnings when running rake test
In-Reply-To: <57c63afe0608261511jd3ad5e8w7fb97b6b1a5aa1bc@mail.gmail.com>
References: <57c63afe0608261511jd3ad5e8w7fb97b6b1a5aa1bc@mail.gmail.com>
Message-ID: <8d961d900608261619l726c5685p4d11db9bc3359a4e@mail.gmail.com>

On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> The test task is currently set to show all the warnings. I'd like to
> either turn them off or modify code to get rid of them.
>

I thought I had got rid of all the warnings now.

> Preferences?
>

Keep the warning flag on and keep our code clean.

Aslak

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

From eero.saynatkari at kolumbus.fi  Sat Aug 26 19:25:02 2006
From: eero.saynatkari at kolumbus.fi (E S)
Date: Sun, 27 Aug 2006 2:25:02 +0300
Subject: [Rspec-devel] should_output proof-of-concept
Message-ID: <20060826232502.WUEX4315.fep02-app.kolumbus.fi@smtp.kolumbus.fi>

Hi! Sorry if this is the wrong place--and apologies that
this is not in patch format (I do not have SVN access and
did not want to try to patch from 0.6.1). I currently just
have this hacked in a helper lib I #require for the specs.
I was briefly pondering about something similar for input
but that is more of a context than specification thing.

Thoughts?

# Usage examples:

 lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output "foo\n"
 lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output /foo\n/

 lambda {UI.mainloop {|ui| ui.error 'foo'}}.should_output "foo\n", :to => '$stderr'

# Code:

# Modify RSpec a little
module Spec
  class ShouldHelper

    # Verify output from block is expected
    def output(expected, io = {:to => '$stdout'})
      to = io[:to]

      # Store the old value
      eval "#{to}, old_to = StringIO.new(''), #{to}"
       
      @target.call 
      eval(to).rewind
      output = eval(to).read 

      # Match up
      case expected
        when Regexp
          output.should_match expected
        else 
          output.should_equal expected
      end                             # case expected
      
    # Clean up
    ensure
      eval "#{to} = old_to"
    end                               # output()
  end                                 # ShouldHelper
end                                   # Spec


From dchelimsky at gmail.com  Sat Aug 26 20:54:40 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sat, 26 Aug 2006 19:54:40 -0500
Subject: [Rspec-devel] warnings when running rake test
In-Reply-To: <8d961d900608261619l726c5685p4d11db9bc3359a4e@mail.gmail.com>
References: <57c63afe0608261511jd3ad5e8w7fb97b6b1a5aa1bc@mail.gmail.com>
	<8d961d900608261619l726c5685p4d11db9bc3359a4e@mail.gmail.com>
Message-ID: <57c63afe0608261754p49241582hedf12edeb9ab2bfd@mail.gmail.com>

On 8/26/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > The test task is currently set to show all the warnings. I'd like to
> > either turn them off or modify code to get rid of them.
> >
>
> I thought I had got rid of all the warnings now.
>
> > Preferences?
> >
>
> Keep the warning flag on and keep our code clean.

I agree in spirit, but what "clean" means is subjective. For example,
one warning we get is in reporter.rb:

        return @end_time - @start_time unless (@end_time.nil? or
@start_time.nil?)

This line of code seems perfectly clean, but a warning is generated
stating that @end_time is not initialized. Cleaning this up would
require the following in the initialize method:

  @start_time = nil
  @end_time = nil

Perhaps that is more clear, but it is also more verbose.

Another weird one is in /test/spec/test_to_spec/testfiles/test_unit_api_test.rb:

warning: method redefined; discarding old setup

Wassup w/ that?



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

From smartgpx at gmail.com  Sun Aug 27 03:17:22 2006
From: smartgpx at gmail.com (DeeJay)
Date: Sun, 27 Aug 2006 08:17:22 +0100
Subject: [Rspec-devel] RSpec 0.6.1 [RESCIND]
Message-ID: <533048b70608270017t521b8d62pdf9c046ba7cba81c@mail.gmail.com>

>* 'Noisy' failure of rake task is already dealt with by an attribute
*>* fail_on_error
*>* which defaults to true, but if set false would probable fix my problem.
*>*
*>* Feel free to delete or close the Tracker bug report.
*>*
*
Which one?



# 5508
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060827/990a9264/attachment.html 

From aslak.hellesoy at gmail.com  Sun Aug 27 06:13:54 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 27 Aug 2006 12:13:54 +0200
Subject: [Rspec-devel] warnings when running rake test
In-Reply-To: <57c63afe0608261754p49241582hedf12edeb9ab2bfd@mail.gmail.com>
References: <57c63afe0608261511jd3ad5e8w7fb97b6b1a5aa1bc@mail.gmail.com>
	<8d961d900608261619l726c5685p4d11db9bc3359a4e@mail.gmail.com>
	<57c63afe0608261754p49241582hedf12edeb9ab2bfd@mail.gmail.com>
Message-ID: <8d961d900608270313m3043647dh893a4c6dc5eeec5d@mail.gmail.com>

On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/26/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > The test task is currently set to show all the warnings. I'd like to
> > > either turn them off or modify code to get rid of them.
> > >
> >
> > I thought I had got rid of all the warnings now.
> >
> > > Preferences?
> > >
> >
> > Keep the warning flag on and keep our code clean.
>
> I agree in spirit, but what "clean" means is subjective. For example,
> one warning we get is in reporter.rb:
>
>         return @end_time - @start_time unless (@end_time.nil? or
> @start_time.nil?)
>
> This line of code seems perfectly clean, but a warning is generated
> stating that @end_time is not initialized. Cleaning this up would
> require the following in the initialize method:
>
>   @start_time = nil
>   @end_time = nil
>
> Perhaps that is more clear, but it is also more verbose.
>

I agree it's more verbose than my taste.
What -w warns about is Matz' subjective taste.

I don't care too much whether we follow my, your, matz' or anyone
else's taste in this matter. You decide ;-)

Aslak

> Another weird one is in /test/spec/test_to_spec/testfiles/test_unit_api_test.rb:
>
> warning: method redefined; discarding old setup
>
> Wassup w/ that?
>

def setup
end

def setup
end

-probably something we ought to look into

Aslak

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

From aslak.hellesoy at gmail.com  Sun Aug 27 06:19:51 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 27 Aug 2006 12:19:51 +0200
Subject: [Rspec-devel] ANN: RSpec 0.6.2
In-Reply-To: <8d961d900608261323t60004cf8qcc2d715584b54590@mail.gmail.com>
References: <8d961d900608261323t60004cf8qcc2d715584b54590@mail.gmail.com>
Message-ID: <8d961d900608270319k71a0ecf7g19cba84e46236170@mail.gmail.com>

It seems that 13 hours after the last release the 0.6.2 gem is still
not rsync'ed across rubyforge's cluster of gem servers:

$ sudo gem install rspec
Attempting local installation of 'rspec'
Local gem file not found: rspec*.gem
Attempting remote installation of 'rspec'
Updating Gem source index for: http://gems.rubyforge.org
ERROR:  While executing gem ... (OpenURI::HTTPError)
    404 Not Found

Hopefully the replication will complete soon so this can work. If not,
you can download the gem to your filesystem and do a

gem install path/to/rspec-0.6.2.gem

Aslak

On 8/26/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> I just released RSpec 0.6.2
>
> Hopefully this fixes the couple of glitches that went into 0.6.1 - the
> RSpec rake task was heavily refactored in 0.6.1 and didn't work
> properly when packaged as a gem. This should be fixed now. Holler if
> things are still broken.
>
> Cheers,
> Aslak
>

From dchelimsky at gmail.com  Sun Aug 27 08:40:15 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 07:40:15 -0500
Subject: [Rspec-devel] warnings when running rake test
In-Reply-To: <8d961d900608270313m3043647dh893a4c6dc5eeec5d@mail.gmail.com>
References: <57c63afe0608261511jd3ad5e8w7fb97b6b1a5aa1bc@mail.gmail.com>
	<8d961d900608261619l726c5685p4d11db9bc3359a4e@mail.gmail.com>
	<57c63afe0608261754p49241582hedf12edeb9ab2bfd@mail.gmail.com>
	<8d961d900608270313m3043647dh893a4c6dc5eeec5d@mail.gmail.com>
Message-ID: <57c63afe0608270540i236eaeffr20df8b7615b73846@mail.gmail.com>

On 8/27/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> > Another weird one is in /test/spec/test_to_spec/testfiles/test_unit_api_test.rb:
> >
> > warning: method redefined; discarding old setup
> >
> > Wassup w/ that?
> >
>
> def setup
> end
>
> def setup
> end
>

Yeah, but it only happens once in that file.

> -probably something we ought to look into

Agreed.

From dchelimsky at gmail.com  Sun Aug 27 08:43:22 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 07:43:22 -0500
Subject: [Rspec-devel] RSpec 0.6.1 [RESCIND]
In-Reply-To: <533048b70608270017t521b8d62pdf9c046ba7cba81c@mail.gmail.com>
References: <533048b70608270017t521b8d62pdf9c046ba7cba81c@mail.gmail.com>
Message-ID: <57c63afe0608270543s364e8949l3824c2bf4fbfdcfa@mail.gmail.com>

So closed.

Thanks,
David

On 8/27/06, DeeJay <smartgpx at gmail.com> wrote:
>
>
>
> > 'Noisy' failure of rake task is already dealt with by an attribute
> > fail_on_error
> > which defaults to true, but if set false would probable fix my problem.
> >
> > Feel free to delete or close the Tracker bug report.
> >
>
> Which one?
>
>
> # 5508
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From dchelimsky at gmail.com  Sun Aug 27 10:25:55 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 09:25:55 -0500
Subject: [Rspec-devel] habtm collections
In-Reply-To: <5BE4BC23-1DD5-453C-B84B-F487FBC4536D@daveastels.com>
References: <8d961d900607031900xcd3bcb0jce96848662d7e242@mail.gmail.com>
	<44AA6C31.5040703@rubyforge.org>
	<8d961d900607040759w1956b862jd6d207286ee3f869@mail.gmail.com>
	<44E4DCAB.9040206@dr-siemssen.de>
	<8d961d900608171736p1c99b5e6kd61f0e889ba1c000@mail.gmail.com>
	<44E57096.3070109@dr-siemssen.de>
	<8d961d900608190341k1c207268xb6a5bf1ff4996f36@mail.gmail.com>
	<44E79756.40106@dr-siemssen.de>
	<5BE4BC23-1DD5-453C-B84B-F487FBC4536D@daveastels.com>
Message-ID: <57c63afe0608270725mb35c278sddfc4402f22013a5@mail.gmail.com>

Looks like another sugary sweetness problem - a conflict between
rspec's use of method_missing and that of active_record:


TypeError in 'Animal should have person'
wrong argument type Animal (expected Module)
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/base.rb:1129:in
`method_missing'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/associations/has_many_association.rb:102:in
`method_missing'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/base.rb:873:in
`with_scope'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.3/lib/active_record/associations/has_many_association.rb:92:in
`method_missing'

I've raised issue #5539 at rubyforge:


On 8/20/06, David Astels <dastels at daveastels.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> It looks like we need better support for habtm virtual collections...
> at least based on the behaviour I'm seeing.
>
> For example, instead of doing:
>
>         @dave.tracks.should_include Track.find_by_name("School's Out")
>
> I have to do:
>
>         @dave.tracks.include?(Track.find_by_name("School's Out")).should_be
> true
>
> Yuck.
>
> Dave
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
>
> iD8DBQFE6OvBauez/L4x7g4RAlGaAKCUjKFYUlRuu8KoRxedgPMtFtXwXQCfRZ7x
> 1vgNY50aZK+phkDhAEUXVnk=
> =29QJ
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sun Aug 27 10:48:54 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 09:48:54 -0500
Subject: [Rspec-devel] RSpec on Rails and Rails Engines
In-Reply-To: <8d961d900608171738x2a47cff7s4942219206ea1bed@mail.gmail.com>
References: <44E4DFC7.2080208@dr-siemssen.de>
	<8d961d900608171738x2a47cff7s4942219206ea1bed@mail.gmail.com>
Message-ID: <57c63afe0608270748sa50b625p9e95ec5547f366a2@mail.gmail.com>

I'm just getting caught up w/ everything. Was this addressed in 0.6.1?


On 8/17/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/17/06, Daniel Siemssen <daniel at dr-siemssen.de> wrote:
> > Why do you have the require lines for controller_mixin.rb and
> > rspec_on_rails.rb in your init.rb and not in the spec_helper.rb? When
> > these require lines are in the init.rb they cause errors for Rails
> > Engines users because rspec_on_rails.rb requires 'application'. Since
> > application might have some include lines like 'include myengine' and
> > since the rspec_on_rails plugin gets loaded before any engine, you'll
> > certainly run into troubles when loading your rails environment.
> > So, my question is, can you put these lines into spec_helper.rb and if
> > not please tell me why.
> >
>
> It's been a month or two since I worked on this so my memory is a bit
> rusty on this. Do you have a patch that you would like us to
> incorporate?
>
> Aslak
>
> > Keep up the good work!
> >
> > Daniel
> >
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sun Aug 27 11:25:57 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 10:25:57 -0500
Subject: [Rspec-devel] Feature requests
In-Reply-To: <44E274A2.3040001@redfivellc.com>
References: <44E274A2.3040001@redfivellc.com>
Message-ID: <57c63afe0608270825ub0037bck23abf173ca59e070@mail.gmail.com>

Judson - there are a few separate issues you raise here. I've got a
ton I'm trying to catch up w/ here so you could you please help me out
by entering feature requests (or bugs or patches) at rubyforge for any
of these issues that are still open?

Thanks,
David

On 8/15/06, Judson Lester <nyarly-rspec at redfivellc.com> wrote:
> I've run into a couple of minor irritations working with rspec recently.
>
> Mostly, I really like working with rspec.  Tidy DSL, good Rake
> integration, built in mocks and coverage are all major boons.  But:
>
> proc.should_raise and should_not_raise both result in printing the
> backtrace of the the RSpec failure they raise, rather than the
> unexpected exception that was raised.  This leads to a fair amount of
> extra dev time spent hunting down the error, where a message along the
> lines of "proc should not have raised, but instead raised:" and the
> whole exception (not the standard Ruby "...400 lines skipped that
> include the line you care about..." :)
>
> Contrarywise, other expectations also print their entire backtrace,
> which is rarely helpful and consumes a fair amount of scrollback and
> attention.
>
> Finally hash.should_has_key(:key) fails (<hash> doesn't respond to has?)
> as do similar predicates (i.e. anything with an underscore).
>
> It wouldn't hurt if mocks passed .and_return([1,2,3]) would treat that
> as an expectation to be called at least 3 times, and warn if they were
> told otherwise - it's certainly not Least Surprise when the class being
> specced against fails because it's getting the wrong result.
>
> Am I the voice in the wilderness here?  I'm more than willing to submit
> patches, if there's some chance they'll be accepted.
>
> Judson
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Sun Aug 27 11:32:27 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 27 Aug 2006 17:32:27 +0200
Subject: [Rspec-devel] warnings when running rake test
In-Reply-To: <57c63afe0608270540i236eaeffr20df8b7615b73846@mail.gmail.com>
References: <57c63afe0608261511jd3ad5e8w7fb97b6b1a5aa1bc@mail.gmail.com>
	<8d961d900608261619l726c5685p4d11db9bc3359a4e@mail.gmail.com>
	<57c63afe0608261754p49241582hedf12edeb9ab2bfd@mail.gmail.com>
	<8d961d900608270313m3043647dh893a4c6dc5eeec5d@mail.gmail.com>
	<57c63afe0608270540i236eaeffr20df8b7615b73846@mail.gmail.com>
Message-ID: <8d961d900608270832q4ccad2acmb70407c374b9462e@mail.gmail.com>

On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/27/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> >
> > > Another weird one is in /test/spec/test_to_spec/testfiles/test_unit_api_test.rb:
> > >
> > > warning: method redefined; discarding old setup
> > >
> > > Wassup w/ that?
> > >
> >
> > def setup
> > end
> >
> > def setup
> > end
> >
>
> Yeah, but it only happens once in that file.
>

So it probably happens somewhere in a different file too. Ruby doesn't
care about what file it happens in.

> > -probably something we ought to look into
>
> Agreed.
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sun Aug 27 11:51:51 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 10:51:51 -0500
Subject: [Rspec-devel] warnings when running rake test
In-Reply-To: <8d961d900608270832q4ccad2acmb70407c374b9462e@mail.gmail.com>
References: <57c63afe0608261511jd3ad5e8w7fb97b6b1a5aa1bc@mail.gmail.com>
	<8d961d900608261619l726c5685p4d11db9bc3359a4e@mail.gmail.com>
	<57c63afe0608261754p49241582hedf12edeb9ab2bfd@mail.gmail.com>
	<8d961d900608270313m3043647dh893a4c6dc5eeec5d@mail.gmail.com>
	<57c63afe0608270540i236eaeffr20df8b7615b73846@mail.gmail.com>
	<8d961d900608270832q4ccad2acmb70407c374b9462e@mail.gmail.com>
Message-ID: <57c63afe0608270851j2ec20f2dg96e7c20362c609bd@mail.gmail.com>

On 8/27/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/27/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > >
> > > > Another weird one is in /test/spec/test_to_spec/testfiles/test_unit_api_test.rb:
> > > >
> > > > warning: method redefined; discarding old setup
> > > >
> > > > Wassup w/ that?
> > > >
> > >
> > > def setup
> > > end
> > >
> > > def setup
> > > end
> > >
> >
> > Yeah, but it only happens once in that file.
> >
>
> So it probably happens somewhere in a different file too. Ruby doesn't
> care about what file it happens in.

Ruby is so nice :)

Seriously - I don't see any other places where that particular class
is opened again. Maybe it's happening at runtime? If so, that's a
(*&^(*&^ing annoying warning.


>
> > > -probably something we ought to look into
> >
> > Agreed.

From dchelimsky at gmail.com  Sun Aug 27 11:58:56 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 10:58:56 -0500
Subject: [Rspec-devel] rSpec QuickRef
In-Reply-To: <89CBEA5E-69B3-4304-8E73-15C9BF39EADC@daveastels.com>
References: <44DCFFED.7010207@redfivellc.com>
	<FDFA3642-C926-4193-889A-17F415963471@pobox.com>
	<44DD1332.1060701@redfivellc.com>
	<C82DF1F5-EDE9-4963-9A6B-A925DB31F0F8@daveastels.com>
	<44E0E393.60306@redfivellc.com>
	<36A35A00-7CA0-4C71-AEB7-4613ABF044C0@daveastels.com>
	<6AB20C14-D0DA-46B8-A1BD-C4B93F4EA88C@daveastels.com>
	<66655060-012A-42BF-93F8-218BA17A928D@agileevolved.com>
	<89CBEA5E-69B3-4304-8E73-15C9BF39EADC@daveastels.com>
Message-ID: <57c63afe0608270858ka28948bx7ce3527686282ddf@mail.gmail.com>

.never in Receive Counts should go. It's still there but is
functionally replaced by should_not_receive and will probably be
removed entirely sometime soon.

On 8/26/06, David Astels <dastels at daveastels.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Here's a quick ref card I've been working on for rSpec (general, not
> rails specific).  Let me know what you think
>
> http://blog.daveastels.com/files/rSpec_QuickRef.pdf
>
> Dave
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (Darwin)
>
> iD8DBQFE7+feauez/L4x7g4RAoLAAKDe7TESf1kVoFHfeY2YPDuT67UifwCeI5Ul
> NFt7JVcu8BUJs6nDKrJoFy8=
> =BlDk
> -----END PGP SIGNATURE-----
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sun Aug 27 12:06:10 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 11:06:10 -0500
Subject: [Rspec-devel] should_output proof-of-concept
In-Reply-To: <20060826232502.WUEX4315.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
References: <20060826232502.WUEX4315.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
Message-ID: <57c63afe0608270906j53789e7fsa9e5345c0dbcc697@mail.gmail.com>

Even without a patch, would you please submit this as a feature
request at rubyforge?

I like this idea. Anyone else?

Thanks,
David

On 8/26/06, E S <eero.saynatkari at kolumbus.fi> wrote:
> Hi! Sorry if this is the wrong place--and apologies that
> this is not in patch format (I do not have SVN access and
> did not want to try to patch from 0.6.1). I currently just
> have this hacked in a helper lib I #require for the specs.
> I was briefly pondering about something similar for input
> but that is more of a context than specification thing.
>
> Thoughts?
>
> # Usage examples:
>
>  lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output "foo\n"
>  lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output /foo\n/
>
>  lambda {UI.mainloop {|ui| ui.error 'foo'}}.should_output "foo\n", :to => '$stderr'
>
> # Code:
>
> # Modify RSpec a little
> module Spec
>   class ShouldHelper
>
>     # Verify output from block is expected
>     def output(expected, io = {:to => '$stdout'})
>       to = io[:to]
>
>       # Store the old value
>       eval "#{to}, old_to = StringIO.new(''), #{to}"
>
>       @target.call
>       eval(to).rewind
>       output = eval(to).read
>
>       # Match up
>       case expected
>         when Regexp
>           output.should_match expected
>         else
>           output.should_equal expected
>       end                             # case expected
>
>     # Clean up
>     ensure
>       eval "#{to} = old_to"
>     end                               # output()
>   end                                 # ShouldHelper
> end                                   # Spec
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From brian.takita at gmail.com  Sun Aug 27 13:20:42 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 27 Aug 2006 10:20:42 -0700
Subject: [Rspec-devel] should_output proof-of-concept
In-Reply-To: <57c63afe0608270906j53789e7fsa9e5345c0dbcc697@mail.gmail.com>
References: <20060826232502.WUEX4315.fep02-app.kolumbus.fi@smtp.kolumbus.fi>
	<57c63afe0608270906j53789e7fsa9e5345c0dbcc697@mail.gmail.com>
Message-ID: <1d7ddd110608271020k2ac93a2egeebcf59abcedafa6@mail.gmail.com>

+1

On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> Even without a patch, would you please submit this as a feature
> request at rubyforge?
>
> I like this idea. Anyone else?
>
> Thanks,
> David
>
> On 8/26/06, E S <eero.saynatkari at kolumbus.fi> wrote:
> > Hi! Sorry if this is the wrong place--and apologies that
> > this is not in patch format (I do not have SVN access and
> > did not want to try to patch from 0.6.1). I currently just
> > have this hacked in a helper lib I #require for the specs.
> > I was briefly pondering about something similar for input
> > but that is more of a context than specification thing.
> >
> > Thoughts?
> >
> > # Usage examples:
> >
> >  lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output "foo\n"
> >  lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output /foo\n/
> >
> >  lambda {UI.mainloop {|ui| ui.error 'foo'}}.should_output "foo\n", :to
> => '$stderr'
> >
> > # Code:
> >
> > # Modify RSpec a little
> > module Spec
> >   class ShouldHelper
> >
> >     # Verify output from block is expected
> >     def output(expected, io = {:to => '$stdout'})
> >       to = io[:to]
> >
> >       # Store the old value
> >       eval "#{to}, old_to = StringIO.new(''), #{to}"
> >
> >       @target.call
> >       eval(to).rewind
> >       output = eval(to).read
> >
> >       # Match up
> >       case expected
> >         when Regexp
> >           output.should_match expected
> >         else
> >           output.should_equal expected
> >       end                             # case expected
> >
> >     # Clean up
> >     ensure
> >       eval "#{to} = old_to"
> >     end                               # output()
> >   end                                 # ShouldHelper
> > end                                   # Spec
> >
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060827/37288d8a/attachment.html 

From brian.takita at gmail.com  Sun Aug 27 14:47:23 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 27 Aug 2006 11:47:23 -0700
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
Message-ID: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>

Hello,

At work we came up with a trio of methods that mock out methods in an
object.

   - define_instance_method
   - stub_with
   - mock_with

Funny thing is around the same time, this was posted.
http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight-mocking-ish

Here is a snippit from that article.

class Object

  def metaclass
    class << self; self; end
  end

  def define_instance_method(sym, &block)
    metaclass.__send__(:define_method, sym, &block)
  end

  def stub_instance_method(sym, &block)
    raise "#{self} does not respond to <#{sym}> and therefore cannot be
stubbed" unless self.respond_to?(sym)
    define_instance_method(sym, &block)
  end

  def __log__
    @__log__ ||= []
  end

end

So you can use this like:
o = Object.new
o.define_instance_method(:foo) do
  :bar
end
o.foo # return :bar

We went a little further by adding the mock_with and stub_with methods,
which take a Hash and allow you to mock out the method names corresponding
to the keys.

For example,
o = Object.new
two_value = 2
o.stub_with(:one => 1, :two => proc {two_value})
o.one # returns 1
o.two # returns 2

o = Object.new
mock_action = mock("mock_action")
mock_action.should_receive(:something).with(:grey_poupon)
o.mock_with(:receive => proc {mock_action)}
o.receive.something(:grey_poupon)

David, I also remember you where working on acts_as_mock. This has helped us
with our tests and I think it would also make using specs more convenient
and easier to read.
What does everybody think? If it sounds good, I'll create a patch.

Thanks,
Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060827/3452cd3d/attachment.html 

From luke at agileevolved.com  Sun Aug 27 15:15:59 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Sun, 27 Aug 2006 20:15:59 +0100
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
Message-ID: <F1C3CC64-FBC7-4820-A1CC-34752C1C9583@agileevolved.com>

Brian, have you seen mocha and stubba? It might be of interest to you.

http://mocha.rubyforge.org/

Cheers
Luke

On 27 Aug 2006, at 19:47, Brian Takita wrote:

> Hello,
>
> At work we came up with a trio of methods that mock out methods in  
> an object.
> define_instance_method
> stub_with
> mock_with
> Funny thing is around the same time, this was posted.
> http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight- 
> mocking-ish
>
> Here is a snippit from that article.
>
> class Object
>
>   def metaclass
>     class << self; self; end
>   end
>
>   def define_instance_method(sym, &block)
>     metaclass.__send__(:define_method, sym, &block)
>   end
>
>   def stub_instance_method(sym, &block)
>     raise "#{self} does not respond to <#{sym}> and therefore  
> cannot be stubbed" unless self.respond_to?(sym)
>     define_instance_method(sym, &block)
>   end
>
>   def __log__
>     @__log__ ||= []
>   end
>
> end
>
> So you can use this like:
> o = Object.new
> o.define_instance_method(:foo) do
>   :bar
> end
> o.foo # return :bar
>
> We went a little further by adding the mock_with and stub_with  
> methods, which take a Hash and allow you to mock out the method  
> names corresponding to the keys.
>
> For example,
> o = Object.new
> two_value = 2
> o.stub_with(:one => 1, :two => proc {two_value})
> o.one # returns 1
> o.two # returns 2
>
> o = Object.new
> mock_action = mock("mock_action")
> mock_action.should_receive(:something).with(:grey_poupon)
> o.mock_with (:receive => proc {mock_action)}
> o.receive.something(:grey_poupon)
>
> David, I also remember you where working on acts_as_mock. This has  
> helped us with our tests and I think it would also make using specs  
> more convenient and easier to read.
> What does everybody think? If it sounds good, I'll create a patch.
>
> Thanks,
> Brian
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel

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

From dchelimsky at gmail.com  Sun Aug 27 15:51:00 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 14:51:00 -0500
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
Message-ID: <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>

On 8/27/06, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> At work we came up with a trio of methods that mock out methods in an
> object.
>
> define_instance_method
> stub_with
> mock_withFunny thing is around the same time, this was posted.
> http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight-mocking-ish
>
> Here is a snippit from that article.
>
> class Object
>
>   def metaclass
>     class << self; self; end
>    end
>
>   def define_instance_method(sym, &block)
>      metaclass.__send__(:define_method, sym, &block)
>   end
>
>   def stub_instance_method(sym, &block)
>      raise "#{self} does not respond to <#{sym}> and therefore cannot be
> stubbed" unless self.respond_to?(sym)
>      define_instance_method(sym, &block)
>   end
>
>   def __log__
>     @__log__ ||= []
>   end
>
>  end
>
> So you can use this like:
> o = Object.new
>  o.define_instance_method(:foo) do
>   :bar
>  end
> o.foo # return :bar
>
> We went a little further by adding the mock_with and stub_with methods,
> which take a Hash and allow you to mock out the method names corresponding
> to the keys.
>
> For example,
> o = Object.new
> two_value = 2
>  o.stub_with(:one => 1, :two => proc {two_value})
> o.one # returns 1
> o.two # returns 2
>
>  o = Object.new
> mock_action = mock("mock_action")
>  mock_action.should_receive(:something).with(:grey_poupon)
> o.mock_with (:receive => proc {mock_action)}
> o.receive.something(:grey_poupon)
>
> David, I also remember you where working on acts_as_mock. This has helped us
> with our tests and I think it would also make using specs more convenient
> and easier to read.
> What does everybody think? If it sounds good, I'll create a patch.

I started working on acts_as_mock because rails forces us to use
static methods to find objects, which couples us to the database in
our controller specs:

Person.find(123)

In retrospect, all we really need is the ability to mock class level
methods and then return a mock:

specify "should display person when show is requested" do
  person = mock("person")
  Person.should_receive(:find).with(123).and_return(person)
  person.should_receive(:name).and_return("Joe")
  get 'show'
end

specify "should ask Person for a new one when create is requested" do
  person = mock("person")
  Person.should_receive(:new).and_return(person)
  get 'create'
end

The code for this much is already in a branch, so I'll revisit that in
the next few days.

As for the idea you are presenting, in general, I think that mocking
methods on real instances is  a risky proposition. I've seen this
result in tests that are very difficult to understand when they fail,
as some methods on the instance are mocked and some are not. I also
have yet to see a case where   using partial mocks is a better
decision than improving the decoupling in the system under test.

That's just my 2 cents. Anyone else?

David

From brian.takita at gmail.com  Sun Aug 27 16:31:05 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 27 Aug 2006 13:31:05 -0700
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
	<57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
Message-ID: <1d7ddd110608271331w24d0887btf8cdfd7779520772@mail.gmail.com>

>
> As for the idea you are presenting, in general, I think that mocking
> methods on real instances is  a risky proposition.


Yes, I agree with you about the partial mocking. mock_with was an alias of
stub_with, but that has to do with inaccurately definining a mock.

Using a stub to introduce a mock is useful though.

specify "should display person when show is requested" do
>  person = mock("person")
>  Person.should_receive(:find).with(123).and_return(person)
>  person.should_receive(:name).and_return("Joe")
>  get 'show'
> end
>
> specify "should ask Person for a new one when create is requested" do
>  person = mock("person")
>  Person.should_receive(:new).and_return(person)
>  get 'create'
> end
>

I noticed that Stubba does do this, with a different syntax. I tried
introducing it at my workplace, but it caused issues with other tests.

On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
>
> On 8/27/06, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > At work we came up with a trio of methods that mock out methods in an
> > object.
> >
> > define_instance_method
> > stub_with
> > mock_withFunny thing is around the same time, this was posted.
> >
> http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight-mocking-ish
> >
> > Here is a snippit from that article.
> >
> > class Object
> >
> >   def metaclass
> >     class << self; self; end
> >    end
> >
> >   def define_instance_method(sym, &block)
> >      metaclass.__send__(:define_method, sym, &block)
> >   end
> >
> >   def stub_instance_method(sym, &block)
> >      raise "#{self} does not respond to <#{sym}> and therefore cannot be
> > stubbed" unless self.respond_to?(sym)
> >      define_instance_method(sym, &block)
> >   end
> >
> >   def __log__
> >     @__log__ ||= []
> >   end
> >
> >  end
> >
> > So you can use this like:
> > o = Object.new
> >  o.define_instance_method(:foo) do
> >   :bar
> >  end
> > o.foo # return :bar
> >
> > We went a little further by adding the mock_with and stub_with methods,
> > which take a Hash and allow you to mock out the method names
> corresponding
> > to the keys.
> >
> > For example,
> > o = Object.new
> > two_value = 2
> >  o.stub_with(:one => 1, :two => proc {two_value})
> > o.one # returns 1
> > o.two # returns 2
> >
> >  o = Object.new
> > mock_action = mock("mock_action")
> >  mock_action.should_receive(:something).with(:grey_poupon)
> > o.mock_with (:receive => proc {mock_action)}
> > o.receive.something(:grey_poupon)
> >
> > David, I also remember you where working on acts_as_mock. This has
> helped us
> > with our tests and I think it would also make using specs more
> convenient
> > and easier to read.
> > What does everybody think? If it sounds good, I'll create a patch.
>
> I started working on acts_as_mock because rails forces us to use
> static methods to find objects, which couples us to the database in
> our controller specs:
>
> Person.find(123)
>
> In retrospect, all we really need is the ability to mock class level
> methods and then return a mock:
>
> specify "should display person when show is requested" do
>   person = mock("person")
>   Person.should_receive(:find).with(123).and_return(person)
>   person.should_receive(:name).and_return("Joe")
>   get 'show'
> end
>
> specify "should ask Person for a new one when create is requested" do
>   person = mock("person")
>   Person.should_receive(:new).and_return(person)
>   get 'create'
> end
>
> The code for this much is already in a branch, so I'll revisit that in
> the next few days.
>
> As for the idea you are presenting, in general, I think that mocking
> methods on real instances is  a risky proposition. I've seen this
> result in tests that are very difficult to understand when they fail,
> as some methods on the instance are mocked and some are not. I also
> have yet to see a case where   using partial mocks is a better
> decision than improving the decoupling in the system under test.
>
> That's just my 2 cents. Anyone else?
>
> 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-devel/attachments/20060827/10c0a3af/attachment.html 

From dastels at daveastels.com  Sun Aug 27 17:11:35 2006
From: dastels at daveastels.com (David Astels)
Date: Sun, 27 Aug 2006 18:11:35 -0300
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
	<57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
Message-ID: <F901CE6D-78F5-4E66-A1B8-042193890FE8@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 27-Aug-06, at 4:51 PM, David Chelimsky wrote:

> As for the idea you are presenting, in general, I think that mocking
> methods on real instances is  a risky proposition. I've seen this
> result in tests that are very difficult to understand when they fail,
> as some methods on the instance are mocked and some are not. I also
> have yet to see a case where   using partial mocks is a better
> decision than improving the decoupling in the system under test.
>
> That's just my 2 cents. Anyone else?

I agree.  Partial mocks can get very confusing, very easily.

Dave
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD4DBQFE8gqIauez/L4x7g4RAjpCAKDjtFmylU+508YBYHhJ6Ht9vQN23ACXdv4r
yhLqDl+7/htXR2TliE4ZHg==
=yEcS
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Sun Aug 27 17:20:26 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 27 Aug 2006 23:20:26 +0200
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
	<57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
Message-ID: <8d961d900608271420r391e2206yb44d049c0c1be3a6@mail.gmail.com>

On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/27/06, Brian Takita <brian.takita at gmail.com> wrote:
> > Hello,
> >
> > At work we came up with a trio of methods that mock out methods in an
> > object.
> >
> > define_instance_method
> > stub_with
> > mock_withFunny thing is around the same time, this was posted.
> > http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight-mocking-ish
> >
> > Here is a snippit from that article.
> >
> > class Object
> >
> >   def metaclass
> >     class << self; self; end
> >    end
> >
> >   def define_instance_method(sym, &block)
> >      metaclass.__send__(:define_method, sym, &block)
> >   end
> >
> >   def stub_instance_method(sym, &block)
> >      raise "#{self} does not respond to <#{sym}> and therefore cannot be
> > stubbed" unless self.respond_to?(sym)
> >      define_instance_method(sym, &block)
> >   end
> >
> >   def __log__
> >     @__log__ ||= []
> >   end
> >
> >  end
> >
> > So you can use this like:
> > o = Object.new
> >  o.define_instance_method(:foo) do
> >   :bar
> >  end
> > o.foo # return :bar
> >
> > We went a little further by adding the mock_with and stub_with methods,
> > which take a Hash and allow you to mock out the method names corresponding
> > to the keys.
> >
> > For example,
> > o = Object.new
> > two_value = 2
> >  o.stub_with(:one => 1, :two => proc {two_value})
> > o.one # returns 1
> > o.two # returns 2
> >
> >  o = Object.new
> > mock_action = mock("mock_action")
> >  mock_action.should_receive(:something).with(:grey_poupon)
> > o.mock_with (:receive => proc {mock_action)}
> > o.receive.something(:grey_poupon)
> >
> > David, I also remember you where working on acts_as_mock. This has helped us
> > with our tests and I think it would also make using specs more convenient
> > and easier to read.
> > What does everybody think? If it sounds good, I'll create a patch.
>
> I started working on acts_as_mock because rails forces us to use
> static methods to find objects, which couples us to the database in
> our controller specs:
>
> Person.find(123)
>
> In retrospect, all we really need is the ability to mock class level
> methods and then return a mock:
>
> specify "should display person when show is requested" do
>   person = mock("person")
>   Person.should_receive(:find).with(123).and_return(person)
>   person.should_receive(:name).and_return("Joe")
>   get 'show'
> end
>
> specify "should ask Person for a new one when create is requested" do
>   person = mock("person")
>   Person.should_receive(:new).and_return(person)
>   get 'create'
> end
>
> The code for this much is already in a branch, so I'll revisit that in
> the next few days.
>
> As for the idea you are presenting, in general, I think that mocking
> methods on real instances is  a risky proposition. I've seen this
> result in tests that are very difficult to understand when they fail,
> as some methods on the instance are mocked and some are not. I also
> have yet to see a case where   using partial mocks is a better
> decision than improving the decoupling in the system under test.
>

Isn't acts_as_mock (the branch experiment) using 'partial' mocking?
(Redefining class and instance methods on existing classes)

Aslak

> That's just my 2 cents. Anyone else?
>
> David
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From dchelimsky at gmail.com  Sun Aug 27 18:17:59 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 17:17:59 -0500
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <8d961d900608271420r391e2206yb44d049c0c1be3a6@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
	<57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
	<8d961d900608271420r391e2206yb44d049c0c1be3a6@mail.gmail.com>
Message-ID: <57c63afe0608271517u794b5f99hba1ed4d4449554a3@mail.gmail.com>

On 8/27/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/27/06, Brian Takita <brian.takita at gmail.com> wrote:
> > > Hello,
> > >
> > > At work we came up with a trio of methods that mock out methods in an
> > > object.
> > >
> > > define_instance_method
> > > stub_with
> > > mock_withFunny thing is around the same time, this was posted.
> > > http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight-mocking-ish
> > >
> > > Here is a snippit from that article.
> > >
> > > class Object
> > >
> > >   def metaclass
> > >     class << self; self; end
> > >    end
> > >
> > >   def define_instance_method(sym, &block)
> > >      metaclass.__send__(:define_method, sym, &block)
> > >   end
> > >
> > >   def stub_instance_method(sym, &block)
> > >      raise "#{self} does not respond to <#{sym}> and therefore cannot be
> > > stubbed" unless self.respond_to?(sym)
> > >      define_instance_method(sym, &block)
> > >   end
> > >
> > >   def __log__
> > >     @__log__ ||= []
> > >   end
> > >
> > >  end
> > >
> > > So you can use this like:
> > > o = Object.new
> > >  o.define_instance_method(:foo) do
> > >   :bar
> > >  end
> > > o.foo # return :bar
> > >
> > > We went a little further by adding the mock_with and stub_with methods,
> > > which take a Hash and allow you to mock out the method names corresponding
> > > to the keys.
> > >
> > > For example,
> > > o = Object.new
> > > two_value = 2
> > >  o.stub_with(:one => 1, :two => proc {two_value})
> > > o.one # returns 1
> > > o.two # returns 2
> > >
> > >  o = Object.new
> > > mock_action = mock("mock_action")
> > >  mock_action.should_receive(:something).with(:grey_poupon)
> > > o.mock_with (:receive => proc {mock_action)}
> > > o.receive.something(:grey_poupon)
> > >
> > > David, I also remember you where working on acts_as_mock. This has helped us
> > > with our tests and I think it would also make using specs more convenient
> > > and easier to read.
> > > What does everybody think? If it sounds good, I'll create a patch.
> >
> > I started working on acts_as_mock because rails forces us to use
> > static methods to find objects, which couples us to the database in
> > our controller specs:
> >
> > Person.find(123)
> >
> > In retrospect, all we really need is the ability to mock class level
> > methods and then return a mock:
> >
> > specify "should display person when show is requested" do
> >   person = mock("person")
> >   Person.should_receive(:find).with(123).and_return(person)
> >   person.should_receive(:name).and_return("Joe")
> >   get 'show'
> > end
> >
> > specify "should ask Person for a new one when create is requested" do
> >   person = mock("person")
> >   Person.should_receive(:new).and_return(person)
> >   get 'create'
> > end
> >
> > The code for this much is already in a branch, so I'll revisit that in
> > the next few days.
> >
> > As for the idea you are presenting, in general, I think that mocking
> > methods on real instances is  a risky proposition. I've seen this
> > result in tests that are very difficult to understand when they fail,
> > as some methods on the instance are mocked and some are not. I also
> > have yet to see a case where   using partial mocks is a better
> > decision than improving the decoupling in the system under test.
> >
>
> Isn't acts_as_mock (the branch experiment) using 'partial' mocking?
> (Redefining class and instance methods on existing classes)

It was originally, but I'm going to try to do it w/ only mocking the
class methods so we can use them to return mocks rather than returning
instances acting like mocks. I think that will be cleaner.

>
> Aslak
>
> > That's just my 2 cents. Anyone else?
> >
> > David
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Sun Aug 27 18:24:09 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 28 Aug 2006 00:24:09 +0200
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <57c63afe0608271517u794b5f99hba1ed4d4449554a3@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
	<57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
	<8d961d900608271420r391e2206yb44d049c0c1be3a6@mail.gmail.com>
	<57c63afe0608271517u794b5f99hba1ed4d4449554a3@mail.gmail.com>
Message-ID: <8d961d900608271524u3e15c27bu52a11a0fa63d8aec@mail.gmail.com>

On 8/28/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> On 8/27/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > On 8/27/06, Brian Takita <brian.takita at gmail.com> wrote:
> > > > Hello,
> > > >
> > > > At work we came up with a trio of methods that mock out methods in an
> > > > object.
> > > >
> > > > define_instance_method
> > > > stub_with
> > > > mock_withFunny thing is around the same time, this was posted.
> > > > http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight-mocking-ish
> > > >
> > > > Here is a snippit from that article.
> > > >
> > > > class Object
> > > >
> > > >   def metaclass
> > > >     class << self; self; end
> > > >    end
> > > >
> > > >   def define_instance_method(sym, &block)
> > > >      metaclass.__send__(:define_method, sym, &block)
> > > >   end
> > > >
> > > >   def stub_instance_method(sym, &block)
> > > >      raise "#{self} does not respond to <#{sym}> and therefore cannot be
> > > > stubbed" unless self.respond_to?(sym)
> > > >      define_instance_method(sym, &block)
> > > >   end
> > > >
> > > >   def __log__
> > > >     @__log__ ||= []
> > > >   end
> > > >
> > > >  end
> > > >
> > > > So you can use this like:
> > > > o = Object.new
> > > >  o.define_instance_method(:foo) do
> > > >   :bar
> > > >  end
> > > > o.foo # return :bar
> > > >
> > > > We went a little further by adding the mock_with and stub_with methods,
> > > > which take a Hash and allow you to mock out the method names corresponding
> > > > to the keys.
> > > >
> > > > For example,
> > > > o = Object.new
> > > > two_value = 2
> > > >  o.stub_with(:one => 1, :two => proc {two_value})
> > > > o.one # returns 1
> > > > o.two # returns 2
> > > >
> > > >  o = Object.new
> > > > mock_action = mock("mock_action")
> > > >  mock_action.should_receive(:something).with(:grey_poupon)
> > > > o.mock_with (:receive => proc {mock_action)}
> > > > o.receive.something(:grey_poupon)
> > > >
> > > > David, I also remember you where working on acts_as_mock. This has helped us
> > > > with our tests and I think it would also make using specs more convenient
> > > > and easier to read.
> > > > What does everybody think? If it sounds good, I'll create a patch.
> > >
> > > I started working on acts_as_mock because rails forces us to use
> > > static methods to find objects, which couples us to the database in
> > > our controller specs:
> > >
> > > Person.find(123)
> > >
> > > In retrospect, all we really need is the ability to mock class level
> > > methods and then return a mock:
> > >
> > > specify "should display person when show is requested" do
> > >   person = mock("person")
> > >   Person.should_receive(:find).with(123).and_return(person)
> > >   person.should_receive(:name).and_return("Joe")
> > >   get 'show'
> > > end
> > >
> > > specify "should ask Person for a new one when create is requested" do
> > >   person = mock("person")
> > >   Person.should_receive(:new).and_return(person)
> > >   get 'create'
> > > end
> > >
> > > The code for this much is already in a branch, so I'll revisit that in
> > > the next few days.
> > >
> > > As for the idea you are presenting, in general, I think that mocking
> > > methods on real instances is  a risky proposition. I've seen this
> > > result in tests that are very difficult to understand when they fail,
> > > as some methods on the instance are mocked and some are not. I also
> > > have yet to see a case where   using partial mocks is a better
> > > decision than improving the decoupling in the system under test.
> > >
> >
> > Isn't acts_as_mock (the branch experiment) using 'partial' mocking?
> > (Redefining class and instance methods on existing classes)
>
> It was originally, but I'm going to try to do it w/ only mocking the
> class methods so we can use them to return mocks rather than returning
> instances acting like mocks. I think that will be cleaner.
>

In Ruby, classes are *real* objects
(http://www.rubycentral.com/book/ref_c_class.html), so making this
available for classes should be no different than making it available
for all objects. -Unless we make it explicitly available for Class
only, which to me seems like a somewhat arbitrary limitation.

Aslak

> >
> > Aslak
> >
> > > That's just my 2 cents. Anyone else?
> > >
> > > David
> > > _______________________________________________
> > > Rspec-devel mailing list
> > > Rspec-devel at rubyforge.org
> > > http://rubyforge.org/mailman/listinfo/rspec-devel
> > >
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From aslak.hellesoy at gmail.com  Sun Aug 27 18:33:32 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 28 Aug 2006 00:33:32 +0200
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
Message-ID: <8d961d900608271533i28ec5cf4w37cd46698f075ba4@mail.gmail.com>

On 8/27/06, Brian Takita <brian.takita at gmail.com> wrote:
> Hello,
>
> At work we came up with a trio of methods that mock out methods in an
> object.
>
> define_instance_method
> stub_with
> mock_withFunny thing is around the same time, this was posted.
> http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight-mocking-ish
>
> Here is a snippit from that article.
>
> class Object
>
>   def metaclass
>     class << self; self; end
>    end
>
>   def define_instance_method(sym, &block)
>      metaclass.__send__(:define_method, sym, &block)
>   end
>
>   def stub_instance_method(sym, &block)
>      raise "#{self} does not respond to <#{sym}> and therefore cannot be
> stubbed" unless self.respond_to?(sym)
>      define_instance_method(sym, &block)
>   end
>
>   def __log__
>     @__log__ ||= []
>   end
>
>  end
>
> So you can use this like:
> o = Object.new
>  o.define_instance_method(:foo) do
>   :bar
>  end
> o.foo # return :bar

Why not just do:

o = Object.new
def o.foo
  :bar
end
o.foo # return :bar

Is it just to get the raise when undefined methods are being (re)defined?

Aslak

>
> We went a little further by adding the mock_with and stub_with methods,
> which take a Hash and allow you to mock out the method names corresponding
> to the keys.
>
> For example,
> o = Object.new
> two_value = 2
>  o.stub_with(:one => 1, :two => proc {two_value})
> o.one # returns 1
> o.two # returns 2
>
>  o = Object.new
> mock_action = mock("mock_action")
>  mock_action.should_receive(:something).with(:grey_poupon)
> o.mock_with (:receive => proc {mock_action)}
> o.receive.something(:grey_poupon)
>
> David, I also remember you where working on acts_as_mock. This has helped us
> with our tests and I think it would also make using specs more convenient
> and easier to read.
> What does everybody think? If it sounds good, I'll create a patch.
>
> Thanks,
> Brian
>
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From eero.saynatkari at kolumbus.fi  Sun Aug 27 20:49:44 2006
From: eero.saynatkari at kolumbus.fi (E S)
Date: Mon, 28 Aug 2006 3:49:44 +0300
Subject: [Rspec-devel] should_output proof-of-concept
Message-ID: <20060828004944.VCMM10406.fep01-app.kolumbus.fi@smtp.kolumbus.fi>

> L?hett?j?: "David Chelimsky" <dchelimsky at gmail.com>
> P?iv?ys: 2006/08/27 su PM 07:06:10 EEST
> Vastaanottaja: rspec-devel at rubyforge.org
> Aihe: Re: [Rspec-devel] should_output proof-of-concept
> 
> Even without a patch, would you please submit this as a feature
> request at rubyforge?

Done. Added a workaround for Readline.

> I like this idea. Anyone else?
> 
> Thanks,
> David
> 
> On 8/26/06, E S <eero.saynatkari at kolumbus.fi> wrote:
> > Hi! Sorry if this is the wrong place--and apologies that
> > this is not in patch format (I do not have SVN access and
> > did not want to try to patch from 0.6.1). I currently just
> > have this hacked in a helper lib I #require for the specs.
> > I was briefly pondering about something similar for input
> > but that is more of a context than specification thing.
> >
> > Thoughts?
> >
> > # Usage examples:
> >
> >  lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output "foo\n"
> >  lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output /foo\n/
> >
> >  lambda {UI.mainloop {|ui| ui.error 'foo'}}.should_output "foo\n", :to => '$stderr'
> >
> > # Code:
> >
> > # Modify RSpec a little
> > module Spec
> >   class ShouldHelper
> >
> >     # Verify output from block is expected
> >     def output(expected, io = {:to => '$stdout'})
> >       to = io[:to]
> >
> >       # Store the old value
> >       eval "#{to}, old_to = StringIO.new(''), #{to}"
> >
> >       @target.call
> >       eval(to).rewind
> >       output = eval(to).read
> >
> >       # Match up
> >       case expected
> >         when Regexp
> >           output.should_match expected
> >         else
> >           output.should_equal expected
> >       end                             # case expected
> >
> >     # Clean up
> >     ensure
> >       eval "#{to} = old_to"
> >     end                               # output()
> >   end                                 # ShouldHelper
> > end                                   # Spec
> >
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
> 


From brian.takita at gmail.com  Mon Aug 28 00:04:29 2006
From: brian.takita at gmail.com (Brian Takita)
Date: Sun, 27 Aug 2006 21:04:29 -0700
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <8d961d900608271533i28ec5cf4w37cd46698f075ba4@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
	<8d961d900608271533i28ec5cf4w37cd46698f075ba4@mail.gmail.com>
Message-ID: <1d7ddd110608272104w20061648r747140a0778f727d@mail.gmail.com>

>
> Why not just do:
>
> o = Object.new
> def o.foo
>  :bar
> end
> o.foo # return :bar
>
> Is it just to get the raise when undefined methods are being (re)defined?
>

Because you lose scope.

o = Object.new
return_value = :bar

def o.foo
  return_value
end

o.foo # returns nil

But

o = Object.new
return_value = :bar

o.define_instance_method(:foo) {return_value}
o.foo # returns :bar

Its also useful for checking what parameters where passed in.

o = Object.new
passed_arg = nil
o.define_instance_method(:foo) {|arg| passed_arg = arg}
o.foo(:bar)
passed_arg == :bar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060827/a51550b0/attachment.html 

From dchelimsky at gmail.com  Mon Aug 28 00:25:24 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 23:25:24 -0500
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <8d961d900608271524u3e15c27bu52a11a0fa63d8aec@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
	<57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
	<8d961d900608271420r391e2206yb44d049c0c1be3a6@mail.gmail.com>
	<57c63afe0608271517u794b5f99hba1ed4d4449554a3@mail.gmail.com>
	<8d961d900608271524u3e15c27bu52a11a0fa63d8aec@mail.gmail.com>
Message-ID: <57c63afe0608272125w18541eaaxa0c64a00bf97b53e@mail.gmail.com>

On 8/27/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> On 8/28/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On 8/27/06, aslak hellesoy <aslak.hellesoy at gmail.com> wrote:
> > > On 8/27/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > On 8/27/06, Brian Takita <brian.takita at gmail.com> wrote:
> > > > > Hello,
> > > > >
> > > > > At work we came up with a trio of methods that mock out methods in an
> > > > > object.
> > > > >
> > > > > define_instance_method
> > > > > stub_with
> > > > > mock_withFunny thing is around the same time, this was posted.
> > > > > http://blog.seagul.co.uk/articles/2006/06/30/very-very-lightweight-mocking-ish
> > > > >
> > > > > Here is a snippit from that article.
> > > > >
> > > > > class Object
> > > > >
> > > > >   def metaclass
> > > > >     class << self; self; end
> > > > >    end
> > > > >
> > > > >   def define_instance_method(sym, &block)
> > > > >      metaclass.__send__(:define_method, sym, &block)
> > > > >   end
> > > > >
> > > > >   def stub_instance_method(sym, &block)
> > > > >      raise "#{self} does not respond to <#{sym}> and therefore cannot be
> > > > > stubbed" unless self.respond_to?(sym)
> > > > >      define_instance_method(sym, &block)
> > > > >   end
> > > > >
> > > > >   def __log__
> > > > >     @__log__ ||= []
> > > > >   end
> > > > >
> > > > >  end
> > > > >
> > > > > So you can use this like:
> > > > > o = Object.new
> > > > >  o.define_instance_method(:foo) do
> > > > >   :bar
> > > > >  end
> > > > > o.foo # return :bar
> > > > >
> > > > > We went a little further by adding the mock_with and stub_with methods,
> > > > > which take a Hash and allow you to mock out the method names corresponding
> > > > > to the keys.
> > > > >
> > > > > For example,
> > > > > o = Object.new
> > > > > two_value = 2
> > > > >  o.stub_with(:one => 1, :two => proc {two_value})
> > > > > o.one # returns 1
> > > > > o.two # returns 2
> > > > >
> > > > >  o = Object.new
> > > > > mock_action = mock("mock_action")
> > > > >  mock_action.should_receive(:something).with(:grey_poupon)
> > > > > o.mock_with (:receive => proc {mock_action)}
> > > > > o.receive.something(:grey_poupon)
> > > > >
> > > > > David, I also remember you where working on acts_as_mock. This has helped us
> > > > > with our tests and I think it would also make using specs more convenient
> > > > > and easier to read.
> > > > > What does everybody think? If it sounds good, I'll create a patch.
> > > >
> > > > I started working on acts_as_mock because rails forces us to use
> > > > static methods to find objects, which couples us to the database in
> > > > our controller specs:
> > > >
> > > > Person.find(123)
> > > >
> > > > In retrospect, all we really need is the ability to mock class level
> > > > methods and then return a mock:
> > > >
> > > > specify "should display person when show is requested" do
> > > >   person = mock("person")
> > > >   Person.should_receive(:find).with(123).and_return(person)
> > > >   person.should_receive(:name).and_return("Joe")
> > > >   get 'show'
> > > > end
> > > >
> > > > specify "should ask Person for a new one when create is requested" do
> > > >   person = mock("person")
> > > >   Person.should_receive(:new).and_return(person)
> > > >   get 'create'
> > > > end
> > > >
> > > > The code for this much is already in a branch, so I'll revisit that in
> > > > the next few days.
> > > >
> > > > As for the idea you are presenting, in general, I think that mocking
> > > > methods on real instances is  a risky proposition. I've seen this
> > > > result in tests that are very difficult to understand when they fail,
> > > > as some methods on the instance are mocked and some are not. I also
> > > > have yet to see a case where   using partial mocks is a better
> > > > decision than improving the decoupling in the system under test.
> > > >
> > >
> > > Isn't acts_as_mock (the branch experiment) using 'partial' mocking?
> > > (Redefining class and instance methods on existing classes)
> >
> > It was originally, but I'm going to try to do it w/ only mocking the
> > class methods so we can use them to return mocks rather than returning
> > instances acting like mocks. I think that will be cleaner.
> >
>
> In Ruby, classes are *real* objects
> (http://www.rubycentral.com/book/ref_c_class.html), so making this
> available for classes should be no different than making it available
> for all objects. -Unless we make it explicitly available for Class
> only, which to me seems like a somewhat arbitrary limitation.

I appreciate that classes are objects, and I've already implemented a
partially working version of acts_as_mock that works equally well (not
that well yet, but equally so) for any class (i.e. classes and their
classes).

The question is one of principle. My experience with partial mocks is
that they are not that helpful and are generally a bandaid for testing
(yes, testing) a highly coupled, already existing design. If RSpec is
a design tool, then it should promote good design. If we agree on that
principle, then partial mocks for instances shouldn't be supported.
The only reason to support them for classes is to intercept class
level methods that are implemented using the class name directly:

MyClass.some_method

Thoughts?

From dchelimsky at gmail.com  Mon Aug 28 00:27:08 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 27 Aug 2006 23:27:08 -0500
Subject: [Rspec-devel] define_instance_method, stub_with, and mock_with
In-Reply-To: <1d7ddd110608271331w24d0887btf8cdfd7779520772@mail.gmail.com>
References: <1d7ddd110608271147t2f083c3l8c111666a058dfa@mail.gmail.com>
	<57c63afe0608271251n57c0bafctc07ec9c0ddc585c8@mail.gmail.com>
	<1d7ddd110608271331w24d0887btf8cdfd7779520772@mail.gmail.com>
Message-ID: <57c63afe0608272127j1ca796cct2989df0eab091a61@mail.gmail.com>

On 8/27/06, Brian Takita <brian.takita at gmail.com> wrote:
>
> > As for the idea you are presenting, in general, I think that mocking
> > methods on real instances is  a risky proposition.
>
>
> Yes, I agree with you about the partial mocking. mock_with was an alias of
> stub_with, but that has to do with inaccurately definining a mock.
>
> Using a stub to introduce a mock is useful though.

Agreed. That is more or less where I'm leaning for acts_as_mock.

From dchelimsky at gmail.com  Mon Aug 28 01:49:07 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 28 Aug 2006 00:49:07 -0500
Subject: [Rspec-devel] single specs
Message-ID: <57c63afe0608272249u1e0ff3d3nae8b17673d05209a@mail.gmail.com>

The spec command has an option to run a single spec. I'm realizing
that I never, ever use this. Does anyone else? If not, I'd like to get
rid of it! It's one of those things that "seemed like a good idea at
the time", but resulted in a bunch of hack-ish code.

From dastels at daveastels.com  Mon Aug 28 02:08:35 2006
From: dastels at daveastels.com (David Astels)
Date: Mon, 28 Aug 2006 03:08:35 -0300
Subject: [Rspec-devel] single specs
In-Reply-To: <57c63afe0608272249u1e0ff3d3nae8b17673d05209a@mail.gmail.com>
References: <57c63afe0608272249u1e0ff3d3nae8b17673d05209a@mail.gmail.com>
Message-ID: <B38954E6-D08E-470E-A013-7E7C0B86A0AC@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 28-Aug-06, at 2:49 AM, David Chelimsky wrote:

> The spec command has an option to run a single spec. I'm realizing
> that I never, ever use this. Does anyone else? If not, I'd like to get
> rid of it! It's one of those things that "seemed like a good idea at
> the time", but resulted in a bunch of hack-ish code.

I've never used it.  The finest level of granularity I get is running  
a single file.

Dave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE8ohqauez/L4x7g4RAsvaAKDgdYhOVH6Jlvs7XqpP3PgOvV5RpQCfZ2pV
oD+CfNIoV6TW7K+avrlH8pI=
=BpHB
-----END PGP SIGNATURE-----

From aslak.hellesoy at gmail.com  Mon Aug 28 03:33:49 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 28 Aug 2006 09:33:49 +0200
Subject: [Rspec-devel] [Rspec-users] single specs
In-Reply-To: <57c63afe0608272249u1e0ff3d3nae8b17673d05209a@mail.gmail.com>
References: <57c63afe0608272249u1e0ff3d3nae8b17673d05209a@mail.gmail.com>
Message-ID: <8d961d900608280033u16499374h5a86f9b2bf8dbee8@mail.gmail.com>

On 8/28/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> The spec command has an option to run a single spec. I'm realizing
> that I never, ever use this. Does anyone else? If not, I'd like to get
> rid of it! It's one of those things that "seemed like a good idea at
> the time", but resulted in a bunch of hack-ish code.

I use this feature a lot. It's especially useful when you have a bunch
of slow specs.
Even as one of the writers of Ashcroft
(http://docs.codehaus.org/display/ASH/Home) slow specs are sometimes
unavoidable.

Now for example, I'm writing a library that interfaces with a local
scm, which is inherently slow.

Example of the way I use it is:

1) spec # run all specs - they pass. The suite takes 15 seconds (sloooow)
2) Do a refactoring
3) spec # 10 of the specs fail
4) spec -s 'One of the failing specs' # Takes 1 second instead of 15.

The nice thing about this is that the argument to -s can be copied and
pasted from the error messages.

So please don't remove this feature.

Aslak

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

From dchelimsky at gmail.com  Mon Aug 28 08:30:26 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 28 Aug 2006 07:30:26 -0500
Subject: [Rspec-devel] slightly different view
Message-ID: <57c63afe0608280530v283004d9nd1a5a326324c9565@mail.gmail.com>

All,

One of the things I learned when I started to do TDD was that you
should write enough tests to give you the courage to move forward. For
some, that results in more tests than others.

In approaching BDD, my initial thinking was to write examples for all
of the possible behaviours in every context. I've had a change of
thinking on this. Please check out my blog on it and let me know your
thoughts (here or there).

http://butunclebob.com/ArticleS.DavidChelimsky.SpecOrganization

Thanks,
David

From dchelimsky at gmail.com  Mon Aug 28 08:32:18 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 28 Aug 2006 07:32:18 -0500
Subject: [Rspec-devel] slightly different view
In-Reply-To: <57c63afe0608280530v283004d9nd1a5a326324c9565@mail.gmail.com>
References: <57c63afe0608280530v283004d9nd1a5a326324c9565@mail.gmail.com>
Message-ID: <57c63afe0608280532v50c004cei343b6062eb6fd90e@mail.gmail.com>

On 8/28/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> All,
>
> One of the things I learned when I started to do TDD was that you
> should write enough tests to give you the courage to move forward. For
> some, that results in more tests than others.
>
> In approaching BDD, my initial thinking was to write examples for all
> of the possible behaviours in every context. I've had a change of
> thinking on this. Please check out my blog on it and let me know your
> thoughts (here or there).
>
> http://butunclebob.com/ArticleS.DavidChelimsky.SpecOrganization
>
> Thanks,
> David

PS - if you check out the trunk, examples/stack_spec.rb now reflects
this thinking.

From demmer12 at fastmail.us  Mon Aug 28 14:22:35 2006
From: demmer12 at fastmail.us (Craig Demyanovich)
Date: Mon, 28 Aug 2006 14:22:35 -0400
Subject: [Rspec-devel] [Rspec-users] single specs
In-Reply-To: <57c63afe0608272249u1e0ff3d3nae8b17673d05209a@mail.gmail.com>
References: <57c63afe0608272249u1e0ff3d3nae8b17673d05209a@mail.gmail.com>
Message-ID: <518604E4-437C-4BF4-A52E-5EDEC66F0F5B@fastmail.us>

On Aug 28, 2006, at 1:49 AM, David Chelimsky wrote:

> The spec command has an option to run a single spec. I'm realizing
> that I never, ever use this. Does anyone else? If not, I'd like to get
> rid of it! It's one of those things that "seemed like a good idea at
> the time", but resulted in a bunch of hack-ish code.

I sometimes like being able to do this in xUnit frameworks when  
writing something new or digging in to something that isn't working.  
I don't yet have this use case while using rspec, though, since I'm  
not actively using it on anything yet. At this point, then, I don't  
care either way, but I wanted to throw this idea out there.

Regards,
Craig

From nyarly-rspec at redfivellc.com  Mon Aug 28 15:44:35 2006
From: nyarly-rspec at redfivellc.com (Judson Lester)
Date: Mon, 28 Aug 2006 12:44:35 -0700
Subject: [Rspec-devel] Mock feature thoughts
Message-ID: <44F347A3.7@redfivellc.com>

Given the discussion elsewhere on the list about Mocks and Rails, I
thought I'd briefly raise a couple of feature thoughts that I'm not
positive about in terms of philosophy.  Basically these all come out of
a basic frustration I've always had with every mock package.  That mocks
don't behave like the objects they're mocking.

Specifically, if I write something like

thing_mock=mock("thing")
thing_mock.should_receive(:a_message).and_return("message received")

I'd love to have thing_mock implicitly do something like
thing_mock.should_receive(:respond_to?).with(:a_message).and_return(true).any_number_of_times

Unless, of course I were to explicitly specify some other behavior for
#respond_to?

Relatedly, I'd love to be able to say (and _please_ don't read this as a
request for auto-mocking or whatever - assume that there is no "MyClass"
defined anywhere)

thing_mock=mock("thing")
thing_mock.mock_ancestors(["Object", "MyParentClass", "MyClass"])

and have it respond intelligently to #class, #kind_of, etc. 

This is especially useful when specifying a behavior that relies on
another library.  For instance, DRb. 

Does this seem useful, or does it expose an underlying misapprehension
about BDD on my part?

Judson

From dastels at daveastels.com  Mon Aug 28 16:17:33 2006
From: dastels at daveastels.com (David Astels)
Date: Mon, 28 Aug 2006 17:17:33 -0300
Subject: [Rspec-devel] Mock feature thoughts
In-Reply-To: <44F347A3.7@redfivellc.com>
References: <44F347A3.7@redfivellc.com>
Message-ID: <69312E13-CB44-4E8D-99E8-DE2789EAA597@daveastels.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 28-Aug-06, at 4:44 PM, Judson Lester wrote:

> Given the discussion elsewhere on the list about Mocks and Rails, I
> thought I'd briefly raise a couple of feature thoughts that I'm not
> positive about in terms of philosophy.  Basically these all come  
> out of
> a basic frustration I've always had with every mock package.  That  
> mocks
> don't behave like the objects they're mocking.

That might be your problem.  You're not mocking objects.. or even  
classes.. you're mocking interfaces (whether literally as in Java, or  
conceptually in a real.. ahem dynamic language

> Specifically, if I write something like
>
> thing_mock=mock("thing")
> thing_mock.should_receive(:a_message).and_return("message received")
>
> I'd love to have thing_mock implicitly do something like
> thing_mock.should_receive(:respond_to?).with(:a_message).and_return 
> (true).any_number_of_times
>
> Unless, of course I were to explicitly specify some other behavior for
> #respond_to?
>
> Relatedly, I'd love to be able to say (and _please_ don't read this  
> as a
> request for auto-mocking or whatever - assume that there is no  
> "MyClass"
> defined anywhere)

That's often the truth of it

> thing_mock=mock("thing")
> thing_mock.mock_ancestors(["Object", "MyParentClass", "MyClass"])

part of the joy of dynamic languages is that that stuff doesn't  
matter 99% of the time.  You focus should be "what it does" not "what  
it is"

> and have it respond intelligently to #class, #kind_of, etc.

If you need that.. you mock it.  You shouldn't need it.

> This is especially useful when specifying a behavior that relies on
> another library.  For instance, DRb.

In cases like that you should create a thin facade layer to the  
library and mock that.  Another advantage of doing that is that the  
layer can also be an adapter... translating the library's API into  
something that fits better with the domain of the application.  It  
also insulates your app from changes in the library's API.. whether  
due to a new version.. or swapping out for a different solution  
entirely.

> Does this seem useful, or does it expose an underlying misapprehension
> about BDD on my part?

A misunderstanding of Mock Objects and their purpose possibly.

Dave


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFE809dauez/L4x7g4RAhknAJ4nSj5zk4cXY7OjkAa7A0yRpaIhSgCgqG0x
LrV31MwezF+YU+8yRAuMmjQ=
=D8Jc
-----END PGP SIGNATURE-----

From nyarly-rspec at redfivellc.com  Mon Aug 28 18:46:58 2006
From: nyarly-rspec at redfivellc.com (Judson Lester)
Date: Mon, 28 Aug 2006 15:46:58 -0700
Subject: [Rspec-devel] Mock feature thoughts
In-Reply-To: <69312E13-CB44-4E8D-99E8-DE2789EAA597@daveastels.com>
References: <44F347A3.7@redfivellc.com>
	<69312E13-CB44-4E8D-99E8-DE2789EAA597@daveastels.com>
Message-ID: <44F37262.2050603@redfivellc.com>

David Astels wrote:
>
> That might be your problem.  You're not mocking objects.. or even  
> classes.. you're mocking interfaces (whether literally as in Java, or  
> conceptually in a real.. ahem dynamic language
Certainly.  But the fact is that implicitly when I add #method to the
interface of a class, the #respond_to? method changes.  Unless I rewrite
it.  This is a Good Thing.
> >> Specifically, if I write something like
> >>
> >> thing_mock=mock("thing")
> >> thing_mock.should_receive(:a_message).and_return("message received")
> >>
> >> I'd love to have thing_mock implicitly do something like
> >> thing_mock.should_receive(:respond_to?).with(:a_message).and_return
> >> (true).any_number_of_times
> >>
> >> Unless, of course I were to explicitly specify some other behavior for
> >> #respond_to?>> thing_mock=mock("thing")
> >> thing_mock.mock_ancestors(["Object", "MyParentClass", "MyClass"])
>
> part of the joy of dynamic languages is that that stuff doesn't  
> matter 99% of the time.  You focus should be "what it does" not "what  
> it is"
Certainly.  But there are cases, and I'd argue closer to 10% of the
time, where checking up front that an object does what it needs to do
before you need it to do it (in other words: duck typing) is amazingly
useful.  But not especially part of the behavior of the object.

The place I'm arguing from, (and one might notice a theme in my
suggestions on this note) is one which I picked up from Martin Fowler's
Refactoring book.  Which is basically laziness.  I know that the easier
it is for me to write specs, and to use them, and the more I get out of
using them, the more I _will_ use them.

In that vein (and apologies for the misplaced praise) the recent rewrite
of the Stack example is a real boon.  It's an excellent direction on how
convention can save effort.

But, I'd like to see _implementation_ save effort as well, if that makes
sense.  For the same reason that we do spec specs/*.  Because it's
easy.  You don't think about it.

I'm all for building levees across Bad Directions, but I'm more for
digging the river deeper under Good Directions.

Judson





From lists-rspec at shopwatch.org  Mon Aug 28 20:16:38 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Mon, 28 Aug 2006 20:16:38 -0400
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
Message-ID: <44F38766.7080805@shopwatch.org>

I'm developing an engine that I'd like to design with rspec.  I 
generated rspec in the main (stub) application, and then moved the spec 
folder to the engine.  Some quick modifications to the environment and 
fixtures paths in spec_helper.rb got me running, but I'd like to be able 
to use rails_spec_runner now that it's working.

I start rails_spec_runner in the main rails dir, and then in a separate 
shell I type "script/rails_spec vendor/plugins/myplugin/spec/*".  It 
mostly works, but the output is a bit noisy; I get some "already 
initialized constant" warnings, and the backtrace seems to include all 
of drb as well as rspec_on_rails.  Specifics below:

--------

$ script/rails_spec vendor/plugins/myplugin/spec/*
/cygdrive/c/dev/src/eclipse/myplugin/config/environment.rb:8: warning: 
already initialized constant RAILS_GEM_VERSION
script/../config/../vendor/plugins/myplugin/init_engine.rb:4: warning: 
already initialized constant Major
script/../config/../vendor/plugins/myplugin/init_engine.rb:5: warning: 
already initialized constant Minor
script/../config/../vendor/plugins/myplugin/init_engine.rb:6: warning: 
already initialized constant Release

.F

1)
Spec::Api::ExpectationNotMetError in 'myplugin class with fixtures 
loaded should have more specifications'
not enough specs
./vendor/plugins/myplugin/spec/models/myplugin_spec.rb:11:in `should 
have more specifications'
./script/../config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:103:in 
`run'
script/rails_spec_runner:26:in `run'
/usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
/usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
/usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
/usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
/usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
/usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
/usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
/usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
/usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
script/rails_spec_runner:47


From aslak.hellesoy at gmail.com  Mon Aug 28 20:56:28 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 29 Aug 2006 02:56:28 +0200
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F38766.7080805@shopwatch.org>
References: <44F38766.7080805@shopwatch.org>
Message-ID: <8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>

On 8/29/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> I'm developing an engine that I'd like to design with rspec.  I
> generated rspec in the main (stub) application, and then moved the spec
> folder to the engine.  Some quick modifications to the environment and
> fixtures paths in spec_helper.rb got me running, but I'd like to be able
> to use rails_spec_runner now that it's working.
>
> I start rails_spec_runner in the main rails dir, and then in a separate
> shell I type "script/rails_spec vendor/plugins/myplugin/spec/*".  It
> mostly works, but the output is a bit noisy; I get some "already
> initialized constant" warnings, and the backtrace seems to include all
> of drb as well as rspec_on_rails.  Specifics below:
>
> --------
>
> $ script/rails_spec vendor/plugins/myplugin/spec/*
> /cygdrive/c/dev/src/eclipse/myplugin/config/environment.rb:8: warning:
> already initialized constant RAILS_GEM_VERSION
> script/../config/../vendor/plugins/myplugin/init_engine.rb:4: warning:
> already initialized constant Major
> script/../config/../vendor/plugins/myplugin/init_engine.rb:5: warning:
> already initialized constant Minor
> script/../config/../vendor/plugins/myplugin/init_engine.rb:6: warning:
> already initialized constant Release
>
> .F
>
> 1)
> Spec::Api::ExpectationNotMetError in 'myplugin class with fixtures
> loaded should have more specifications'
> not enough specs
> ./vendor/plugins/myplugin/spec/models/myplugin_spec.rb:11:in `should
> have more specifications'
> ./script/../config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:103:in
> `run'
> script/rails_spec_runner:26:in `run'
> /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
> /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
> /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
> /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
> /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
> /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
> /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
> /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
> /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
> script/rails_spec_runner:47
>

I've seen those myself I think.
Could you please submit a bug report for each of these issues?

Apart from annoying warnings is it working okay with multiple runs?

Cheers,
Aslak

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

From lists-rspec at shopwatch.org  Mon Aug 28 21:05:56 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Mon, 28 Aug 2006 21:05:56 -0400
Subject: [Rspec-devel] Adding spec helpers in rails
Message-ID: <44F392F4.3080701@jay.fm>

Using rspec 0.5.13, I had a bunch of helpers defined like so at the end 
of spec_helper.rb:

class Spec::Runner::Context 
  def fields_should_start_empty(obj, *fields)
    fields.flatten.each do |f|
      specify "should have an empty #{f} field" do
        eval(obj.id2name + ".#{f}.should.be.nil")
      end
    end
  end

In 0.6.2, this doesn't seem to work.  I've tried adding them instead to

module Spec
  module Runner
    class Context
      module InstanceMethods

but that didn't work.  I also tried simply defining them in SpecTestCase 
the way setup, teardown and run are, but no matter where I try defining 
them, I get:

/usr/lib/ruby/gems/1.8/gems/rspec-0.6.2/lib/spec/api/sugar.rb:16:in 
`call': undefined method `fields_should_start_empty' for 
#<Module:0x4fca630> (NoMethodError)

Any tips?

Jay Levitt



From dchelimsky at gmail.com  Mon Aug 28 21:59:49 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Mon, 28 Aug 2006 21:59:49 -0400
Subject: [Rspec-devel] should_output proof-of-concept
In-Reply-To: <20060828004944.VCMM10406.fep01-app.kolumbus.fi@smtp.kolumbus.fi>
References: <20060828004944.VCMM10406.fep01-app.kolumbus.fi@smtp.kolumbus.fi>
Message-ID: <57c63afe0608281859s29cd6feasa4ea35891e60938d@mail.gmail.com>

On 8/27/06, E S <eero.saynatkari at kolumbus.fi> wrote:
> > L?hett?j?: "David Chelimsky" <dchelimsky at gmail.com>
> > P?iv?ys: 2006/08/27 su PM 07:06:10 EEST
> > Vastaanottaja: rspec-devel at rubyforge.org
> > Aihe: Re: [Rspec-devel] should_output proof-of-concept
> >
> > Even without a patch, would you please submit this as a feature
> > request at rubyforge?
>
> Done. Added a workaround for Readline.
>
> > I like this idea. Anyone else?
> >
> > Thanks,
> > David
> >
> > On 8/26/06, E S <eero.saynatkari at kolumbus.fi> wrote:
> > > Hi! Sorry if this is the wrong place--and apologies that
> > > this is not in patch format (I do not have SVN access and
> > > did not want to try to patch from 0.6.1). I currently just
> > > have this hacked in a helper lib I #require for the specs.
> > > I was briefly pondering about something similar for input
> > > but that is more of a context than specification thing.
> > >
> > > Thoughts?
> > >
> > > # Usage examples:
> > >
> > >  lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output "foo\n"
> > >  lambda {UI.mainloop {|ui| ui.output 'foo'}}.should_output /foo\n/
> > >
> > >  lambda {UI.mainloop {|ui| ui.error 'foo'}}.should_output "foo\n", :to => '$stderr'
> > >
> > > # Code:
> > >
> > > # Modify RSpec a little
> > > module Spec
> > >   class ShouldHelper
> > >
> > >     # Verify output from block is expected
> > >     def output(expected, io = {:to => '$stdout'})
> > >       to = io[:to]
> > >
> > >       # Store the old value
> > >       eval "#{to}, old_to = StringIO.new(''), #{to}"
> > >
> > >       @target.call
> > >       eval(to).rewind
> > >       output = eval(to).read
> > >
> > >       # Match up
> > >       case expected
> > >         when Regexp
> > >           output.should_match expected
> > >         else
> > >           output.should_equal expected
> > >       end                             # case expected
> > >
> > >     # Clean up
> > >     ensure
> > >       eval "#{to} = old_to"
> > >     end                               # output()
> > >   end                                 # ShouldHelper
> > > end                                   # Spec

Thanks for putting it on the site.

By any chance, do you have any tests? We'd like to keep the code coverage high.

Thanks,
David

From luke at agileevolved.com  Tue Aug 29 06:48:23 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 29 Aug 2006 11:48:23 +0100
Subject: [Rspec-devel] (no subject)
Message-ID: <0BEFBD78-6519-4B07-8A79-633EE9BF9533@agileevolved.com>

Hi guys, I'm working on a two part article, aimed at BDD/RSpec  
beginners mainly, but also those interested in how to apply BDD  
principles to Rails development. Its entitled "Developing a Rails  
model using BDD" and the first part draft is here:

http://123.writeboard.com/1fb9120e320c6a92e

Password is agile2006

The article is a breakdown of my general workflow and the techniques  
I use when writing my Rails specs.

All feedback would be greatly appreciated; I want to publish this bad  
boy later today on my blog. Pointing out grammar/spelling issues is  
great but most important are any technical errors.

Cheers
Luke

From luke at agileevolved.com  Tue Aug 29 06:49:45 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 29 Aug 2006 11:49:45 +0100
Subject: [Rspec-devel] Strange RSpec/Rails problem
Message-ID: <7744AE4F-4C7D-4D7A-85E6-52A87DBFF42A@agileevolved.com>

NOTE: Please ignore the other version of this mail sitting in the  
moderation queue - I sent it with the wrong email address.

I'm in the process of writing an RSpec/Rails tutorial and I just  
created a new Rails project to test out my tutorial code. However,  
when I run the specs, I get the following strange error:

NoMethodError in 'A user (in general) should be invalid without a  
username'
You have a nil object when you didn't expect it!
You might have expected an instance of Array.
The error occured while evaluating nil.-
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ 
active_record/transactions.rb:112:in `unlock_mutex'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ 
active_record/fixtures.rb:534:in `teardown_with_fixtures'
/usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/ 
active_record/fixtures.rb:556:in `teardown'
./spec/models/../spec_helper.rb:23:in `teardown'
/Users/luke/Sandbox/misc/rspec_tutorial/config/../vendor/plugins/ 
rspec/lib/rspec_on_rails.rb:103:in `run'	
I'm using RSpec 0.6.2 and the latest RSpec on Rails plugin with Rails  
1.1.6. Any ideas what could be causing this? I've also tried freezing  
to edge revision 4727.

Cheers
Luke

From luke at agileevolved.com  Tue Aug 29 06:50:25 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 29 Aug 2006 11:50:25 +0100
Subject: [Rspec-devel] (no subject)
In-Reply-To: <0BEFBD78-6519-4B07-8A79-633EE9BF9533@agileevolved.com>
References: <0BEFBD78-6519-4B07-8A79-633EE9BF9533@agileevolved.com>
Message-ID: <24238A30-5716-4A95-B2F4-8485A970B261@agileevolved.com>

Er, apologies for the missing subject. Should have said "RSpec/Rails  
Tutorial" ;)

On 29 Aug 2006, at 11:48, Luke Redpath wrote:

> Hi guys, I'm working on a two part article, aimed at BDD/RSpec
> beginners mainly, but also those interested in how to apply BDD
> principles to Rails development. Its entitled "Developing a Rails
> model using BDD" and the first part draft is here:
>
> http://123.writeboard.com/1fb9120e320c6a92e
>
> Password is agile2006
>
> The article is a breakdown of my general workflow and the techniques
> I use when writing my Rails specs.
>
> All feedback would be greatly appreciated; I want to publish this bad
> boy later today on my blog. Pointing out grammar/spelling issues is
> great but most important are any technical errors.
>
> Cheers
> Luke
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Tue Aug 29 06:55:56 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 29 Aug 2006 12:55:56 +0200
Subject: [Rspec-devel] Strange RSpec/Rails problem
In-Reply-To: <7744AE4F-4C7D-4D7A-85E6-52A87DBFF42A@agileevolved.com>
References: <7744AE4F-4C7D-4D7A-85E6-52A87DBFF42A@agileevolved.com>
Message-ID: <8d961d900608290355i169daa7eu4f430168e2a7667f@mail.gmail.com>

On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
> NOTE: Please ignore the other version of this mail sitting in the
> moderation queue - I sent it with the wrong email address.
>
> I'm in the process of writing an RSpec/Rails tutorial and I just
> created a new Rails project to test out my tutorial code. However,
> when I run the specs, I get the following strange error:
>
> NoMethodError in 'A user (in general) should be invalid without a
> username'
> You have a nil object when you didn't expect it!
> You might have expected an instance of Array.
> The error occured while evaluating nil.-
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
> active_record/transactions.rb:112:in `unlock_mutex'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
> active_record/fixtures.rb:534:in `teardown_with_fixtures'
> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
> active_record/fixtures.rb:556:in `teardown'
> ./spec/models/../spec_helper.rb:23:in `teardown'
> /Users/luke/Sandbox/misc/rspec_tutorial/config/../vendor/plugins/
> rspec/lib/rspec_on_rails.rb:103:in `run'
> I'm using RSpec 0.6.2 and the latest RSpec on Rails plugin with Rails
> 1.1.6. Any ideas what could be causing this? I've also tried freezing
> to edge revision 4727.
>

Can you share some code that we can use to reproduce this?
Preferrably as a patch to RSpec's demo rails app under vendor/rspec_on_rails

Cheers,
Aslak

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

From luke at agileevolved.com  Tue Aug 29 07:07:27 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 29 Aug 2006 12:07:27 +0100
Subject: [Rspec-devel] Strange RSpec/Rails problem
In-Reply-To: <8d961d900608290355i169daa7eu4f430168e2a7667f@mail.gmail.com>
References: <7744AE4F-4C7D-4D7A-85E6-52A87DBFF42A@agileevolved.com>
	<8d961d900608290355i169daa7eu4f430168e2a7667f@mail.gmail.com>
Message-ID: <8A5F0B04-0D23-4387-BF83-602C60C6A822@agileevolved.com>

Aslak, I can get this error by simply generating a new Rails app,  
installing the RSpec on Rails plugin, doing the script/generate rspec  
installation then creating a single spec that is as simple as this:

context "Foo" do
   specify "whatever"
     #nothing here
   end
end

The strange thing is that I have an existing app elsewhere with a  
whole suite of specs that are running fine. The only difference is  
that it is using an older version of the RSpec on Rails plugin  
(around 0.5.6 I think).

Cheers
Luke

On 29 Aug 2006, at 11:55, aslak hellesoy wrote:

> On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
>> NOTE: Please ignore the other version of this mail sitting in the
>> moderation queue - I sent it with the wrong email address.
>>
>> I'm in the process of writing an RSpec/Rails tutorial and I just
>> created a new Rails project to test out my tutorial code. However,
>> when I run the specs, I get the following strange error:
>>
>> NoMethodError in 'A user (in general) should be invalid without a
>> username'
>> You have a nil object when you didn't expect it!
>> You might have expected an instance of Array.
>> The error occured while evaluating nil.-
>> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
>> active_record/transactions.rb:112:in `unlock_mutex'
>> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
>> active_record/fixtures.rb:534:in `teardown_with_fixtures'
>> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
>> active_record/fixtures.rb:556:in `teardown'
>> ./spec/models/../spec_helper.rb:23:in `teardown'
>> /Users/luke/Sandbox/misc/rspec_tutorial/config/../vendor/plugins/
>> rspec/lib/rspec_on_rails.rb:103:in `run'
>> I'm using RSpec 0.6.2 and the latest RSpec on Rails plugin with Rails
>> 1.1.6. Any ideas what could be causing this? I've also tried freezing
>> to edge revision 4727.
>>
>
> Can you share some code that we can use to reproduce this?
> Preferrably as a patch to RSpec's demo rails app under vendor/ 
> rspec_on_rails
>
> Cheers,
> Aslak
>
>> Cheers
>> Luke
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From daniel at dr-siemssen.de  Tue Aug 29 07:28:47 2006
From: daniel at dr-siemssen.de (Daniel Siemssen)
Date: Tue, 29 Aug 2006 13:28:47 +0200
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>
References: <44F38766.7080805@shopwatch.org>
	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>
Message-ID: <44F424EF.3060203@dr-siemssen.de>

On 29.08.2006 02:56, aslak hellesoy wrote:
> On 8/29/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>   
>> I'm developing an engine that I'd like to design with rspec.  I
>> generated rspec in the main (stub) application, and then moved the spec
>> folder to the engine.  Some quick modifications to the environment and
>> fixtures paths in spec_helper.rb got me running, but I'd like to be able
>> to use rails_spec_runner now that it's working.
>>
>> I start rails_spec_runner in the main rails dir, and then in a separate
>> shell I type "script/rails_spec vendor/plugins/myplugin/spec/*".  It
>> mostly works, but the output is a bit noisy; I get some "already
>> initialized constant" warnings, and the backtrace seems to include all
>> of drb as well as rspec_on_rails.  Specifics below:
>>
>> --------
>>
>> $ script/rails_spec vendor/plugins/myplugin/spec/*
>> /cygdrive/c/dev/src/eclipse/myplugin/config/environment.rb:8: warning:
>> already initialized constant RAILS_GEM_VERSION
>> script/../config/../vendor/plugins/myplugin/init_engine.rb:4: warning:
>> already initialized constant Major
>> script/../config/../vendor/plugins/myplugin/init_engine.rb:5: warning:
>> already initialized constant Minor
>> script/../config/../vendor/plugins/myplugin/init_engine.rb:6: warning:
>> already initialized constant Release
>>
>> .F
>>
>> 1)
>> Spec::Api::ExpectationNotMetError in 'myplugin class with fixtures
>> loaded should have more specifications'
>> not enough specs
>> ./vendor/plugins/myplugin/spec/models/myplugin_spec.rb:11:in `should
>> have more specifications'
>> ./script/../config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:103:in
>> `run'
>> script/rails_spec_runner:26:in `run'
>> /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
>> /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
>> /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
>> /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
>> /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
>> /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
>> /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
>> /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
>> /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
>> script/rails_spec_runner:47
>>
>>     
>
> I've seen those myself I think.
> Could you please submit a bug report for each of these issues?
>
> Apart from annoying warnings is it working okay with multiple runs?
>
> Cheers,
> Aslak
>
>   
>> _______________________________________________
>> 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
>   
Patch submitted (see tracker).

From dchelimsky at gmail.com  Tue Aug 29 07:29:05 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Tue, 29 Aug 2006 07:29:05 -0400
Subject: [Rspec-devel] (no subject)
In-Reply-To: <24238A30-5716-4A95-B2F4-8485A970B261@agileevolved.com>
References: <0BEFBD78-6519-4B07-8A79-633EE9BF9533@agileevolved.com>
	<24238A30-5716-4A95-B2F4-8485A970B261@agileevolved.com>
Message-ID: <57c63afe0608290429u26d00343hcc65317ff54fb3de@mail.gmail.com>

Nice work Luke. Thanks for promoting the goodness....

The CRC_Card link doesn't go anywhere useful.

The spec that you wrote:

context "A user (in general)" do
  def setup
    @user = User.new
  end

  specify "should be invalid without a username" do
    @user.should_not_be_valid
    @user.username = 'someusername'
    @user.should_be_valid
  end
end

does something that I try to avoid - it sets one expectation, then
changes state, then sets a new expectation. The way I look at this is
that a user with a username and a user without one are two different
contexts. So I'd write this instead (note - "I'd write" - this is my
personal view):

context "A user with no username" do
  def setup
    @user = User.new
  end

  specify "should be invalid" do
    @user.should_not_be_valid
  end
end

context "A user with a username" do
  def setup
    @user = User.new
    @user.username = 'someusername'
  end

  specify "should be invalid" do
    @user.should_be_valid
  end
end

Taking this approach leads to much more granular specs. The down side
is there end up w/ many more specs.

I'd like to take more time but I've got to run. Given that you're
planning to post this soon, I thought I'd get this little bit in.

Cheers,
David




On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
> Er, apologies for the missing subject. Should have said "RSpec/Rails
> Tutorial" ;)
>
> On 29 Aug 2006, at 11:48, Luke Redpath wrote:
>
> > Hi guys, I'm working on a two part article, aimed at BDD/RSpec
> > beginners mainly, but also those interested in how to apply BDD
> > principles to Rails development. Its entitled "Developing a Rails
> > model using BDD" and the first part draft is here:
> >
> > http://123.writeboard.com/1fb9120e320c6a92e
> >
> > Password is agile2006
> >
> > The article is a breakdown of my general workflow and the techniques
> > I use when writing my Rails specs.
> >
> > All feedback would be greatly appreciated; I want to publish this bad
> > boy later today on my blog. Pointing out grammar/spelling issues is
> > great but most important are any technical errors.
> >
> > Cheers
> > Luke
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From luke at agileevolved.com  Tue Aug 29 07:43:01 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 29 Aug 2006 12:43:01 +0100
Subject: [Rspec-devel] (no subject)
In-Reply-To: <57c63afe0608290429u26d00343hcc65317ff54fb3de@mail.gmail.com>
References: <0BEFBD78-6519-4B07-8A79-633EE9BF9533@agileevolved.com>
	<24238A30-5716-4A95-B2F4-8485A970B261@agileevolved.com>
	<57c63afe0608290429u26d00343hcc65317ff54fb3de@mail.gmail.com>
Message-ID: <5D14493D-2E51-4AD4-8356-51F8DF2E9ED7@agileevolved.com>

Hi David

Thanks for your comments. I agree that finer grained specs can be  
useful in some situations but in this situation having a context for  
each attribute, with and without, is more verbose than it needs to  
be. Its worth mentioning that the last two lines of the specs will be  
refactored out in the second part of the article. The reason they are  
there to begin with is that just testing a user without a username is  
invalid only partly tests the specification in my opinion. By setting  
the username then checking it is valid, the spec is fully tested.

My final spec would see all of the set/revalidate lines removed into  
a single spec:

specify "should be valid with a complete set of valid attributes" do
   @user.attributes = valid_user_attributes
   @user.should_be_valid
end

That single spec eliminates the need for the verbosity in the other  
specs, but I want to approach my article in a "get things working,  
then refactor" style.

Thanks for the heads up on the CRC link, I've fixed that.

Cheers
Luke

On 29 Aug 2006, at 12:29, David Chelimsky wrote:

> Nice work Luke. Thanks for promoting the goodness....
>
> The CRC_Card link doesn't go anywhere useful.
>
> The spec that you wrote:
>
> context "A user (in general)" do
>   def setup
>     @user = User.new
>   end
>
>   specify "should be invalid without a username" do
>     @user.should_not_be_valid
>     @user.username = 'someusername'
>     @user.should_be_valid
>   end
> end
>
> does something that I try to avoid - it sets one expectation, then
> changes state, then sets a new expectation. The way I look at this is
> that a user with a username and a user without one are two different
> contexts. So I'd write this instead (note - "I'd write" - this is my
> personal view):
>
> context "A user with no username" do
>   def setup
>     @user = User.new
>   end
>
>   specify "should be invalid" do
>     @user.should_not_be_valid
>   end
> end
>
> context "A user with a username" do
>   def setup
>     @user = User.new
>     @user.username = 'someusername'
>   end
>
>   specify "should be invalid" do
>     @user.should_be_valid
>   end
> end
>
> Taking this approach leads to much more granular specs. The down side
> is there end up w/ many more specs.
>
> I'd like to take more time but I've got to run. Given that you're
> planning to post this soon, I thought I'd get this little bit in.
>
> Cheers,
> David
>
>
>
>
> On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
>> Er, apologies for the missing subject. Should have said "RSpec/Rails
>> Tutorial" ;)
>>
>> On 29 Aug 2006, at 11:48, Luke Redpath wrote:
>>
>>> Hi guys, I'm working on a two part article, aimed at BDD/RSpec
>>> beginners mainly, but also those interested in how to apply BDD
>>> principles to Rails development. Its entitled "Developing a Rails
>>> model using BDD" and the first part draft is here:
>>>
>>> http://123.writeboard.com/1fb9120e320c6a92e
>>>
>>> Password is agile2006
>>>
>>> The article is a breakdown of my general workflow and the techniques
>>> I use when writing my Rails specs.
>>>
>>> All feedback would be greatly appreciated; I want to publish this  
>>> bad
>>> boy later today on my blog. Pointing out grammar/spelling issues is
>>> great but most important are any technical errors.
>>>
>>> Cheers
>>> Luke
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From aslak.hellesoy at gmail.com  Tue Aug 29 07:43:24 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 29 Aug 2006 13:43:24 +0200
Subject: [Rspec-devel] Strange RSpec/Rails problem
In-Reply-To: <8A5F0B04-0D23-4387-BF83-602C60C6A822@agileevolved.com>
References: <7744AE4F-4C7D-4D7A-85E6-52A87DBFF42A@agileevolved.com>
	<8d961d900608290355i169daa7eu4f430168e2a7667f@mail.gmail.com>
	<8A5F0B04-0D23-4387-BF83-602C60C6A822@agileevolved.com>
Message-ID: <8d961d900608290443p7945a24bw8725353edfb3db11@mail.gmail.com>

On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
> Aslak, I can get this error by simply generating a new Rails app,
> installing the RSpec on Rails plugin, doing the script/generate rspec
> installation then creating a single spec that is as simple as this:
>
> context "Foo" do
>    specify "whatever"
>      #nothing here
>    end
> end
>
> The strange thing is that I have an existing app elsewhere with a
> whole suite of specs that are running fine. The only difference is
> that it is using an older version of the RSpec on Rails plugin
> (around 0.5.6 I think).
>
> Cheers
> Luke
>

Here is how I tried to reproduce this:

1) Uninstall my old 1.1.4 rails:
sudo gem uninstall activesupport
sudo gem uninstall activerecord
sudo gem uninstall actionpack
sudo gem uninstall actionmailer
sudo gem uninstall actionwebservice

2) Install Rails 1.1.6
sudo gem install -y rails

3) Uninstall my old RSpec
sudo gem uninstall rspec

4) Install RSpec 0.6.2
sudo gem install rspec

5) Create a new rails app with rspec
rails rspec_test
cd rspec_test
ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_6_2/ven
dor/rspec_on_rails/vendor/plugins/rspec
script/generate rspec

6) Create a dummy spec in spec/spec.rb:

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

context "Foo" do
  specify "whatever" do
    #nothing here
  end
end

7) Run the spec
spec spec/spec.rb

.

Finished in 0.026393 seconds

1 specification, 0 failures

-------

I'm unable to reproduce your problem. Are you sure you don't have
old/incompatible stuff lying around?

Aslak

> On 29 Aug 2006, at 11:55, aslak hellesoy wrote:
>
> > On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
> >> NOTE: Please ignore the other version of this mail sitting in the
> >> moderation queue - I sent it with the wrong email address.
> >>
> >> I'm in the process of writing an RSpec/Rails tutorial and I just
> >> created a new Rails project to test out my tutorial code. However,
> >> when I run the specs, I get the following strange error:
> >>
> >> NoMethodError in 'A user (in general) should be invalid without a
> >> username'
> >> You have a nil object when you didn't expect it!
> >> You might have expected an instance of Array.
> >> The error occured while evaluating nil.-
> >> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
> >> active_record/transactions.rb:112:in `unlock_mutex'
> >> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
> >> active_record/fixtures.rb:534:in `teardown_with_fixtures'
> >> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
> >> active_record/fixtures.rb:556:in `teardown'
> >> ./spec/models/../spec_helper.rb:23:in `teardown'
> >> /Users/luke/Sandbox/misc/rspec_tutorial/config/../vendor/plugins/
> >> rspec/lib/rspec_on_rails.rb:103:in `run'
> >> I'm using RSpec 0.6.2 and the latest RSpec on Rails plugin with Rails
> >> 1.1.6. Any ideas what could be causing this? I've also tried freezing
> >> to edge revision 4727.
> >>
> >
> > Can you share some code that we can use to reproduce this?
> > Preferrably as a patch to RSpec's demo rails app under vendor/
> > rspec_on_rails
> >
> > Cheers,
> > Aslak
> >
> >> Cheers
> >> Luke
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From luke at agileevolved.com  Tue Aug 29 07:44:26 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 29 Aug 2006 12:44:26 +0100
Subject: [Rspec-devel] (no subject)
In-Reply-To: <57c63afe0608290429u26d00343hcc65317ff54fb3de@mail.gmail.com>
References: <0BEFBD78-6519-4B07-8A79-633EE9BF9533@agileevolved.com>
	<24238A30-5716-4A95-B2F4-8485A970B261@agileevolved.com>
	<57c63afe0608290429u26d00343hcc65317ff54fb3de@mail.gmail.com>
Message-ID: <E89A16E5-F215-40D4-8751-93118A1374DE@agileevolved.com>

Actually, thinking about it, I think I'll add that final refactoring  
to the end of this article instead.

Cheers
Luke

On 29 Aug 2006, at 12:29, David Chelimsky wrote:

> Nice work Luke. Thanks for promoting the goodness....
>
> The CRC_Card link doesn't go anywhere useful.
>
> The spec that you wrote:
>
> context "A user (in general)" do
>   def setup
>     @user = User.new
>   end
>
>   specify "should be invalid without a username" do
>     @user.should_not_be_valid
>     @user.username = 'someusername'
>     @user.should_be_valid
>   end
> end
>
> does something that I try to avoid - it sets one expectation, then
> changes state, then sets a new expectation. The way I look at this is
> that a user with a username and a user without one are two different
> contexts. So I'd write this instead (note - "I'd write" - this is my
> personal view):
>
> context "A user with no username" do
>   def setup
>     @user = User.new
>   end
>
>   specify "should be invalid" do
>     @user.should_not_be_valid
>   end
> end
>
> context "A user with a username" do
>   def setup
>     @user = User.new
>     @user.username = 'someusername'
>   end
>
>   specify "should be invalid" do
>     @user.should_be_valid
>   end
> end
>
> Taking this approach leads to much more granular specs. The down side
> is there end up w/ many more specs.
>
> I'd like to take more time but I've got to run. Given that you're
> planning to post this soon, I thought I'd get this little bit in.
>
> Cheers,
> David
>
>
>
>
> On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
>> Er, apologies for the missing subject. Should have said "RSpec/Rails
>> Tutorial" ;)
>>
>> On 29 Aug 2006, at 11:48, Luke Redpath wrote:
>>
>>> Hi guys, I'm working on a two part article, aimed at BDD/RSpec
>>> beginners mainly, but also those interested in how to apply BDD
>>> principles to Rails development. Its entitled "Developing a Rails
>>> model using BDD" and the first part draft is here:
>>>
>>> http://123.writeboard.com/1fb9120e320c6a92e
>>>
>>> Password is agile2006
>>>
>>> The article is a breakdown of my general workflow and the techniques
>>> I use when writing my Rails specs.
>>>
>>> All feedback would be greatly appreciated; I want to publish this  
>>> bad
>>> boy later today on my blog. Pointing out grammar/spelling issues is
>>> great but most important are any technical errors.
>>>
>>> Cheers
>>> Luke
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From luke at agileevolved.com  Tue Aug 29 07:56:50 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 29 Aug 2006 12:56:50 +0100
Subject: [Rspec-devel] Strange RSpec/Rails problem
In-Reply-To: <8d961d900608290443p7945a24bw8725353edfb3db11@mail.gmail.com>
References: <7744AE4F-4C7D-4D7A-85E6-52A87DBFF42A@agileevolved.com>
	<8d961d900608290355i169daa7eu4f430168e2a7667f@mail.gmail.com>
	<8A5F0B04-0D23-4387-BF83-602C60C6A822@agileevolved.com>
	<8d961d900608290443p7945a24bw8725353edfb3db11@mail.gmail.com>
Message-ID: <381A53AD-527B-49A8-97C8-EB3FE807210C@agileevolved.com>

I'll try cleaning up my gems; perhaps thats the issue.

I'll report back shortly.

Cheers
Luke

On 29 Aug 2006, at 12:43, aslak hellesoy wrote:

> On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
>> Aslak, I can get this error by simply generating a new Rails app,
>> installing the RSpec on Rails plugin, doing the script/generate rspec
>> installation then creating a single spec that is as simple as this:
>>
>> context "Foo" do
>>    specify "whatever"
>>      #nothing here
>>    end
>> end
>>
>> The strange thing is that I have an existing app elsewhere with a
>> whole suite of specs that are running fine. The only difference is
>> that it is using an older version of the RSpec on Rails plugin
>> (around 0.5.6 I think).
>>
>> Cheers
>> Luke
>>
>
> Here is how I tried to reproduce this:
>
> 1) Uninstall my old 1.1.4 rails:
> sudo gem uninstall activesupport
> sudo gem uninstall activerecord
> sudo gem uninstall actionpack
> sudo gem uninstall actionmailer
> sudo gem uninstall actionwebservice
>
> 2) Install Rails 1.1.6
> sudo gem install -y rails
>
> 3) Uninstall my old RSpec
> sudo gem uninstall rspec
>
> 4) Install RSpec 0.6.2
> sudo gem install rspec
>
> 5) Create a new rails app with rspec
> rails rspec_test
> cd rspec_test
> ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/ 
> REL_0_6_2/ven
> dor/rspec_on_rails/vendor/plugins/rspec
> script/generate rspec
>
> 6) Create a dummy spec in spec/spec.rb:
>
> require File.dirname(__FILE__) + '/spec_helper'
>
> context "Foo" do
>   specify "whatever" do
>     #nothing here
>   end
> end
>
> 7) Run the spec
> spec spec/spec.rb
>
> .
>
> Finished in 0.026393 seconds
>
> 1 specification, 0 failures
>
> -------
>
> I'm unable to reproduce your problem. Are you sure you don't have
> old/incompatible stuff lying around?
>
> Aslak
>
>> On 29 Aug 2006, at 11:55, aslak hellesoy wrote:
>>
>>> On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
>>>> NOTE: Please ignore the other version of this mail sitting in the
>>>> moderation queue - I sent it with the wrong email address.
>>>>
>>>> I'm in the process of writing an RSpec/Rails tutorial and I just
>>>> created a new Rails project to test out my tutorial code. However,
>>>> when I run the specs, I get the following strange error:
>>>>
>>>> NoMethodError in 'A user (in general) should be invalid without a
>>>> username'
>>>> You have a nil object when you didn't expect it!
>>>> You might have expected an instance of Array.
>>>> The error occured while evaluating nil.-
>>>> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
>>>> active_record/transactions.rb:112:in `unlock_mutex'
>>>> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
>>>> active_record/fixtures.rb:534:in `teardown_with_fixtures'
>>>> /usr/local/lib/ruby/gems/1.8/gems/activerecord-1.14.4/lib/
>>>> active_record/fixtures.rb:556:in `teardown'
>>>> ./spec/models/../spec_helper.rb:23:in `teardown'
>>>> /Users/luke/Sandbox/misc/rspec_tutorial/config/../vendor/plugins/
>>>> rspec/lib/rspec_on_rails.rb:103:in `run'
>>>> I'm using RSpec 0.6.2 and the latest RSpec on Rails plugin with  
>>>> Rails
>>>> 1.1.6. Any ideas what could be causing this? I've also tried  
>>>> freezing
>>>> to edge revision 4727.
>>>>
>>>
>>> Can you share some code that we can use to reproduce this?
>>> Preferrably as a patch to RSpec's demo rails app under vendor/
>>> rspec_on_rails
>>>
>>> Cheers,
>>> Aslak
>>>
>>>> Cheers
>>>> Luke
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From lists-rspec at shopwatch.org  Tue Aug 29 08:32:33 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 29 Aug 2006 08:32:33 -0400
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F424EF.3060203@dr-siemssen.de>
References: <44F38766.7080805@shopwatch.org>	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>
	<44F424EF.3060203@dr-siemssen.de>
Message-ID: <44F433E1.5080502@rubyforge.org>

Daniel Siemssen wrote:
> Patch submitted (see tracker).

Thanks! That solves the duplicate environment, but I still get the drb 
backtrace lines:

$ script/rails_spec vendor/plugins/hark/spec/*

..F

1)
Spec::Api::ExpectationNotMetError in 'Vlad the valid user new spec'
testing
./vendor/plugins/hark/spec/models/harkee_spec.rb:32:in `new spec'
/cygdrive/c/dev/src/eclipse/hark/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:103:in 
`run'
script/rails_spec_runner:26:in `run'
/usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
/usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
/usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
/usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
/usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
/usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
/usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
/usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
/usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
script/rails_spec_runner:47

Finished in 0.187 seconds

4 specifications, 1 failure


From aslak.hellesoy at gmail.com  Tue Aug 29 09:08:00 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 29 Aug 2006 15:08:00 +0200
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F433E1.5080502@rubyforge.org>
References: <44F38766.7080805@shopwatch.org>
	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>
	<44F424EF.3060203@dr-siemssen.de> <44F433E1.5080502@rubyforge.org>
Message-ID: <8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>

On 8/29/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> Daniel Siemssen wrote:
> > Patch submitted (see tracker).
>
> Thanks! That solves the duplicate environment, but I still get the drb
> backtrace lines:
>
> $ script/rails_spec vendor/plugins/hark/spec/*
>
> ..F
>
> 1)
> Spec::Api::ExpectationNotMetError in 'Vlad the valid user new spec'
> testing
> ./vendor/plugins/hark/spec/models/harkee_spec.rb:32:in `new spec'
> /cygdrive/c/dev/src/eclipse/hark/config/../vendor/plugins/rspec/lib/rspec_on_rails.rb:103:in
> `run'
> script/rails_spec_runner:26:in `run'
> /usr/lib/ruby/1.8/drb/drb.rb:1552:in `perform_without_block'
> /usr/lib/ruby/1.8/drb/drb.rb:1512:in `perform'
> /usr/lib/ruby/1.8/drb/drb.rb:1586:in `main_loop'
> /usr/lib/ruby/1.8/drb/drb.rb:1582:in `main_loop'
> /usr/lib/ruby/1.8/drb/drb.rb:1578:in `main_loop'
> /usr/lib/ruby/1.8/drb/drb.rb:1427:in `run'
> /usr/lib/ruby/1.8/drb/drb.rb:1424:in `run'
> /usr/lib/ruby/1.8/drb/drb.rb:1344:in `initialize'
> /usr/lib/ruby/1.8/drb/drb.rb:1624:in `start_service'
> script/rails_spec_runner:47
>

This is now fixed on trunk, so you'll get backtraces like:

1)
Spec::Api::ExpectationNotMetError in 'Vlad the valid user new spec'
testing
./vendor/plugins/hark/spec/models/harkee_spec.rb:32:in `new spec'

By the way - 'Vlad the valid user new spec' reads kind of funny. Have
you tried to run your specs with '-d -f s' ?

It should read *well*

Aslak

> Finished in 0.187 seconds
>
> 4 specifications, 1 failure
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>

From lists-rspec at shopwatch.org  Tue Aug 29 09:12:50 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 29 Aug 2006 09:12:50 -0400
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>
References: <44F38766.7080805@shopwatch.org>	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>	<44F424EF.3060203@dr-siemssen.de>
	<44F433E1.5080502@rubyforge.org>
	<8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>
Message-ID: <44F43D52.8020508@rubyforge.org>

aslak hellesoy wrote:
> By the way - 'Vlad the valid user new spec' reads kind of funny. Have
> you tried to run your specs with '-d -f s' ?

Hehe.. yeah, that was just me adding a new spec that would fail so I 
could get a backtrace to paste to the list.  It's not how I write specs!

Now, if only there was a way to get rails_spec_runner to reload plugins 
- but I guess that's Rails's fault, and maybe it'll be fixed in Edge 
with the new dependencies.

Jay


From aslak.hellesoy at gmail.com  Tue Aug 29 09:24:50 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 29 Aug 2006 15:24:50 +0200
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F43D52.8020508@rubyforge.org>
References: <44F38766.7080805@shopwatch.org>
	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>
	<44F424EF.3060203@dr-siemssen.de> <44F433E1.5080502@rubyforge.org>
	<8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>
	<44F43D52.8020508@rubyforge.org>
Message-ID: <8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com>

On 8/29/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
> aslak hellesoy wrote:
> > By the way - 'Vlad the valid user new spec' reads kind of funny. Have
> > you tried to run your specs with '-d -f s' ?
>
> Hehe.. yeah, that was just me adding a new spec that would fail so I
> could get a backtrace to paste to the list.  It's not how I write specs!
>

Hehe - I was puzzled, because I thought you were one of the people who
'got it' ;-)

> Now, if only there was a way to get rails_spec_runner to reload plugins
> - but I guess that's Rails's fault, and maybe it'll be fixed in Edge
> with the new dependencies.
>

Sounds like that ball is in Rails' courtyard.

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

From luke at agileevolved.com  Tue Aug 29 09:51:18 2006
From: luke at agileevolved.com (Luke Redpath)
Date: Tue, 29 Aug 2006 14:51:18 +0100
Subject: [Rspec-devel] (no subject)
In-Reply-To: <E89A16E5-F215-40D4-8751-93118A1374DE@agileevolved.com>
References: <0BEFBD78-6519-4B07-8A79-633EE9BF9533@agileevolved.com>
	<24238A30-5716-4A95-B2F4-8485A970B261@agileevolved.com>
	<57c63afe0608290429u26d00343hcc65317ff54fb3de@mail.gmail.com>
	<E89A16E5-F215-40D4-8751-93118A1374DE@agileevolved.com>
Message-ID: <13E3C47E-43AB-4215-A118-B0BA1456ACE6@agileevolved.com>

OK I've made a few updates, added some notes on installing RSpec and  
made a few fixes.

http://www.lukeredpath.co.uk/2006/8/29/developing-a-rails-model-using- 
bdd-and-rspec-part-1

All feedback is welcomed!

Cheers
Luke

On 29 Aug 2006, at 12:44, Luke Redpath wrote:

> Actually, thinking about it, I think I'll add that final refactoring
> to the end of this article instead.
>
> Cheers
> Luke
>
> On 29 Aug 2006, at 12:29, David Chelimsky wrote:
>
>> Nice work Luke. Thanks for promoting the goodness....
>>
>> The CRC_Card link doesn't go anywhere useful.
>>
>> The spec that you wrote:
>>
>> context "A user (in general)" do
>>   def setup
>>     @user = User.new
>>   end
>>
>>   specify "should be invalid without a username" do
>>     @user.should_not_be_valid
>>     @user.username = 'someusername'
>>     @user.should_be_valid
>>   end
>> end
>>
>> does something that I try to avoid - it sets one expectation, then
>> changes state, then sets a new expectation. The way I look at this is
>> that a user with a username and a user without one are two different
>> contexts. So I'd write this instead (note - "I'd write" - this is my
>> personal view):
>>
>> context "A user with no username" do
>>   def setup
>>     @user = User.new
>>   end
>>
>>   specify "should be invalid" do
>>     @user.should_not_be_valid
>>   end
>> end
>>
>> context "A user with a username" do
>>   def setup
>>     @user = User.new
>>     @user.username = 'someusername'
>>   end
>>
>>   specify "should be invalid" do
>>     @user.should_be_valid
>>   end
>> end
>>
>> Taking this approach leads to much more granular specs. The down side
>> is there end up w/ many more specs.
>>
>> I'd like to take more time but I've got to run. Given that you're
>> planning to post this soon, I thought I'd get this little bit in.
>>
>> Cheers,
>> David
>>
>>
>>
>>
>> On 8/29/06, Luke Redpath <luke at agileevolved.com> wrote:
>>> Er, apologies for the missing subject. Should have said "RSpec/Rails
>>> Tutorial" ;)
>>>
>>> On 29 Aug 2006, at 11:48, Luke Redpath wrote:
>>>
>>>> Hi guys, I'm working on a two part article, aimed at BDD/RSpec
>>>> beginners mainly, but also those interested in how to apply BDD
>>>> principles to Rails development. Its entitled "Developing a Rails
>>>> model using BDD" and the first part draft is here:
>>>>
>>>> http://123.writeboard.com/1fb9120e320c6a92e
>>>>
>>>> Password is agile2006
>>>>
>>>> The article is a breakdown of my general workflow and the  
>>>> techniques
>>>> I use when writing my Rails specs.
>>>>
>>>> All feedback would be greatly appreciated; I want to publish this
>>>> bad
>>>> boy later today on my blog. Pointing out grammar/spelling issues is
>>>> great but most important are any technical errors.
>>>>
>>>> Cheers
>>>> Luke
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel


From lists-rspec at shopwatch.org  Tue Aug 29 09:59:27 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 29 Aug 2006 09:59:27 -0400
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com>
References: <44F38766.7080805@shopwatch.org>	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>	<44F424EF.3060203@dr-siemssen.de>
	<44F433E1.5080502@rubyforge.org>	<8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>	<44F43D52.8020508@rubyforge.org>
	<8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com>
Message-ID: <44F4483F.5070002@rubyforge.org>

aslak hellesoy wrote:
> On 8/29/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>> Now, if only there was a way to get rails_spec_runner to reload plugins
>> - but I guess that's Rails's fault, and maybe it'll be fixed in Edge
>> with the new dependencies.
> 
> Sounds like that ball is in Rails' courtyard.

Probably - but I wanted to check with Daniel, since he keeps coming up 
with clever solutions...

Jay


From daniel at dr-siemssen.de  Tue Aug 29 11:03:20 2006
From: daniel at dr-siemssen.de (Daniel Siemssen)
Date: Tue, 29 Aug 2006 17:03:20 +0200
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F4483F.5070002@rubyforge.org>
References: <44F38766.7080805@shopwatch.org>	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>	<44F424EF.3060203@dr-siemssen.de>	<44F433E1.5080502@rubyforge.org>	<8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>	<44F43D52.8020508@rubyforge.org>	<8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com>
	<44F4483F.5070002@rubyforge.org>
Message-ID: <44F45738.2080601@dr-siemssen.de>

On 29.08.2006 15:59, Jay Levitt wrote:
> aslak hellesoy wrote:
>   
>> On 8/29/06, Jay Levitt <lists-rspec at shopwatch.org> wrote:
>>     
>>> Now, if only there was a way to get rails_spec_runner to reload plugins
>>> - but I guess that's Rails's fault, and maybe it'll be fixed in Edge
>>> with the new dependencies.
>>>       
>> Sounds like that ball is in Rails' courtyard.
>>     
>
> Probably - but I wanted to check with Daniel, since he keeps coming up 
> with clever solutions...
>
> Jay
>
>   
What exactly does not get reloaded / What do you want to get reloaded?

Daniel

From lists-rspec at shopwatch.org  Tue Aug 29 11:13:57 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 29 Aug 2006 11:13:57 -0400
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F45738.2080601@dr-siemssen.de>
References: <44F38766.7080805@shopwatch.org>	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>	<44F424EF.3060203@dr-siemssen.de>	<44F433E1.5080502@rubyforge.org>	<8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>	<44F43D52.8020508@rubyforge.org>	<8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com>	<44F4483F.5070002@rubyforge.org>
	<44F45738.2080601@dr-siemssen.de>
Message-ID: <44F459B5.7010601@rubyforge.org>

Daniel Siemssen wrote:
>>   
> What exactly does not get reloaded / What do you want to get reloaded?

I'm writing an authentication engine with the fairly typical structure:

vendor/
   plugins/
     myplugin/
       lib/
         myplugin
           myplugin1.rb
           myplugin2.rb
         myplugin.rb

myplugin.rb reads, as you'd expect:

   require "myplugin/myplugin1"
   require "myplugin/myplugin2"

Those, in turn, populate the module Myplugin.  application.rb (and 
myplugin.rb) include Myplugin.

I'd like to be able to make changes to myplugin1.rb without having to 
restart rails_spec_runner.

It actually gets slightly trickier; myplugin1.rb borrows an idea from 
LoginEngine, and defines the user model instance methods as a module 
that gets dragged in by self.included.  That, in turn, uses .class_eval 
to load the attributes, and .extend to load the class methods.

If you're interested in tackling it, and if the trickiness is actually 
tricky, I can tar up what I've got so far and send it off-list.

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


From daniel at dr-siemssen.de  Tue Aug 29 12:16:58 2006
From: daniel at dr-siemssen.de (Daniel Siemssen)
Date: Tue, 29 Aug 2006 18:16:58 +0200
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F459B5.7010601@rubyforge.org>
References: <44F38766.7080805@shopwatch.org>	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>	<44F424EF.3060203@dr-siemssen.de>	<44F433E1.5080502@rubyforge.org>	<8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>	<44F43D52.8020508@rubyforge.org>	<8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com>	<44F4483F.5070002@rubyforge.org>	<44F45738.2080601@dr-siemssen.de>
	<44F459B5.7010601@rubyforge.org>
Message-ID: <44F4687A.2070203@dr-siemssen.de>

On 29.08.2006 17:13, Jay Levitt wrote:
> Daniel Siemssen wrote:
>   
>>>   
>>>       
>> What exactly does not get reloaded / What do you want to get reloaded?
>>     
>
> I'm writing an authentication engine with the fairly typical structure:
>
> vendor/
>    plugins/
>      myplugin/
>        lib/
>          myplugin
>            myplugin1.rb
>            myplugin2.rb
>          myplugin.rb
>
> myplugin.rb reads, as you'd expect:
>
>    require "myplugin/myplugin1"
>    require "myplugin/myplugin2"
>
> Those, in turn, populate the module Myplugin.  application.rb (and 
> myplugin.rb) include Myplugin.
>
> I'd like to be able to make changes to myplugin1.rb without having to 
> restart rails_spec_runner.
>
> It actually gets slightly trickier; myplugin1.rb borrows an idea from 
> LoginEngine, and defines the user model instance methods as a module 
> that gets dragged in by self.included.  That, in turn, uses .class_eval 
> to load the attributes, and .extend to load the class methods.
>
> If you're interested in tackling it, and if the trickiness is actually 
> tricky, I can tar up what I've got so far and send it off-list.
>
>   
>> Daniel
>> _______________________________________________
>> 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
>   
Seems like the new dependencies code in edge rails / rails 1.2 will
solve that if you use it's naming convention so that your libs get
autoloaded. I don't think that it's worth to put too much time in
producing something that achieves the same.

Daniel

From lists-rspec at shopwatch.org  Tue Aug 29 13:40:12 2006
From: lists-rspec at shopwatch.org (Jay Levitt)
Date: Tue, 29 Aug 2006 13:40:12 -0400
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F4687A.2070203@dr-siemssen.de>
References: <44F38766.7080805@shopwatch.org>	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>	<44F424EF.3060203@dr-siemssen.de>	<44F433E1.5080502@rubyforge.org>	<8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>	<44F43D52.8020508@rubyforge.org>	<8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com>	<44F4483F.5070002@rubyforge.org>	<44F45738.2080601@dr-siemssen.de>	<44F459B5.7010601@rubyforge.org>
	<44F4687A.2070203@dr-siemssen.de>
Message-ID: <44F47BFC.1090605@rubyforge.org>

Daniel Siemssen wrote:
>>   
> Seems like the new dependencies code in edge rails / rails 1.2 will
> solve that if you use it's naming convention so that your libs get
> autoloaded. I don't think that it's worth to put too much time in
> producing something that achieves the same.

Makes sense.  Can you point me to any discussions of those conventions? 
  I keep looking for info on how the new dependencies code is coming, 
but all I see is reports of broken plugins!

Jay


From smartgpx at gmail.com  Wed Aug 30 05:53:03 2006
From: smartgpx at gmail.com (DeeJay)
Date: Wed, 30 Aug 2006 10:53:03 +0100
Subject: [Rspec-devel] Mock API - should_not_receive
Message-ID: <533048b70608300253s3f760e56m57b1a69fddcd067b@mail.gmail.com>

I would like to be able to specify that under given circumstances a
particular message
from my application is NOT returned to the user. [eg. IF Bank_Balance is
Positive THEN
Credit_Status_Report should NOT be "you are overdrawn."]


I can do -

specify "correct output" do
  my_mock_output.should_receive(:msg).with("expected text")
end

By trying for a PLS solution, I would hope to be able to write -

 specify "unwanted output" do
  my_mock_output.should_not_receive(:msg).with("unwanted text")
end

But that fails - it looks as though 'with' is not implemented for
should_not_receive.

Is there a way of expressing this logic in the API as it stands, or should
I submit a Feature Request?

Thanks -

DeeJay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060830/9492df21/attachment.html 

From dchelimsky at gmail.com  Wed Aug 30 05:59:15 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 30 Aug 2006 05:59:15 -0400
Subject: [Rspec-devel] Mock API - should_not_receive
In-Reply-To: <533048b70608300253s3f760e56m57b1a69fddcd067b@mail.gmail.com>
References: <533048b70608300253s3f760e56m57b1a69fddcd067b@mail.gmail.com>
Message-ID: <57c63afe0608300259lcf630c9w81fe6defbb4bb9df@mail.gmail.com>

For today you can still use should_receive(:msg).with("unwanted
text").never, but that will be removed in version 0.7 or 0.8.

Please submit a feature request for this. We can add this before we
remove the "never" syntax.

Thanks,
David


On 8/30/06, DeeJay <smartgpx at gmail.com> wrote:
>
>
> I would like to be able to specify that under given circumstances a
> particular message
> from my application is NOT returned to the user. [eg. IF Bank_Balance is
> Positive THEN
> Credit_Status_Report should NOT be "you are overdrawn."]
>
>
> I can do -
>
> specify "correct output" do
>   my_mock_output.should_receive(:msg).with("expected text")
> end
>
> By trying for a PLS solution, I would hope to be able to write -
>
>
> specify "unwanted output" do
>   my_mock_output.should_not_receive(:msg).with("unwanted
> text")
> end
>
> But that fails - it looks as though 'with' is not implemented for
> should_not_receive.
>
> Is there a way of expressing this logic in the API as it stands, or should
> I submit a Feature Request?
>
> Thanks -
>
> DeeJay
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From dchelimsky at gmail.com  Wed Aug 30 06:42:02 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 30 Aug 2006 06:42:02 -0400
Subject: [Rspec-devel] Mock API - should_not_receive
In-Reply-To: <57c63afe0608300259lcf630c9w81fe6defbb4bb9df@mail.gmail.com>
References: <533048b70608300253s3f760e56m57b1a69fddcd067b@mail.gmail.com>
	<57c63afe0608300259lcf630c9w81fe6defbb4bb9df@mail.gmail.com>
Message-ID: <57c63afe0608300342s305f022dvfd42d9977520549b@mail.gmail.com>

Never mind - I've implemented it and want to commit it so I'll add the
feature request now.

On 8/30/06, David Chelimsky <dchelimsky at gmail.com> wrote:
> For today you can still use should_receive(:msg).with("unwanted
> text").never, but that will be removed in version 0.7 or 0.8.
>
> Please submit a feature request for this. We can add this before we
> remove the "never" syntax.
>
> Thanks,
> David
>
>
> On 8/30/06, DeeJay <smartgpx at gmail.com> wrote:
> >
> >
> > I would like to be able to specify that under given circumstances a
> > particular message
> > from my application is NOT returned to the user. [eg. IF Bank_Balance is
> > Positive THEN
> > Credit_Status_Report should NOT be "you are overdrawn."]
> >
> >
> > I can do -
> >
> > specify "correct output" do
> >   my_mock_output.should_receive(:msg).with("expected text")
> > end
> >
> > By trying for a PLS solution, I would hope to be able to write -
> >
> >
> > specify "unwanted output" do
> >   my_mock_output.should_not_receive(:msg).with("unwanted
> > text")
> > end
> >
> > But that fails - it looks as though 'with' is not implemented for
> > should_not_receive.
> >
> > Is there a way of expressing this logic in the API as it stands, or should
> > I submit a Feature Request?
> >
> > Thanks -
> >
> > DeeJay
> >
> > _______________________________________________
> > Rspec-devel mailing list
> > Rspec-devel at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-devel
> >
> >
>

From smartgpx at gmail.com  Wed Aug 30 06:42:02 2006
From: smartgpx at gmail.com (DeeJay)
Date: Wed, 30 Aug 2006 11:42:02 +0100
Subject: [Rspec-devel] Mock API - should_not_receive
Message-ID: <533048b70608300342o5b42da03n55e89132ff37fbe5@mail.gmail.com>

  For today you can still use should_receive(:msg).with("unwanted
  text").never, but that will be removed in version 0.7 or 0.8.
Ah! It's too late to worry about it now, but although this is in the Rdoc
(which
I *should* have checked...), .never isn't mentioned on the website
documentation
at  http://rspec.rubyforge.org/documentation/mocks.html


  Please submit a feature request for this. We can add this before we
  remove the "never" syntax.

Will do. Thanks.


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

From dchelimsky at gmail.com  Wed Aug 30 06:54:31 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Wed, 30 Aug 2006 06:54:31 -0400
Subject: [Rspec-devel] Mock API - should_not_receive
In-Reply-To: <533048b70608300342o5b42da03n55e89132ff37fbe5@mail.gmail.com>
References: <533048b70608300342o5b42da03n55e89132ff37fbe5@mail.gmail.com>
Message-ID: <57c63afe0608300354y30d14d2cp959e2f636ae02342@mail.gmail.com>

On 8/30/06, DeeJay <smartgpx at gmail.com> wrote:
>   For today you can still use
> should_receive(:msg).with("unwanted
>   text").never, but that will be removed in version 0.7 or 0.8.
> Ah! It's too late to worry about it now, but although this is in the Rdoc
> (which
> I *should* have checked...), .never isn't mentioned on the website
> documentation
> at  http://rspec.rubyforge.org/documentation/mocks.html

Yeah - I pulled that from the docs when we added should_not_receive.
In the future, I'll add a deprecation message rather than pulling from
the docs.

>   Please submit a feature request for this. We can add this before we
>   remove the "never" syntax.
>
> Will do. Thanks.

I already added the feature request, committed code and closed the
request. Go ahead and check out the trunk if you want to use it right
away.

Cheers,
David

From daniel at dr-siemssen.de  Wed Aug 30 07:01:43 2006
From: daniel at dr-siemssen.de (Daniel Siemssen)
Date: Wed, 30 Aug 2006 13:01:43 +0200
Subject: [Rspec-devel] Using rspec with rails plugins, engines, etc.
In-Reply-To: <44F47BFC.1090605@rubyforge.org>
References: <44F38766.7080805@shopwatch.org>	<8d961d900608281756g78c3fe3er5de7657fcac2ed@mail.gmail.com>	<44F424EF.3060203@dr-siemssen.de>	<44F433E1.5080502@rubyforge.org>	<8d961d900608290608i1c738c1p77053d9c3ef20491@mail.gmail.com>	<44F43D52.8020508@rubyforge.org>	<8d961d900608290624p5ae6429eu39d1bb49e3e58072@mail.gmail.com>	<44F4483F.5070002@rubyforge.org>	<44F45738.2080601@dr-siemssen.de>	<44F459B5.7010601@rubyforge.org>	<44F4687A.2070203@dr-siemssen.de>
	<44F47BFC.1090605@rubyforge.org>
Message-ID: <44F57017.8050001@dr-siemssen.de>

On 29.08.2006 19:40, Jay Levitt wrote:
> Daniel Siemssen wrote:
>   
>>>   
>>>       
>> Seems like the new dependencies code in edge rails / rails 1.2 will
>> solve that if you use it's naming convention so that your libs get
>> autoloaded. I don't think that it's worth to put too much time in
>> producing something that achieves the same.
>>     
>
> Makes sense.  Can you point me to any discussions of those conventions? 
>   I keep looking for info on how the new dependencies code is coming, 
> but all I see is reports of broken plugins!
>
> Jay
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>   
Rails dependencies mechanism uses const_missing to load missing classes
and modules. It tries to find the classes/modules within these
directories (in this order):
 * /test/mocks/#{RAILS_ENV}
 * /app/controllers/*
 * /app/models/[_a-z]*
 * /components/[_a-z]*
 * /app
 * /app/models
 * /app/controllers
 * /app/helpers
 * /app/services
 * /app/apis
 * /components
 * /config
 * /lib
 * /vendor/plugins/*/lib/
Add more directories via config.autoload_paths in environment.rb.

If you use the the constant MyModule::MyClass, then rails searches for a
file my_class.rb in the directory my_module
("MyModule::MyClass".underscore). If you have a
/components/my_module/my_class.rb and a /lib/my_module/my_class.rb, then
only the first file gets loaded/required by rails. When rails loads a
file it will also be added to a set of already loaded files, so that
rails can check whether a file is already loaded or not or unload all
already loaded files (Dependencies.clear).

This results in the following conventions:
 * module name is equivalent to directory name
 * class name is equivalent to file name
 * classes and modules are always in MixedCase (as all classes and
modules in ruby are) and will be translated to underscore (e.g. MyClass
to my_class)
(* every file should only contain the class that corresponds to it's
file name)

As you see conventions haven't changed. But now all classes that are
loaded automatically can be reloaded and not only those that descend
from a class that includes the Reloadable module.

Take a look at activesupport/lib/active_support/dependencies.rb if you
want to know more and please correct me if I'm wrong.

Daniel

From aslak.hellesoy at gmail.com  Wed Aug 30 08:28:56 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 30 Aug 2006 14:28:56 +0200
Subject: [Rspec-devel] Mock API - should_not_receive
In-Reply-To: <533048b70608300253s3f760e56m57b1a69fddcd067b@mail.gmail.com>
References: <533048b70608300253s3f760e56m57b1a69fddcd067b@mail.gmail.com>
Message-ID: <8d961d900608300528w311ec98ah1f572c3e64de7ae5@mail.gmail.com>

On 8/30/06, DeeJay <smartgpx at gmail.com> wrote:
>
>
> I would like to be able to specify that under given circumstances a
> particular message
> from my application is NOT returned to the user. [eg. IF Bank_Balance is
> Positive THEN
> Credit_Status_Report should NOT be "you are overdrawn."]
>
>
> I can do -
>
> specify "correct output" do
>   my_mock_output.should_receive(:msg).with("expected text")
> end
>
> By trying for a PLS solution, I would hope to be able to write -
>
>
> specify "unwanted output" do
>   my_mock_output.should_not_receive(:msg).with("unwanted
> text")
> end
>

I would do:

specify "should not receive unwanted text" do
  # don't expect anything on the mock - it will barf if :msg is sent to it
end

Aslak

> But that fails - it looks as though 'with' is not implemented for
> should_not_receive.
>
> Is there a way of expressing this logic in the API as it stands, or should
> I submit a Feature Request?
>
> Thanks -
>
> DeeJay
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>

From smartgpx at gmail.com  Wed Aug 30 10:29:03 2006
From: smartgpx at gmail.com (DeeJay)
Date: Wed, 30 Aug 2006 15:29:03 +0100
Subject: [Rspec-devel] Mock API - should_not_receive
Message-ID: <533048b70608300729p1962f26dr4a2f23f20d93ed86@mail.gmail.com>

Aslak replied:

*> I would hope to be able to write -
*>*
*>*
*>* specify "unwanted output" do
*>*   my_mock_output.should_not_receive(:msg).with("unwanted **text")
*>* end
*>*
*
I would do:

specify "should not receive unwanted text" do
  # don't expect anything on the mock - it will barf if :msg is sent to it
end

Aslak

==============================================




Thanks, but DavidC has already commited code for this in response to 5570.

[5571, which I generated independently, can also be closed I think.]





DeeJay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060830/0fef0fbc/attachment.html 

From smartgpx at gmail.com  Wed Aug 30 11:17:01 2006
From: smartgpx at gmail.com (DeeJay)
Date: Wed, 30 Aug 2006 16:17:01 +0100
Subject: [Rspec-devel] Mock API - should_not_receive
Message-ID: <533048b70608300817l216ef498y2a22d3bc28cc6d75@mail.gmail.com>

FAO: David Chelimsky

DavidC wrote -

"I already added the feature request, committed code and closed the
request. Go ahead and check out the trunk if you want to use it right
away."

Checked out and exercised.

Yes, that's just what I was hoping for. Many thanks.

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

From aslak.hellesoy at gmail.com  Thu Aug 31 06:00:11 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 31 Aug 2006 12:00:11 +0200
Subject: [Rspec-devel] RSpec style in Scriptaculous' unittest.js
Message-ID: <8d961d900608310300x4af50af6pfceec46fb29b034b@mail.gmail.com>

Doing Javascript?

Looks like Scriptaculous' *excellent* unittest.js has got some BDD love:

http://ajaxian.com/archives/scriptaculous-behaviour-driven-development-testing

Aslak