From aslak.hellesoy at gmail.com Fri Apr 7 17:36:58 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 7 Apr 2006 16:36:58 -0500
Subject: [Rspec-devel] RSpec website
Message-ID: <8d961d900604071436r35f50e66yac9ce16751babc4a@mail.gmail.com>
The doc directory now contains what will become the RSpec website.
It's based on free webdesign from OSWD =>
http://www.oswd.org/user/profile/id/9462 and weaved together with
http://webgen.rubyforge.org/
All we need to do is to type textile docs in doc/*.page files
In order to generate the HTML you must install redcloth and webgen.
Stand in the doc folder and say
webgen
I'll do some more work on the layout and improve our Rake script so we
can generate the website+rdoc and upload it all with one command.
Aslak
From aslak.hellesoy at gmail.com Sat Apr 8 02:38:18 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sat, 8 Apr 2006 01:38:18 -0500
Subject: [Rspec-devel] New website, better release process
Message-ID: <8d961d900604072338j4d5ccd62j9e23d9a1aae454cf@mail.gmail.com>
Lads,
I have uploaded a new website to http://rspec.rubyforge.org/
Underneath it you will find RDoc and RCov as well as hand-written docs
that Dave A and I have been working on lately. Here is what you need
to know about the website:
* Documentation (*.page files) must be in textile format
(http://www.textism.com/tools/textile/)
* You must gem install syntax, webgen and redcloth in order to
generate the website
* You can generate the website locally with 'rake doc'
* Don't paste code in the docs - use the special tag I added for it
(see doc/src/examples.page) and it will end up nicely
syntax-colourised.
The website still needs some styling improvements - I'll try to get
this done before the show in Canada.
The Rakefile has also be overhauled, making the release process much
easier. In order to make a new release you must:
* Make sure CHANGES has all the important changes since last release
* Ensure CHANGES and lib/version.rb agree
* svn commit
* rake release
* Bump version in lib/version.rb (the upcoming version)
* Add a fresh new entry in CHANGES with the same upcoming version
(prefixed with 'In SVN')
* svn commit
'rake release' will do the following:
* Run tests, outputting an rcov report
* Package gem, tgz and zip files
* Release (upload) files to RubyForge's release system
* Generate website with webgen
* Move the RCov report under the website
* Generate RDoc under the website
* Upload all the HTML to http://rspec.rubyforge.org/
There were previously some permission problems that prevented some of
you from doing rake release. This should be fixed now
(http://rubyurl.com/wUb). Holler if you can't release.
Laters,
Aslak
From aslak.hellesoy at gmail.com Mon Apr 10 01:13:14 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 10 Apr 2006 00:13:14 -0500
Subject: [Rspec-devel] rcov stuff
Message-ID: <8d961d900604092213x618a1e2fu7c2770965ed3131c@mail.gmail.com>
lads,
the deafult target (test) now runs without rcov (faster)
the website target runs with rcov, and also verifies that coverage
doesn't drop below what we have now (99.2% wow)
aslak
From aslak.hellesoy at gmail.com Sun Apr 16 12:15:05 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 16 Apr 2006 11:15:05 -0500
Subject: [Rspec-devel] CHANGES
Message-ID: <8d961d900604160915o76c20999o4579e7c00f5ee203@mail.gmail.com>
guys,
let's all get back into the habit of updating CHANGES whenever we
commit functional changes to the codebase.
aslak
From aslak.hellesoy at gmail.com Wed Apr 19 13:41:46 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 19 Apr 2006 12:41:46 -0500
Subject: [Rspec-devel] [Fwd: RSpec webgen documentation]
In-Reply-To: <444669AE.5020704@daveastels.com>
References: <444669AE.5020704@daveastels.com>
Message-ID: <8d961d900604191041m7381e01cp6bf11b93910239df@mail.gmail.com>
Please direct future discussions to rspec-devel at rubyforge.org
The following is needed in order to run webgen from the doc folder:
webgen gem
syntax gem
RedCloth gem
You can safely ignore webgen's warnings about rmagick and bluecloth.
We'll update the README with this info.
While all of the RSpec developers usually use Macs, I just tried to
build the website against SVN HEAD (r369) on a WinXP box with Ruby
1.8.4 (2005-12-24) [i386-mswin32]:
gem install webgen
gem install syntax
gem install RedCloth
cd doc
webgen
The website built fine - I was unable to reproduce the errors you got.
(I do get errors when trying to build with 'rake website' - but the
errors are not the same as yours).
If the problem persists for you, please file a bug report at
RubyForge. Make sure to provide details about your environment (OS,
Ruby version, Gem versions, SVN revision)
HTH,
Aslak
On 4/19/06, Dave Astels wrote:
>
>
>
>
> ---------- Forwarded message ----------
> From: "Wilson Bilkovich"
> To: dastels at daveastels.com
> Date: Wed, 19 Apr 2006 12:26:56 -0400
> Subject: RSpec webgen documentation
> The 'README' file in the doc directory tells you to install:
> webgen, bluecloth, redcloth
>
> However, it turns out that you also need gem install syntax, and rmagick.
>
> Once I installed those, I still got some ugliness when I tried to gen
> the docs. Is this working for other people?
>
> C:\Bin\rspec\doc>webgen
> Wed Apr 19 12:26:00 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: parse error, unexpected tIDENTIFIER, expecting $:
> Wed Apr 19 12:26:01 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: parse error, unexpected tCONSTANT, expecting $:
> Wed Apr 19 12:26:01 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: Invalid char `\010' in expression
> (erb):14: Invalid char `\024' in expression
> (erb):14: Invalid char `\216' in expression
> (erb):15: parse error, unexpected tIDENTIFIER, expecting $:
> Wed Apr 19 12:26:01 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: parse error, unexpected tCONSTANT, expecting $:
> Wed Apr 19 12:26:01 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: parse error, unexpected tXSTRING_BEG, expecting $:
> Wed Apr 19 12:26:01 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):13: parse error, unexpected tSTRING_BEG, expecting $
> _erbout.concat "

Behaviour Driven Development for Ruby g>

\n"
> ^:
> Wed Apr 19 12:26:01 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: Invalid char `\260' in expression
> (erb):14: parse error, unexpected tIDENTIFIER, expecting $:
> Wed Apr 19 12:26:02 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: parse error, unexpected tIDENTIFIER, expecting $:
> Wed Apr 19 12:26:02 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: parse error, unexpected tCONSTANT, expecting $:
> Wed Apr 19 12:26:02 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: parse error, unexpected tXSTRING_BEG, expecting $:
> Wed Apr 19 12:26:02 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: parse error, unexpected tIDENTIFIER, expecting $:
> Wed Apr 19 12:26:02 Eastern Daylight Time 2006 ERROR -- ERB threw an error while
> processing an ERB template (): compile error
> (erb):12: Invalid char `\021' in expression
> (erb):14: parse error, unexpected tIDENTIFIER, expecting $:
>
>
>
>
>
From aslak.hellesoy at gmail.com Thu Apr 20 18:56:25 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Thu, 20 Apr 2006 17:56:25 -0500
Subject: [Rspec-devel] Rake and RCov documented
Message-ID: <8d961d900604201556n1a994dccy2ffbe911a68c37a5@mail.gmail.com>
http://rspec.rubyforge.org/tools/rake.html
And as you'll see in some places, we can now do in our *.page files:
def some
inline.ruby
end
Or if you want to slurp a file:
I haven't converted all the pages to use this yet - I'll leave it to you.
Aslak
From rich at infoether.com Mon Apr 24 07:45:29 2006
From: rich at infoether.com (Richard Kilmer)
Date: Mon, 24 Apr 2006 07:45:29 -0400
Subject: [Rspec-devel] possible addition to expectations...
Message-ID: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
Hello all.
Very great framework!
I was talking with Steven Baker at the Ruby in the Valley thing and I
came up with a simple addition that allows underscore notation in
addition to dot notation...so you can do this:
target.should.equal
target.should.not.equal
target.should.be.close ,
target.should.not.be.close ,
can also be expressed as:
target.should_equal
target.should_not_equal
target.should_be_close ,
target.should_not_be_close ,
What I did was override method_missing on Object and if the call
begins with should_ it splits on _ and then chain invokes those
methods. There may be cleaner code than this...I did it on a red-eye.
Best,
Rich Kilmer
class Object
include Spec::ObjectExpectations
alias_method :__orig_method_missing, :method_missing
def method_missing(method, *args, &block)
if method.to_s[0,7] == "should_"
object = self
calls = method.to_s.split("_")
while calls.length > 1
object = object.send(calls.shift)
end
return object.send(calls.shift, *args, &block)
end
__orig_method_missing(method, *args, &block)
end
end
From aslak.hellesoy at gmail.com Mon Apr 24 09:08:06 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Apr 2006 08:08:06 -0500
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
Message-ID: <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
hi rich,
that's funny. it's back to the way it used to be!
the reason we.switched.to.a.dotted.syntax was primarily implementation reasons.
however, i can't help but think it sounds a bit staccato when i read
it. my ruby head is more_used_to_digesting_underscores.
i like it a lot. let's see what the others think.
oh - i think you forgot to attach the tests ;-) we're trying to keep
our coverage where it is (98.9%)
aslak
On 4/24/06, Richard Kilmer wrote:
> Hello all.
>
> Very great framework!
>
> I was talking with Steven Baker at the Ruby in the Valley thing and I
> came up with a simple addition that allows underscore notation in
> addition to dot notation...so you can do this:
>
> target.should.equal
> target.should.not.equal
> target.should.be.close ,
> target.should.not.be.close ,
>
> can also be expressed as:
>
> target.should_equal
> target.should_not_equal
> target.should_be_close ,
> target.should_not_be_close ,
>
> What I did was override method_missing on Object and if the call
> begins with should_ it splits on _ and then chain invokes those
> methods. There may be cleaner code than this...I did it on a red-eye.
>
> Best,
>
> Rich Kilmer
>
>
> class Object
> include Spec::ObjectExpectations
>
> alias_method :__orig_method_missing, :method_missing
> def method_missing(method, *args, &block)
> if method.to_s[0,7] == "should_"
> object = self
> calls = method.to_s.split("_")
> while calls.length > 1
> object = object.send(calls.shift)
> end
> return object.send(calls.shift, *args, &block)
> end
> __orig_method_missing(method, *args, &block)
> end
>
> end
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
From dastels at daveastels.com Mon Apr 24 09:20:18 2006
From: dastels at daveastels.com (David Astels)
Date: Mon, 24 Apr 2006 08:20:18 -0500
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
<8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
Message-ID: <55FAB747-D6E4-4E51-BA5C-9FBA207C62FA@daveastels.com>
Nice. But... it doesn't support the have... expectations.
Dave
On 24-Apr-06, at 8:08 AM, aslak hellesoy wrote:
> hi rich,
>
> that's funny. it's back to the way it used to be!
> the reason we.switched.to.a.dotted.syntax was primarily
> implementation reasons.
>
> however, i can't help but think it sounds a bit staccato when i read
> it. my ruby head is more_used_to_digesting_underscores.
>
> i like it a lot. let's see what the others think.
> oh - i think you forgot to attach the tests ;-) we're trying to keep
> our coverage where it is (98.9%)
>
> aslak
>
> On 4/24/06, Richard Kilmer wrote:
>> Hello all.
>>
>> Very great framework!
>>
>> I was talking with Steven Baker at the Ruby in the Valley thing and I
>> came up with a simple addition that allows underscore notation in
>> addition to dot notation...so you can do this:
>>
>> target.should.equal
>> target.should.not.equal
>> target.should.be.close ,
>> target.should.not.be.close ,
>>
>> can also be expressed as:
>>
>> target.should_equal
>> target.should_not_equal
>> target.should_be_close ,
>> target.should_not_be_close ,
>>
>> What I did was override method_missing on Object and if the call
>> begins with should_ it splits on _ and then chain invokes those
>> methods. There may be cleaner code than this...I did it on a red-
>> eye.
>>
>> Best,
>>
>> Rich Kilmer
>>
>>
>> class Object
>> include Spec::ObjectExpectations
>>
>> alias_method :__orig_method_missing, :method_missing
>> def method_missing(method, *args, &block)
>> if method.to_s[0,7] == "should_"
>> object = self
>> calls = method.to_s.split("_")
>> while calls.length > 1
>> object = object.send(calls.shift)
>> end
>> return object.send(calls.shift, *args, &block)
>> end
>> __orig_method_missing(method, *args, &block)
>> end
>>
>> end
>>
>> _______________________________________________
>> 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 Mon Apr 24 09:25:58 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Apr 2006 08:25:58 -0500
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <55FAB747-D6E4-4E51-BA5C-9FBA207C62FA@daveastels.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
<8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
<55FAB747-D6E4-4E51-BA5C-9FBA207C62FA@daveastels.com>
Message-ID: <8d961d900604240625q491e0545nbde661e0c996c116@mail.gmail.com>
On 4/24/06, David Astels wrote:
> Nice. But... it doesn't support the have... expectations.
>
I got the impression Rich wanted feedback on the general idea. Support
for have.. can be easily added.
So what do you think about the idea? Something we want to add before
1.0? In my opinion it makes RSpec follow general Ruby naming
conventions more closely. So I'm +1
Aslak
> Dave
>
> On 24-Apr-06, at 8:08 AM, aslak hellesoy wrote:
>
> > hi rich,
> >
> > that's funny. it's back to the way it used to be!
> > the reason we.switched.to.a.dotted.syntax was primarily
> > implementation reasons.
> >
> > however, i can't help but think it sounds a bit staccato when i read
> > it. my ruby head is more_used_to_digesting_underscores.
> >
> > i like it a lot. let's see what the others think.
> > oh - i think you forgot to attach the tests ;-) we're trying to keep
> > our coverage where it is (98.9%)
> >
> > aslak
> >
> > On 4/24/06, Richard Kilmer wrote:
> >> Hello all.
> >>
> >> Very great framework!
> >>
> >> I was talking with Steven Baker at the Ruby in the Valley thing and I
> >> came up with a simple addition that allows underscore notation in
> >> addition to dot notation...so you can do this:
> >>
> >> target.should.equal
> >> target.should.not.equal
> >> target.should.be.close ,
> >> target.should.not.be.close ,
> >>
> >> can also be expressed as:
> >>
> >> target.should_equal
> >> target.should_not_equal
> >> target.should_be_close ,
> >> target.should_not_be_close ,
> >>
> >> What I did was override method_missing on Object and if the call
> >> begins with should_ it splits on _ and then chain invokes those
> >> methods. There may be cleaner code than this...I did it on a red-
> >> eye.
> >>
> >> Best,
> >>
> >> Rich Kilmer
> >>
> >>
> >> class Object
> >> include Spec::ObjectExpectations
> >>
> >> alias_method :__orig_method_missing, :method_missing
> >> def method_missing(method, *args, &block)
> >> if method.to_s[0,7] == "should_"
> >> object = self
> >> calls = method.to_s.split("_")
> >> while calls.length > 1
> >> object = object.send(calls.shift)
> >> end
> >> return object.send(calls.shift, *args, &block)
> >> end
> >> __orig_method_missing(method, *args, &block)
> >> end
> >>
> >> end
> >>
> >> _______________________________________________
> >> 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 dastels at daveastels.com Mon Apr 24 10:34:41 2006
From: dastels at daveastels.com (Dave Astels)
Date: Mon, 24 Apr 2006 09:34:41 -0500
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <8d961d900604240625q491e0545nbde661e0c996c116@mail.gmail.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
<8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
<55FAB747-D6E4-4E51-BA5C-9FBA207C62FA@daveastels.com>
<8d961d900604240625q491e0545nbde661e0c996c116@mail.gmail.com>
Message-ID: <444CE201.9040408@daveastels.com>
aslak hellesoy wrote:
> On 4/24/06, David Astels wrote:
>
>> Nice. But... it doesn't support the have... expectations.
>>
>>
>
> I got the impression Rich wanted feedback on the general idea. Support
> for have.. can be easily added.
>
> So what do you think about the idea? Something we want to add before
> 1.0? In my opinion it makes RSpec follow general Ruby naming
> conventions more closely. So I'm +1
I agree about having the _s. I'm not sure we want to roll it into 1.0
at this point. Possibly part of a 1.0.x point release.
It's a wicked cool approach but I have some small qualms about
overriding method_missing in object.
Let's give it some thought & disscussion.
Dave
From aslak.hellesoy at gmail.com Mon Apr 24 10:49:05 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Apr 2006 09:49:05 -0500
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <444CE201.9040408@daveastels.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
<8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
<55FAB747-D6E4-4E51-BA5C-9FBA207C62FA@daveastels.com>
<8d961d900604240625q491e0545nbde661e0c996c116@mail.gmail.com>
<444CE201.9040408@daveastels.com>
Message-ID: <8d961d900604240749i1ec3296bt897abf65e543e699@mail.gmail.com>
On 4/24/06, Dave Astels wrote:
> aslak hellesoy wrote:
> > On 4/24/06, David Astels wrote:
> >
> >> Nice. But... it doesn't support the have... expectations.
> >>
> >>
> >
> > I got the impression Rich wanted feedback on the general idea. Support
> > for have.. can be easily added.
> >
> > So what do you think about the idea? Something we want to add before
> > 1.0? In my opinion it makes RSpec follow general Ruby naming
> > conventions more closely. So I'm +1
> I agree about having the _s. I'm not sure we want to roll it into 1.0
> at this point. Possibly part of a 1.0.x point release.
>
> It's a wicked cool approach but I have some small qualms about
> overriding method_missing in object.
>
that's not a big deal as long as we alias the old method_missing and
delegate to it if the :method doesn't =~ /should_.*/
a
> Let's give it some thought & disscussion.
>
> Dave
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
From dastels at daveastels.com Mon Apr 24 13:02:48 2006
From: dastels at daveastels.com (Dave Astels)
Date: Mon, 24 Apr 2006 12:02:48 -0500
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <8d961d900604240749i1ec3296bt897abf65e543e699@mail.gmail.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com> <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com> <55FAB747-D6E4-4E51-BA5C-9FBA207C62FA@daveastels.com> <8d961d900604240625q491e0545nbde661e0c996c116@mail.gmail.com> <444CE201.9040408@daveastels.com>
<8d961d900604240749i1ec3296bt897abf65e543e699@mail.gmail.com>
Message-ID: <444D04B8.7050800@daveastels.com>
aslak hellesoy wrote:
> On 4/24/06, Dave Astels wrote:
>
>> aslak hellesoy wrote:
>>
>>> On 4/24/06, David Astels wrote:
>>>
>>>
>>>> Nice. But... it doesn't support the have... expectations.
>>>>
>>>>
>>>>
>>> I got the impression Rich wanted feedback on the general idea. Support
>>> for have.. can be easily added.
>>>
>>> So what do you think about the idea? Something we want to add before
>>> 1.0? In my opinion it makes RSpec follow general Ruby naming
>>> conventions more closely. So I'm +1
>>>
>> I agree about having the _s. I'm not sure we want to roll it into 1.0
>> at this point. Possibly part of a 1.0.x point release.
>>
>> It's a wicked cool approach but I have some small qualms about
>> overriding method_missing in object.
>>
>>
>
> that's not a big deal as long as we alias the old method_missing and
> delegate to it if the :method doesn't =~ /should_.*/
what about other messages =~ /should_.*/ that aren't ours?
Dave
From aslak.hellesoy at gmail.com Mon Apr 24 14:06:43 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Apr 2006 13:06:43 -0500
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <444D04B8.7050800@daveastels.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
<8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
<55FAB747-D6E4-4E51-BA5C-9FBA207C62FA@daveastels.com>
<8d961d900604240625q491e0545nbde661e0c996c116@mail.gmail.com>
<444CE201.9040408@daveastels.com>
<8d961d900604240749i1ec3296bt897abf65e543e699@mail.gmail.com>
<444D04B8.7050800@daveastels.com>
Message-ID: <8d961d900604241106m6e3eacebw84e326efd28e9144@mail.gmail.com>
> > that's not a big deal as long as we alias the old method_missing and
> > delegate to it if the :method doesn't =~ /should_.*/
>
> what about other messages =~ /should_.*/ that aren't ours?
>
I think that's very unlikely - just like collision with an other
should is unlikely.
We can address that with a commanline switch to disable the
/should_.*/ syntax - and have it enabled by default.
> Dave
>
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
From rich at infoether.com Mon Apr 24 16:02:03 2006
From: rich at infoether.com (Richard Kilmer)
Date: Mon, 24 Apr 2006 16:02:03 -0400
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <8d961d900604241106m6e3eacebw84e326efd28e9144@mail.gmail.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
<8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
<55FAB747-D6E4-4E51-BA5C-9FBA207C62FA@daveastels.com>
<8d961d900604240625q491e0545nbde661e0c996c116@mail.gmail.com>
<444CE201.9040408@daveastels.com>
<8d961d900604240749i1ec3296bt897abf65e543e699@mail.gmail.com>
<444D04B8.7050800@daveastels.com>
<8d961d900604241106m6e3eacebw84e326efd28e9144@mail.gmail.com>
Message-ID: <599ACCD4-8074-411F-A702-0F291CD82ED9@infoether.com>
On Apr 24, 2006, at 2:06 PM, aslak hellesoy wrote:
>>> that's not a big deal as long as we alias the old method_missing and
>>> delegate to it if the :method doesn't =~ /should_.*/
>>
>> what about other messages =~ /should_.*/ that aren't ours?
>>
>
> I think that's very unlikely - just like collision with an other
> should is unlikely.
> We can address that with a commanline switch to disable the
> /should_.*/ syntax - and have it enabled by default.
The same is for should itself. Since the should_ is a string, it can
easily be available at runtime via a switch. Its just spliting/
dispatching.
>
>> Dave
>>
>> _______________________________________________
>> 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 rich at infoether.com Mon Apr 24 16:09:37 2006
From: rich at infoether.com (Richard Kilmer)
Date: Mon, 24 Apr 2006 16:09:37 -0400
Subject: [Rspec-devel] possible addition to expectations...
In-Reply-To: <8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
References: <6F35CB5B-2BD4-447D-A070-6892C2DEBA3E@infoether.com>
<8d961d900604240608s3c861c15x9b0b239cdb0d20fb@mail.gmail.com>
Message-ID:
On Apr 24, 2006, at 9:08 AM, aslak hellesoy wrote:
> hi rich,
>
> that's funny. it's back to the way it used to be!
> the reason we.switched.to.a.dotted.syntax was primarily
> implementation reasons.
>
> however, i can't help but think it sounds a bit staccato when i read
> it. my ruby head is more_used_to_digesting_underscores.
>
> i like it a lot. let's see what the others think.
> oh - i think you forgot to attach the tests ;-) we're trying to keep
> our coverage where it is (98.9%)
>
> aslak
Yep, sorry about that, I was operating on the gem code on the plane,
it was all I had. I will roll tests in. I just wanted feedback, as
my initial impression of the readability of rspec (as a long time
ruby person) was "why all the ugly dots". I like the implementation
and encapsulation (chaining of calls). That's why I just split and
dispatch. The dots remove all ambiguity as to what is happening, the
other syntax is more "readable ruby". You will likely mix them for
example:
should_foo(bar).baz_buz
You need the dot to separate the passed variables, but its still
better to me than:
should.foo(bar).baz.buz
Although the same is happening.
-rich
>
> On 4/24/06, Richard Kilmer wrote:
>> Hello all.
>>
>> Very great framework!
>>
>> I was talking with Steven Baker at the Ruby in the Valley thing and I
>> came up with a simple addition that allows underscore notation in
>> addition to dot notation...so you can do this:
>>
>> target.should.equal
>> target.should.not.equal
>> target.should.be.close ,
>> target.should.not.be.close ,
>>
>> can also be expressed as:
>>
>> target.should_equal
>> target.should_not_equal
>> target.should_be_close ,
>> target.should_not_be_close ,
>>
>> What I did was override method_missing on Object and if the call
>> begins with should_ it splits on _ and then chain invokes those
>> methods. There may be cleaner code than this...I did it on a red-
>> eye.
>>
>> Best,
>>
>> Rich Kilmer
>>
>>
>> class Object
>> include Spec::ObjectExpectations
>>
>> alias_method :__orig_method_missing, :method_missing
>> def method_missing(method, *args, &block)
>> if method.to_s[0,7] == "should_"
>> object = self
>> calls = method.to_s.split("_")
>> while calls.length > 1
>> object = object.send(calls.shift)
>> end
>> return object.send(calls.shift, *args, &block)
>> end
>> __orig_method_missing(method, *args, &block)
>> end
>>
>> end
>>
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
From aslak.hellesoy at gmail.com Mon Apr 24 17:52:05 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Apr 2006 16:52:05 -0500
Subject: [Rspec-devel] ActiveRecord fixtures support in RSpec
Message-ID: <8d961d900604241452h73b2a29ara1a7815f2b7808c0@mail.gmail.com>
I have taken a look at how we can integrate RSpec with ActiveRecord.
Here is what I have found so far (with a little background for the
non-rails internals savvy):
When running Test::Unit tests for ActiveRecord objects, rails
developers usually use fixtures, which puts the database in a known
state as part of the setup() method. This known state is usually
described in a rails app's test/fixtures/*.yml files.
The code that reads these YAML files and puts the data in the database
during setup() is implemented here:
http://dev.rubyonrails.org/browser/trunk/activerecord/lib/active_record/fixtures.rb
As you see, the code is very tightly coupled to Test::Unit (by opening
the Test::Unit::TestCase class and adding class methods).
In order to have RSpec work with ActiveRecord we have to be able to
reuse this tightly coupled code. The way I see it now we have 2
options:
1) Patch Rails
Pull out the code that is coupled to Test::Unit and stick it in a
module that can be included both by Test::Unit::TestCase and by
whichever class we decide to do it from in RSpec (probably
ExecutionContext).
We'd have to produce a patch that is likely to be accepted by the
rails team, which means that it should be 110% backwards compatible.
2) Write an adapter
We can try to leave the Rails code untouched, and instead reimplement
an identical API (fixtures, use_transactional_fixtures, etc) in RSpec
and just have our implementation delegate to what's already in Rails.
This would only delegate to the methods that set up and tear down the
fixtures.
While I think option 1 is cleaner I think it's potentially a tougher
sell to the Rails team. I suggest we give our first stab at something
akin to option 2.
I know Steve and Eric have looked a little bit into this. What are
your thoughts on 1 vs 2? Can anyone think of other options?
Aslak
From aslak.hellesoy at gmail.com Mon Apr 24 17:59:10 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Apr 2006 16:59:10 -0500
Subject: [Rspec-devel] Fwd: ActiveRecord fixtures support in RSpec
In-Reply-To:
References: <8d961d900604241452h73b2a29ara1a7815f2b7808c0@mail.gmail.com>
Message-ID: <8d961d900604241459v686b48b3w58e9a2328f6dc2c5@mail.gmail.com>
was sent to me
---------- Forwarded message ----------
From: Wilson Bilkovich
Date: Apr 24, 2006 4:57 PM
Subject: Re: [Rspec-devel] ActiveRecord fixtures support in RSpec
To: aslak hellesoy
On 4/24/06, aslak hellesoy wrote:
> I have taken a look at how we can integrate RSpec with ActiveRecord.
> Here is what I have found so far (with a little background for the
> non-rails internals savvy):
>
> When running Test::Unit tests for ActiveRecord objects, rails
> developers usually use fixtures, which puts the database in a known
> state as part of the setup() method. This known state is usually
> described in a rails app's test/fixtures/*.yml files.
>
> The code that reads these YAML files and puts the data in the database
> during setup() is implemented here:
>
> http://dev.rubyonrails.org/browser/trunk/activerecord/lib/active_record/fixtures.rb
>
> As you see, the code is very tightly coupled to Test::Unit (by opening
> the Test::Unit::TestCase class and adding class methods).
>
> In order to have RSpec work with ActiveRecord we have to be able to
> reuse this tightly coupled code. The way I see it now we have 2
> options:
>
> 1) Patch Rails
> Pull out the code that is coupled to Test::Unit and stick it in a
> module that can be included both by Test::Unit::TestCase and by
> whichever class we decide to do it from in RSpec (probably
> ExecutionContext).
>
> We'd have to produce a patch that is likely to be accepted by the
> rails team, which means that it should be 110% backwards compatible.
>
> 2) Write an adapter
> We can try to leave the Rails code untouched, and instead reimplement
> an identical API (fixtures, use_transactional_fixtures, etc) in RSpec
> and just have our implementation delegate to what's already in Rails.
> This would only delegate to the methods that set up and tear down the
> fixtures.
>
> While I think option 1 is cleaner I think it's potentially a tougher
> sell to the Rails team. I suggest we give our first stab at something
> akin to option 2.
>
> I know Steve and Eric have looked a little bit into this. What are
> your thoughts on 1 vs 2? Can anyone think of other options?
>
> Aslak
>
I've done some work in the guts of fixtures.rb, adding support for STI
naming conventions, etc, etc.
Given what I saw, I highly recommend #2, and I'd be glad to help.
My personal beef with the fixtures code is that it names fixtures
after the table name in the DB, rather than the model class.
class Yarr < ActiveRecord::Base
set_table_name 'yoogle'
end
means that you can't just say:
fixtures :yarrs
..and expect it to work.
Supporting that at the same time might give RSpec another reason to
're-implement' fixtures.
--Wilson.
From aslak.hellesoy at gmail.com Mon Apr 24 17:59:25 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Apr 2006 16:59:25 -0500
Subject: [Rspec-devel] Fwd: ActiveRecord fixtures support in RSpec
In-Reply-To:
References: <8d961d900604241452h73b2a29ara1a7815f2b7808c0@mail.gmail.com>
Message-ID: <8d961d900604241459j1388435bhf925632a438f76a2@mail.gmail.com>
was sent to me
---------- Forwarded message ----------
From: Eric Hodel
Date: Apr 24, 2006 4:57 PM
Subject: Re: [Rspec-devel] ActiveRecord fixtures support in RSpec
To: aslak hellesoy
On Apr 24, 2006, at 2:52 PM, aslak hellesoy wrote:
> [...] the code is very tightly coupled to Test::Unit (by opening
> the Test::Unit::TestCase class and adding class methods).
>
> In order to have RSpec work with ActiveRecord we have to be able to
> reuse this tightly coupled code. The way I see it now we have 2
> options:
>
> 1) Patch Rails
> Pull out the code that is coupled to Test::Unit and stick it in a
> module that can be included both by Test::Unit::TestCase and by
> whichever class we decide to do it from in RSpec (probably
> ExecutionContext).
>
> We'd have to produce a patch that is likely to be accepted by the
> rails team, which means that it should be 110% backwards compatible.
>
> 2) Write an adapter
> We can try to leave the Rails code untouched, and instead reimplement
> an identical API (fixtures, use_transactional_fixtures, etc) in RSpec
> and just have our implementation delegate to what's already in Rails.
> This would only delegate to the methods that set up and tear down the
> fixtures.
>
> While I think option 1 is cleaner I think it's potentially a tougher
> sell to the Rails team. I suggest we give our first stab at something
> akin to option 2.
>
> I know Steve and Eric have looked a little bit into this. What are
> your thoughts on 1 vs 2? Can anyone think of other options?
I vote for option 1. It shouldn't be too difficult to make it
generic-enough and still backwards compatible.
The part that stomps on Test::Unit could be pulled into
test_helper.rb, I think, keeping the patch quite small.
--
Eric Hodel - drbrain at segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
From rich at infoether.com Mon Apr 24 19:49:25 2006
From: rich at infoether.com (Richard Kilmer)
Date: Mon, 24 Apr 2006 19:49:25 -0400
Subject: [Rspec-devel] shall vs. should
Message-ID: <337928BA-EF10-4656-AEBD-DF0B86A416D5@infoether.com>
Just a vocabulary nit, but if you are "specifying" behavior is it not
correct to say this object shall do or not do something rather than
should? I mean, you are in a sense specifying something akin to a
contract, and all contracts that I have worked on use shall to
indicate that its required and not optional.
context "An empty stack" do
specify "should accept an item when sent push" do
lambda { @stack.push Object.new }.should.not.raise
end
end
would it not be more correct in saying:
context "An empty stack" do
specify "shall accept an item when sent push" do
lambda { @stack.push Object.new }.shall.not.raise
end
end
Its more proper to say "An empty stack shall accept an item when sent
push". That is contractual language, asserting an absolute
requirement, and these specs are either met or not (there is no grey
area).
-rich
From aslak.hellesoy at gmail.com Mon Apr 24 20:35:03 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Mon, 24 Apr 2006 19:35:03 -0500
Subject: [Rspec-devel] shall vs. should
In-Reply-To: <337928BA-EF10-4656-AEBD-DF0B86A416D5@infoether.com>
References: <337928BA-EF10-4656-AEBD-DF0B86A416D5@infoether.com>
Message-ID: <8d961d900604241735n47dec17cuca45c3f363584be7@mail.gmail.com>
this is an old debate among bdd'ers. some people want 'must' and
'will' too. dan north, who is the 'father' of bdd uses should in his
jbehave framework (http://jbehave.codehaus.org/) as well as the
various texts he has written on the subject.
dan prefers the word behaviour, but the rspec crowd felt that
'specification of behaviour' is more appropriate - hence spec.
the way i see it, in our context, 'should' is significantly different
from 'shall'. i feel it is easier to say 'should' about something that
doesn't yet exist. 'shall' sort of implies the existence of the
subject - the thing that shall.
and that is precisely why i prefer should over shall. bdd is a design
technique, and we need a vocabulary that allows us to talk about the
not-yet-existent. shall, just like test, assumes the existence of the
subject, which is what we're trying to get away from.
aslak
On 4/24/06, Richard Kilmer wrote:
> Just a vocabulary nit, but if you are "specifying" behavior is it not
> correct to say this object shall do or not do something rather than
> should? I mean, you are in a sense specifying something akin to a
> contract, and all contracts that I have worked on use shall to
> indicate that its required and not optional.
>
> context "An empty stack" do
> specify "should accept an item when sent push" do
> lambda { @stack.push Object.new }.should.not.raise
> end
> end
>
> would it not be more correct in saying:
>
> context "An empty stack" do
> specify "shall accept an item when sent push" do
> lambda { @stack.push Object.new }.shall.not.raise
> end
> end
>
> Its more proper to say "An empty stack shall accept an item when sent
> push". That is contractual language, asserting an absolute
> requirement, and these specs are either met or not (there is no grey
> area).
>
> -rich
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
From rich at infoether.com Mon Apr 24 20:49:57 2006
From: rich at infoether.com (Richard Kilmer)
Date: Mon, 24 Apr 2006 20:49:57 -0400
Subject: [Rspec-devel] shall vs. should
In-Reply-To: <8d961d900604241735n47dec17cuca45c3f363584be7@mail.gmail.com>
References: <337928BA-EF10-4656-AEBD-DF0B86A416D5@infoether.com>
<8d961d900604241735n47dec17cuca45c3f363584be7@mail.gmail.com>
Message-ID: <4CBAFDFE-FA5A-4B26-83EB-B9D8094254BA@infoether.com>
On Apr 24, 2006, at 8:35 PM, aslak hellesoy wrote:
> this is an old debate among bdd'ers. some people want 'must' and
> 'will' too. dan north, who is the 'father' of bdd uses should in his
> jbehave framework (http://jbehave.codehaus.org/) as well as the
> various texts he has written on the subject.
>
> dan prefers the word behaviour, but the rspec crowd felt that
> 'specification of behaviour' is more appropriate - hence spec.
>
> the way i see it, in our context, 'should' is significantly different
> from 'shall'. i feel it is easier to say 'should' about something that
> doesn't yet exist. 'shall' sort of implies the existence of the
> subject - the thing that shall.
>
> and that is precisely why i prefer should over shall. bdd is a design
> technique, and we need a vocabulary that allows us to talk about the
> not-yet-existent. shall, just like test, assumes the existence of the
> subject, which is what we're trying to get away from.
Right, my initial thought of that was:
archetype "An empty stack" do
behavior "should do blah" do
end
end
That is actually what you are doing, imagine an archetype for
something that does not yet exist. You are expecting the behavior to
be such and such.
Anyway, not hung up on the should vs. shall, just came to mind.
from wikipedia:
An archetype is an idealized model of a person, object, or concept
from which similar instances are derived, copied, patterned, or
emulated.
-rich
>
> aslak
>
> On 4/24/06, Richard Kilmer wrote:
>> Just a vocabulary nit, but if you are "specifying" behavior is it not
>> correct to say this object shall do or not do something rather than
>> should? I mean, you are in a sense specifying something akin to a
>> contract, and all contracts that I have worked on use shall to
>> indicate that its required and not optional.
>>
>> context "An empty stack" do
>> specify "should accept an item when sent push" do
>> lambda { @stack.push Object.new }.should.not.raise
>> end
>> end
>>
>> would it not be more correct in saying:
>>
>> context "An empty stack" do
>> specify "shall accept an item when sent push" do
>> lambda { @stack.push Object.new }.shall.not.raise
>> end
>> end
>>
>> Its more proper to say "An empty stack shall accept an item when sent
>> push". That is contractual language, asserting an absolute
>> requirement, and these specs are either met or not (there is no grey
>> area).
>>
>> -rich
>> _______________________________________________
>> Rspec-devel mailing list
>> Rspec-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-devel
>>
From aslak.hellesoy at gmail.com Tue Apr 25 03:09:11 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Tue, 25 Apr 2006 02:09:11 -0500
Subject: [Rspec-devel] shall vs. should
In-Reply-To: <4CBAFDFE-FA5A-4B26-83EB-B9D8094254BA@infoether.com>
References: <337928BA-EF10-4656-AEBD-DF0B86A416D5@infoether.com>
<8d961d900604241735n47dec17cuca45c3f363584be7@mail.gmail.com>
<4CBAFDFE-FA5A-4B26-83EB-B9D8094254BA@infoether.com>
Message-ID: <8d961d900604250009q4f178af1ma0e17ada3555a75a@mail.gmail.com>
On 4/24/06, Richard Kilmer wrote:
>
> On Apr 24, 2006, at 8:35 PM, aslak hellesoy wrote:
>
> > this is an old debate among bdd'ers. some people want 'must' and
> > 'will' too. dan north, who is the 'father' of bdd uses should in his
> > jbehave framework (http://jbehave.codehaus.org/) as well as the
> > various texts he has written on the subject.
> >
> > dan prefers the word behaviour, but the rspec crowd felt that
> > 'specification of behaviour' is more appropriate - hence spec.
> >
> > the way i see it, in our context, 'should' is significantly different
> > from 'shall'. i feel it is easier to say 'should' about something that
> > doesn't yet exist. 'shall' sort of implies the existence of the
> > subject - the thing that shall.
> >
> > and that is precisely why i prefer should over shall. bdd is a design
> > technique, and we need a vocabulary that allows us to talk about the
> > not-yet-existent. shall, just like test, assumes the existence of the
> > subject, which is what we're trying to get away from.
>
> Right, my initial thought of that was:
>
> archetype "An empty stack" do
> behavior "should do blah" do
> end
> end
>
> That is actually what you are doing, imagine an archetype for
> something that does not yet exist. You are expecting the behavior to
> be such and such.
>
> Anyway, not hung up on the should vs. shall, just came to mind.
>
> from wikipedia:
>
> An archetype is an idealized model of a person, object, or concept
> from which similar instances are derived, copied, patterned, or
> emulated.
>
i like archetype. since several people have expressed a desire to use
a different vocabulary for bdd - and since ruby allows us to be
flexible - i'll throw up some docs on how to extend rspec to support
*your* words. -with a big warning to those who are inclined to use
'test', which means they missed the point ;-)
ps rich - any chance you could post a patch on rubyforge with some
tests for the should_this_and_that syntax? i'd like to explore it
further.
cheers,
aslak
> -rich
>
>
>
> >
> > aslak
> >
> > On 4/24/06, Richard Kilmer wrote:
> >> Just a vocabulary nit, but if you are "specifying" behavior is it not
> >> correct to say this object shall do or not do something rather than
> >> should? I mean, you are in a sense specifying something akin to a
> >> contract, and all contracts that I have worked on use shall to
> >> indicate that its required and not optional.
> >>
> >> context "An empty stack" do
> >> specify "should accept an item when sent push" do
> >> lambda { @stack.push Object.new }.should.not.raise
> >> end
> >> end
> >>
> >> would it not be more correct in saying:
> >>
> >> context "An empty stack" do
> >> specify "shall accept an item when sent push" do
> >> lambda { @stack.push Object.new }.shall.not.raise
> >> end
> >> end
> >>
> >> Its more proper to say "An empty stack shall accept an item when sent
> >> push". That is contractual language, asserting an absolute
> >> requirement, and these specs are either met or not (there is no grey
> >> area).
> >>
> >> -rich
> >> _______________________________________________
> >> Rspec-devel mailing list
> >> Rspec-devel at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-devel
> >>
>
>
From aslak.hellesoy at gmail.com Wed Apr 26 15:26:52 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Wed, 26 Apr 2006 14:26:52 -0500
Subject: [Rspec-devel] ActiveRecord fixtures support in RSpec
In-Reply-To: <8d961d900604241452h73b2a29ara1a7815f2b7808c0@mail.gmail.com>
References: <8d961d900604241452h73b2a29ara1a7815f2b7808c0@mail.gmail.com>
Message-ID: <8d961d900604261226i29bca53cgb589f4939cebf384@mail.gmail.com>
> 2) Write an adapter
> We can try to leave the Rails code untouched, and instead reimplement
> an identical API (fixtures, use_transactional_fixtures, etc) in RSpec
> and just have our implementation delegate to what's already in Rails.
> This would only delegate to the methods that set up and tear down the
> fixtures.
>
i have toyed a little with option 2 and the syntax. what do you think of this:
context 'Empolyee' do
fixtures :employees
specify 'should have name' do
employees(:aslak).name.should.equal 'aslak'
end
end
structurally this is the same as test::unit rails fixtures. the
implementation on the rspec side will be completely different, since
it would require implementation of extra methods on Context and
dynamically adding methods to the execution context (e.g. the emplyees
method).
but without going in too much detail about the implementation - how do
you like the syntax?
aslak
From drbrain at segment7.net Wed Apr 26 16:19:01 2006
From: drbrain at segment7.net (Eric Hodel)
Date: Wed, 26 Apr 2006 13:19:01 -0700
Subject: [Rspec-devel] ActiveRecord fixtures support in RSpec
In-Reply-To: <8d961d900604261226i29bca53cgb589f4939cebf384@mail.gmail.com>
References: <8d961d900604241452h73b2a29ara1a7815f2b7808c0@mail.gmail.com>
<8d961d900604261226i29bca53cgb589f4939cebf384@mail.gmail.com>
Message-ID:
On Apr 26, 2006, at 12:26 PM, aslak hellesoy wrote:
>> 2) Write an adapter
>> We can try to leave the Rails code untouched, and instead reimplement
>> an identical API (fixtures, use_transactional_fixtures, etc) in RSpec
>> and just have our implementation delegate to what's already in Rails.
>> This would only delegate to the methods that set up and tear down the
>> fixtures.
>>
>
> i have toyed a little with option 2 and the syntax. what do you
> think of this:
>
> context 'Empolyee' do
> fixtures :employees
>
> specify 'should have name' do
> employees(:aslak).name.should.equal 'aslak'
> end
> end
>
> structurally this is the same as test::unit rails fixtures. the
> implementation on the rspec side will be completely different, since
> it would require implementation of extra methods on Context and
> dynamically adding methods to the execution context (e.g. the emplyees
> method).
>
> but without going in too much detail about the implementation - how do
> you like the syntax?
I think it looks fine and benefits from familiarity with Rails.
--
Eric Hodel - drbrain at segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
From aslak.hellesoy at gmail.com Fri Apr 28 01:24:09 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Fri, 28 Apr 2006 00:24:09 -0500
Subject: [Rspec-devel] ActiveRecord fixtures support in RSpec
In-Reply-To: <8d961d900604261226i29bca53cgb589f4939cebf384@mail.gmail.com>
References: <8d961d900604241452h73b2a29ara1a7815f2b7808c0@mail.gmail.com>
<8d961d900604261226i29bca53cgb589f4939cebf384@mail.gmail.com>
Message-ID: <8d961d900604272224l16b110ccu36e5515fe2936486@mail.gmail.com>
> context 'Empolyee' do
> fixtures :employees
>
> specify 'should have name' do
> employees(:aslak).name.should.equal 'aslak'
> end
> end
>
I've checked in some experimental code that implements this.
it all lives on the branches/ar_fixtures_facade branch.
I have been able to reuse about ~75% of the whole fixtures code, which
is the functionality that loads fixture files (yml, csv etc.) and
populates database tables.
The remaining ~25% of the Rails fixtures code that defines the
'fixtures' and dynamic helper methods (like employees) have been
copied, tweaked and moved to Context, Specification and
ExecutionContext extensions. Even if this had been implemented better
in Rails it would have been hard to reuse. I don't think it's that big
a deal. There is about 150 lines of code to reimplement.
I'm eager to get some feedback on this - especially from people who
know rails fixtures internals.
From deanmao at gmail.com Sun Apr 30 03:25:08 2006
From: deanmao at gmail.com (Dean Mao)
Date: Sun, 30 Apr 2006 03:25:08 -0400
Subject: [Rspec-devel] mock.send defect
Message-ID: <5ad0c3de0604300025s5b050c68rdc51d1a5934cc7b5@mail.gmail.com>
I was asked to post this on the list. This is catch23 on freenode. Below
is the context of the discussion, along with the test case used to produce
the results.
(03:05:06) *catch23:* so i'm trying to mock some of the objects in the
jabber library, but some of the classes there override send
(03:06:42) *catch23:* and so i'm thinking it's not possible to do a
.should.receive(:send) type of thing... when the mock.send happens, it
thinks it's actually trying to perform a method call
(03:07:18) *srbaker:* oh wow
(03:07:26) *srbaker:* that's... awesome.
(03:07:48) *catch23:* i guess nobody has encountered this eh? hehe
(03:16:09) *catch23:* I'm showing 2 examples, one where the message is
"sendb" and one where the message is "send"
(03:16:25) *catch23:* the example with "sendb" works, the message with
"send" fails
(03:17:20) *catch23:* do those test cases look okay?
(03:19:02) *srbaker:* that looks great. put that on the list
context "testing send" do
specify "should be able to mock test" do
test_mock = mock("test")
test_mock.should.receive(:sendb) {puts "success"}
test_mock.sendb
end
end
----> this is okay
context "testing send" do
specify "should be able to mock test" do
test_mock = mock("test")
test_mock.should.receive(:send) {puts "success"}
test_mock.send
end
end
----> this fails
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/rspec-devel/attachments/20060430/a6fd2f05/attachment.htm
From aslak.hellesoy at gmail.com Sun Apr 30 09:59:21 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 30 Apr 2006 08:59:21 -0500
Subject: [Rspec-devel] mock.send defect
In-Reply-To: <5ad0c3de0604300025s5b050c68rdc51d1a5934cc7b5@mail.gmail.com>
References: <5ad0c3de0604300025s5b050c68rdc51d1a5934cc7b5@mail.gmail.com>
Message-ID: <8d961d900604300659w3c8510bexe346c9cac7cda8d5@mail.gmail.com>
RSpec mocks are implemented using method_missing.
However, if you send a message to a mock that _is_ defined (i.e. all
methods inherited from Object), method_missing will not be called.
This is the case for send, plus a lot of other methods.
I think we need to undefine all inherited methods.
Thoughts?
On 4/30/06, Dean Mao wrote:
> I was asked to post this on the list. This is catch23 on freenode. Below
> is the context of the discussion, along with the test case used to produce
> the results.
>
> (03:05:06) catch23: so i'm trying to mock some of the objects in the jabber
> library, but some of the classes there override send
> (03:06:42) catch23: and so i'm thinking it's not possible to do a
> .should.receive(:send) type of thing... when the mock.send happens, it
> thinks it's actually trying to perform a method call
> (03:07:18) srbaker: oh wow
> (03:07:26) srbaker: that's... awesome.
> (03:07:48) catch23: i guess nobody has encountered this eh? hehe
> (03:16:09) catch23: I'm showing 2 examples, one where the message is "sendb"
> and one where the message is "send"
> (03:16:25) catch23: the example with "sendb" works, the message with "send"
> fails
> (03:17:20) catch23: do those test cases look okay?
> (03:19:02) srbaker: that looks great. put that on the list
>
> context "testing send" do
> specify "should be able to mock test" do
> test_mock = mock("test")
> test_mock.should.receive(:sendb) {puts "success"}
> test_mock.sendb
> end
> end
>
> ----> this is okay
>
> context "testing send" do
> specify "should be able to mock test" do
> test_mock = mock("test")
> test_mock.should.receive(:send) {puts "success"}
> test_mock.send
> end
> end
>
> ----> this fails
> _______________________________________________
> Rspec-devel mailing list
> Rspec-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-devel
>
>
From dchelimsky at gmail.com Sun Apr 30 10:11:49 2006
From: dchelimsky at gmail.com (David Chelimsky)
Date: Sun, 30 Apr 2006 10:11:49 -0400
Subject: [Rspec-devel] mock.send defect
In-Reply-To: <8d961d900604300659w3c8510bexe346c9cac7cda8d5@mail.gmail.com>
References: <5ad0c3de0604300025s5b050c68rdc51d1a5934cc7b5@mail.gmail.com>
<8d961d900604300659w3c8510bexe346c9cac7cda8d5@mail.gmail.com>
Message-ID: <57c63afe0604300711s4d483f3am2e85c1350c42d8fb@mail.gmail.com>
Works for me.
On 4/30/06, aslak hellesoy wrote:
> RSpec mocks are implemented using method_missing.
> However, if you send a message to a mock that _is_ defined (i.e. all
> methods inherited from Object), method_missing will not be called.
> This is the case for send, plus a lot of other methods.
>
> I think we need to undefine all inherited methods.
>
> Thoughts?
>
> On 4/30/06, Dean Mao wrote:
> > I was asked to post this on the list. This is catch23 on freenode. Below
> > is the context of the discussion, along with the test case used to produce
> > the results.
> >
> > (03:05:06) catch23: so i'm trying to mock some of the objects in the jabber
> > library, but some of the classes there override send
> > (03:06:42) catch23: and so i'm thinking it's not possible to do a
> > .should.receive(:send) type of thing... when the mock.send happens, it
> > thinks it's actually trying to perform a method call
> > (03:07:18) srbaker: oh wow
> > (03:07:26) srbaker: that's... awesome.
> > (03:07:48) catch23: i guess nobody has encountered this eh? hehe
> > (03:16:09) catch23: I'm showing 2 examples, one where the message is "sendb"
> > and one where the message is "send"
> > (03:16:25) catch23: the example with "sendb" works, the message with "send"
> > fails
> > (03:17:20) catch23: do those test cases look okay?
> > (03:19:02) srbaker: that looks great. put that on the list
> >
> > context "testing send" do
> > specify "should be able to mock test" do
> > test_mock = mock("test")
> > test_mock.should.receive(:sendb) {puts "success"}
> > test_mock.sendb
> > end
> > end
> >
> > ----> this is okay
> >
> > context "testing send" do
> > specify "should be able to mock test" do
> > test_mock = mock("test")
> > test_mock.should.receive(:send) {puts "success"}
> > test_mock.send
> > end
> > end
> >
> > ----> this fails
> > _______________________________________________
> > 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 Apr 30 10:28:41 2006
From: aslak.hellesoy at gmail.com (aslak hellesoy)
Date: Sun, 30 Apr 2006 09:28:41 -0500
Subject: [Rspec-devel] mock.send defect
In-Reply-To: <57c63afe0604300711s4d483f3am2e85c1350c42d8fb@mail.gmail.com>
References: <5ad0c3de0604300025s5b050c68rdc51d1a5934cc7b5@mail.gmail.com>
<8d961d900604300659w3c8510bexe346c9cac7cda8d5@mail.gmail.com>
<57c63afe0604300711s4d483f3am2e85c1350c42d8fb@mail.gmail.com>
Message-ID: <8d961d900604300728t273b17dfld12594c2323463bc@mail.gmail.com>
Fixed in SVN.
(I added this to the top of Mock)
(public_instance_methods - ['__id__', '__send__', 'nil?']).each do |m|
undef_method m
end
Aslak
On 4/30/06, David Chelimsky wrote:
> Works for me.
>
> On 4/30/06, aslak hellesoy wrote:
> > RSpec mocks are implemented using method_missing.
> > However, if you send a message to a mock that _is_ defined (i.e. all
> > methods inherited from Object), method_missing will not be called.
> > This is the case for send, plus a lot of other methods.
> >
> > I think we need to undefine all inherited methods.
> >
> > Thoughts?
> >
> > On 4/30/06, Dean Mao wrote:
> > > I was asked to post this on the list. This is catch23 on freenode. Below
> > > is the context of the discussion, along with the test case used to produce
> > > the results.
> > >
> > > (03:05:06) catch23: so i'm trying to mock some of the objects in the jabber
> > > library, but some of the classes there override send
> > > (03:06:42) catch23: and so i'm thinking it's not possible to do a
> > > .should.receive(:send) type of thing... when the mock.send happens, it
> > > thinks it's actually trying to perform a method call
> > > (03:07:18) srbaker: oh wow
> > > (03:07:26) srbaker: that's... awesome.
> > > (03:07:48) catch23: i guess nobody has encountered this eh? hehe
> > > (03:16:09) catch23: I'm showing 2 examples, one where the message is "sendb"
> > > and one where the message is "send"
> > > (03:16:25) catch23: the example with "sendb" works, the message with "send"
> > > fails
> > > (03:17:20) catch23: do those test cases look okay?
> > > (03:19:02) srbaker: that looks great. put that on the list
> > >
> > > context "testing send" do
> > > specify "should be able to mock test" do
> > > test_mock = mock("test")
> > > test_mock.should.receive(:sendb) {puts "success"}
> > > test_mock.sendb
> > > end
> > > end
> > >
> > > ----> this is okay
> > >
> > > context "testing send" do
> > > specify "should be able to mock test" do
> > > test_mock = mock("test")
> > > test_mock.should.receive(:send) {puts "success"}
> > > test_mock.send
> > > end
> > > end
> > >
> > > ----> this fails
> > > _______________________________________________
> > > 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
>