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 >